Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    emard
    @emard
    great
    Lawrie Griffiths
    @lawrie
    @Dolu1990 Could we add a test that the flash copy to SDRAM has worked in the bootloader. For example check the first few bytes or compare the SDRAM with the flash memory?
    emard
    @emard
    I think screen worked if logged over the network. For flash I can try tu run ecp5.flash_read or similar. I can also try to erase boot flash (passthru) and things like this
    Lawrie Griffiths
    @lawrie
    I have added a new version of rootfs.tar.gz to images. It contains pppd and screen.
    emard
    @emard
    Right I will download! I am listening to mp3 and it WORKS!!!
    Lawrie Griffiths
    @lawrie
    It works better on the blue 85F with 4 cpus, as it doesn't slow down other stuff.
    emard
    @emard
    4-core is really powerful :) I will retry green 85f!
    e2kgh
    @e2kgh
    The boards which should be available from Mouser, are all "blue"?
    emard
    @emard
    They are green but have winbond flash and I have 12F it boots saxonsoc. blue iwas produced by "watterott" germany in some quantity about 100 pcs but I dont know if they produced more (probaby some)
    Currently the blue only has 64MB they probably found cheap enough source around 2-3$ I guess. current 64MB on Mouser are all 10$ or more so Goran decided to put 32MB, I found some ISSI that is around 2$ and has grade 7
    Dolu1990
    @Dolu1990
    @lawrie Sure we can
    e2kgh
    @e2kgh
    @lawrie : On the saxon web, you're(?) writing that for the 64MByte Memory, the :
    saxon_standalone_compile bootloader CFLAGS_ARGS="-DSDRAM_TIMING=AS4C32M16SB_7TCN_ps"
    SDRAM_SIZE=64 saxon_netlist
    FPGA_SIZE=85 saxon_bitstream
    should run. But isn't the :
    saxon_standalone_compile sdram_init CFLAGS_ARGS="-DSDRAM_TIMING=AS4C32M16SB_7TCN_ps"
    missing?
    Dolu1990
    @Dolu1990
    sdram_init is only used if you want to use openocd to connect to the FPGA
    i mean, to connect to the SoC
    e2kgh
    @e2kgh
    Ah! OK!
    Lawrie Griffiths
    @lawrie
    @emard I am guessing that we need CONFIG_UNIX=Y for screen to work. As that enables Unix domain sockets, and screen does things like if ((s = socket(AF_UNIX, SOCK_STREAM, 0)) == -1)
    emard
    @emard
    yes unix doman sockets are needed for many similar things
    Lawrie Griffiths
    @lawrie
    Sockets need adding to the lcc C library sometime.
    emard
    @emard
    Oh well yes it can be on todo list :)
    Lawrie Griffiths
    @lawrie
    Adding CONFIG_UNIX=Y did not fix screen.
    Lawrie Griffiths
    @lawrie
    It made no difference to the size of the kernel, so presumably that option was already on.
    emard
    @emard
    If you have network functionaly, can you try to telnet or ssh to saxonsoc and then try screen?
    BTW 85F I have here has only 32MB SDRAM so first memtest fails
    Lawrie Griffiths
    @lawrie
    I don't have any network functionality.
    Dolu1990
    @Dolu1990
    what is the linux.config / buildroot defconfig you are using ?
    Lawrie Griffiths
    @lawrie
    I have just added BR2_PACKAGE_PPPD=Y and BR2_PACKAGE_SCREEN=Y to spinal_ulx3s_defconfig.
    I tried adding CONFIG_UNIX=Y to linux.config, but that made no difference.
    Dolu1990
    @Dolu1990
    that should have been enough
    weird
    and you rebuilded the whole buildroot from scratch ?
    Lawrie Griffiths
    @lawrie
    Yes, but we got the same error with screen on the old version of SaxonSoc.
    Dolu1990
    @Dolu1990
    ahhh
    Lawrie Griffiths
    @lawrie
    @emard I am wondering what is the best way to map the SaxonSoc Linux GPIO pins for the Ulx3s board. It can have a number of gpio peripherals each with a maximum of 32 each.
    It current maps the first 8 onto the leds and the rest to gp[8] onwards.
    gn[0] - gn[4] are used for the external jtag.
    Lawrie Griffiths
    @lawrie
    The pmod position at gn and gp 14-17 is used for the enc28j60 Ethernet board, and so needs one of the gpio interrupt pins.
    There are a limited number of gpio interrupt pins as they are expensive. There are currently 4.
    emard
    @emard
    If we can have multiple gpio, then gpio0 for leds, gpio1 for btns/dipsw, gpio2 for gp[0-27] gpio3 gn[0-27]. if some of gp/gn are covered with other function JTAG, SPI, RMII just skip them and make gpio non-functional but keep the numbering 0-27 if possible
    Maybe leds and btn/sw can be the same gpio0. And dont forget shutdown but it's better to be separate gpio, just not with LEDs because small mistake and shutdown :)
    Lawrie Griffiths
    @lawrie
    gp14 and gn14 and 15 are used for user spi, again for the enc28j60, or another spi peripheral using that Pmod position.
    If we are going to support USB in the future it might be good to keep the high-numbered gp and gn pins free for Goran's USB board.
    emard
    @emard
    I think it's the best to still have gp,gn[0-27] but gp,gn[14,15] will just not work
    Lawrie Griffiths
    @lawrie
    It would be good to have all the 6 buttons as interrupt pins, plus the SPI Pmod interrupt pin, which would make 7 gpio interrupt pins. That may be too many.
    emard
    @emard
    If the numbers on the board silkscreen matches the numbers of gpio, all will be good. If the bits are skipped and packed, users will just get confused
    Lawrie Griffiths
    @lawrie
    The multiple gpio peripherals by convention will be call gpioA, gpioB etc.
    emard
    @emard
    OK gpioA,B,C,D great. Interrupt pins are always useful to make any input efficient