Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    e2kgh
    @e2kgh
    Was thinking, about sending you my "green" board ;-)
    Dolu1990
    @Dolu1990
    XD
    e2kgh
    @e2kgh
    How would I actually attempt to port SaxonSoc to a different board? I have something here which is similar to the arty-a7, and also one, close to the ulx3s? Is there a good pointer, link?
    Paul Ruiz
    @pnru_gitlab
    @lawrie: great! I think this bug was also the cause of the failure for statx. I think there are no other bug reports at the moment and all appears to work. It would be good to know if lcc-compiled as yields the same output as gcc-compiled as. A test case would be to generate "as.s" with lcc -S as.c and then assembling that "as.s" with both versions of as. If the resulting a.out files are the same, we should be good.
    Dolu1990
    @Dolu1990
    @e2kgh So, there is no good link, only existing SoC to copy and modify

    basicaly each port is mainly made of its BSP :
    https://github.com/SpinalHDL/SaxonSoc/tree/dev-0.1/bsp/radiona/ulx3s/smp

    And its SoC RTL :
    https://github.com/SpinalHDL/SaxonSoc/blob/dev-0.1/hardware/scala/saxon/board/radiona/ulx3s/Ulx3sSmp.scala#L34

    I have to say, it is quite exotic ^^

    quite a experimental framework
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab @emard This is my attempt at scripting the whole build of the linux version of riscv32_lcc - https://github.com/lawrie/riscv32_lcc/blob/master/mklinux.sh
    e2kgh
    @e2kgh
    @lawrie : the "saxon_update" is not checked in yet?
    Dolu1990
    @Dolu1990
    this ? :
    https://github.com/SpinalHDL/SaxonSoc/commit/bb9e61cd0a9174a1267797b32608e858572b0090#diff-659c1ba329c6d2cf3f2e27966474ad60R21
    e2kgh
    @e2kgh
    @Dolu1990 : Sorry, new to this whole thing, and looked in the wrong file. And, it came in, after I updated my git, so didn't see it yet :(
    Dolu1990
    @Dolu1990
    no worries ^^
    emard
    @emard
    @Dolu1990 @lawrie Can a print be done for 4 th byte (the byte after reading 3 dummy bytes received after 0xAB command), Flash should respond by 0x17 its described on page 58 of flash datasheet http://www.issi.com/WW/pdf/IS25LP128.pdf
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab In order to do your lcc-compiled as test, I will need to build an lcc-compiled version of as, and for that I will need your two library routines, so can you give me the source of them.
    Paul Ruiz
    @pnru_gitlab
    Here you go: https://gitlab.com/pnru/ulx3s-misc/-/tree/master/tmp/lcc-riscv/libc
    Upon first read your build script looks ok to me.
    Dolu1990
    @Dolu1990
    @emard I'm adding it
    emard
    @emard
    All flashes I know mounted on ulx3s return 0x17 at this place, so it is indication that 0xAB command itself worked and that SPI interface works also.
    Dolu1990
    @Dolu1990
    hmm on my board i got a 0x15
    ahhh because that's a winbond
    Ok
    I will also add a soft reset command
    to be sure all the registers are set to default
    emard
    @emard
    I must check on winbond is it really 0x15 returned there
    Dolu1990
    @Dolu1990
    it does
    i checked
    in datasheet
    emard
    @emard
    I have some early winbond with the same labeling on the chip which returns 0x17 if I issue 0xAB from ecp5.py
    But yours may be different inside although outside labelled the same
    Dolu1990
    @Dolu1990
    I pushed the update on SaxonSoc git
    emard
    @emard
    Great! In next compiled binary release I will look what is printed at boot
    Dolu1990
    @Dolu1990
    it also removed the 4 extra bytes on the wake command
    emard
    @emard
    What is wake command hex? I thought 0xAB is used as wake
    I want to reproduce on ecp5.py the same flash commnd if I can find that it makes chip go nuts
    Dolu1990
    @Dolu1990
    it is
    but with single byte
    with the 4 extended bytes it become another command
    emard
    @emard
    it is <which hex>?
    Dolu1990
    @Dolu1990
    ?
    0xAB => wake up
    0xAB 0xZZ 0xZZ 0xZZ 0xDeviceId => read device id
    Maybe the behaviour of the read device ID is different between the two vendor, on one it also wake up, on the other it don't ?
    I don't know
    But for sanity i fix it to better match the datasheet XD
    Maybe the software reset of the flash will fix the current issue, maybe that corrected wake up will, maybe the issue will remain ^^
    emard
    @emard
    Aha but that is 0xAB issued twice. At least from ISSI datasheet 0xAB is dual function command, regardless how many bytes are shifted later it will wake up chip and return ID. on winbond (mine) it returns 0xFF 0xFF 0xFF 0x17 0x17 ...
    dual function is that it 1:wakes up and 2:returns id
    The same sequence is on ISSI (first 3 0xFF, rest 0x17 repeating)
    emard
    @emard
    What is hex of software reset command, let me try that also
    e2kgh
    @e2kgh
    @Dolu1990 : saxon_update, doesn't update the saxonsoc.git here. On purpose?
    Dolu1990
    @Dolu1990
    Hooo f* me XD
    sorry
    not on purpose