Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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
    Lawrie Griffiths
    @lawrie
    The enc28j60 does not currently work as its interrupt pin is mapped incorrectly. @Dolu1990 is currently fixing that.
    emard
    @emard
    So lets say gpioA[0-27]=gp[0-27] gpioB=gn[0-27] minus specialized hardware spi eth rmii usb when compiled. If such hardware is not compiled you have full gp[0-27] control. gpioC=btns,switches, gpioD=leds, gpioE=ESP32 connectivity, gpioF=shutdown programn and other special board pins
    Full featured gpio that supports 3-state and interrupts is usually heavy so at f32c we have also "simpleio" those are "lite" gpio which are fixed direction in or out and have no interrupt, pwm etc
    emard
    @emard
    If you can mix in/out directions then I think LEDs and BTNs SWs can go be same gpio and save some luts
    Dolu1990
    @Dolu1990
    in the interrupt controller in saxon, you can specify which pin will support interrupts, hopefully it will not burn to much logic
    Issue currently is that for each pin it alocate one plic interrupt ID
    which is quite no free XD
    Lawrie Griffiths
    @lawrie
    @emard we will probably also want an RMII board mapped to one of the Pmod positions.
    emard
    @emard
    At cortex linux, we have some simple i2c controller that has two 32-bit R/W registers and all i2c traffic is done with them. LAN8720 RMII is gp/gn[9-13] directly plugged. gn[12] is 50MHz clock that must be taken from RMII and used as data clock domain
            alias rmii_tx_en : std_logic is gn(10);
            alias rmii_tx0   : std_logic is gp(10);
            alias rmii_tx1   : std_logic is gn(9);
            alias rmii_rx0   : std_logic is gn(11);
            alias rmii_rx1   : std_logic is gp(11);
            alias rmii_crs   : std_logic is gp(12);
            alias rmii_nint  : std_logic is gn(12); -- clock is here 50MHz
            alias rmii_mdio  : std_logic is gn(13);
            alias rmii_mdc   : std_logic is gp(13);
    constraints lpf file
    FREQUENCY PORT "gn[12]" 50.00 MHZ;
    emard
    @emard
    You can't plug RMII anywhere else directly because clock input capable pin of FPGA wont match RMII clock output