Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Dolu1990
    @Dolu1990
    200 us
    emard
    @emard
    should be okk
    Dolu1990
    @Dolu1990
    datashet say 30 us, but margin never hurt
    emard
    @emard
    I tried almost all combination software reset before 0xAB, after, both, none and reading with 0xB command all works in every combination on ISSI chip from micropython
    Are those all flash commands used: 0x66, 0x99, 0xAB, 0x0B
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab There is still a problem with lcc C library - the exit function crashes, but_exit is OK. I just built it on SaxonSoc and when I run it, it hits that problem.
    Dolu1990
    @Dolu1990
    yes
    e2kgh
    @e2kgh
    Ok, after recompile I got those bytes from flash:
    SDRAM init
    Mem test .. pass
    Flash ID : 0xFF
    OpenSBI copy
    U-Boot copy
    Image check .. OpenSBI missmatch
    15C83919 F468FE56
    emard
    @emard
    I have tested flash by first entering to deep sleep mode. Flash returns 0xFF constanty when in deep sleep. The correct wake sequence is first to issue 0xAB to wake up. Issuing 0x66 0x99 later doesnt matter but 0x66 0x99 itself will not wake up from deep sleep, behaves consistent an in datasheet
    @e2kgh I get 0xFFFFFFFF to opensbi mismatch
    Something is not identical with our boards. But 0xFF of flash ID means 0xAB command didnt succeed and nothing further can work
    Still it is strange how did you later get non-0xFFFFFF return of reading
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab I added your functions to my fork, and I also needed unlink (as I only had unlinkat) - lawrie/riscv32_lcc@a61b173
    emard
    @emard
    ISSI Flash supports SPI mode 0 and mode 3. maybe this...
    0xAB will be ignored if it is issued when FLASH is already processing something else like erase block or similar
    Paul Ruiz
    @pnru_gitlab
    @emard maybe there is a delay for wakeup from deep sleep to become effective? Just guessing.
    Dolu1990
    @Dolu1990
    would realy need remote access to debug that properly XD
    that's possible
    emard
    @emard
    @pnru_gitlab possible, Im testing it using micropyhton (slow) and I don't need to add any extra delays. Still I think micropython reads it in 50ms after wakeup and all is ok
    Yes remote openocd debug is what we must next do. I cant setup my networking now, only if e2kgh has better situation
    Paul Ruiz
    @pnru_gitlab
    @lawrie: not sure I understand the exit/_exit problem. You mean that it works with an extra _exit(0) at the end of main and does not when you just return from main? Is that for a simple test file or something else?
    Lawrie Griffiths
    @lawrie
    No a call to exit(0) crashes, but _exit(0) does not. Return from main without exit is fine.
    Dolu1990
    @Dolu1990
    remote openocd debug else SSH <3
    Lawrie Griffiths
    @lawrie
    @emard I have updated Smp/bitstreams/ulx3s_85f_green_2core_saxonsoc.bit. On a blue 85f it gives:
    
    SDRAM init
    Mem test .. pass
    Flash ID : 0x17
    OpenSBI copy
    U-Boot copy
    Image check .. pass
    Paul Ruiz
    @pnru_gitlab
    @lawrie - ok that makes sense: as we have it returning from main is almost the same as calling _exit() so that is a relief. The main function of exit() over _exit() is to call the "atexit" functions before doing the real exit. The stdio lib uses this to register a function that flushes all buffers before exit. Probably something goes wrong there.
    emard
    @emard
    @lawrie I will test - as you can see, you have winbond on blue 85F but ID returns 0x17. I found it in images instead of bitstreams :) and does uImage actually need update to see new flash id messages?
    Paul Ruiz
    @pnru_gitlab
    @lawrie I will see if I can replicate the issue on the simulator when I have time - probably not today.
    Lawrie Griffiths
    @lawrie
    @emard Moved to correct place. uImage does not need changing.
    emard
    @emard
    OK
    Lawrie Griffiths
    @lawrie
    These changes are in the bootloader which is in BRAM in the bitstream.
    Lawrie Griffiths
    @lawrie
    It immediately dereferences atexit which will be zero, and crashes.
    I am thinking of changing line 19 to:
    static struct atexit *head = NULL;
    struct atexit **__atexit = &head;
    That works, but I have not tested atexit functions.
    The li x0,0 instructions in exit.s are odd.
    emard
    @emard
    SDRAM init
    Mem test .. pass
    Flash ID : 0xFF
    OpenSBI copy
    U-Boot copy
    Image check .. OpenSBI missmatch
    FFFFFFFF FFFFFFFF
    Paul Ruiz
    @pnru_gitlab
    I think you are right about exit. Probably we are missing some setup in crt0.s that this code expects. I've been looking for the exact version of BSD Unix that this libc seems to derive from. The best I could find so far is 4.4BSD and the relevant files are here:
    https://www.tuhs.org/cgi-bin/utree.pl?file=4.4BSD/usr/src/lib/libc/stdlib
    It is not an exact match though.
    If you look at atexit.h, atexit.c and exit.c you'll see that these take a similar approach as the one that you are suggesting. By the way, stdio uses its own custom link, __cleanup.
    Lawrie Griffiths
    @lawrie
    Yes, I did the same as you and looked for bsd versions and looked at atexit.c and atexit.h. I think the solution I have will probably work. The lcc as is now failing because fcntl.h valuers are still wrong for creating files.
    emard
    @emard
    all 0xFF at my "green" 85F. Could be SPI interface. Is phase delay of SPI CLK thru USRMCLK FPGA module small enough to be neglected? Other SPI signals than CLK travel different path. Also for some reason USRMCLK has input for CS too, does it need to sync CLK to be glitchless regarding CS, I dont know but in my cores if I havent connected CS to USRMCLK it didn't work.
    Dolu1990
    @Dolu1990
    On USRMCLK, i just it for the clock
    Hmm on ulx3s, the bootloader run the SPI at 8.33 Mhz
    which is quite slow, so i would say the delay can be neglicted
    Paul Ruiz
    @pnru_gitlab
    @lawrie as to the li x0, 0 instructions, that looks like a missed optimization opportunity. All integer constants are loaded via this template, and it seems that the zero case is not optimized.
    Lawrie Griffiths
    @lawrie
    The lcc-compiled as is crashing in fputc now, after producing some temporary files.
    Lawrie Griffiths
    @lawrie
    But a test of fputc works fine.
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab If seems that any access to the output file causes a crash. One issue if that all the files that as uses, use fseek or rewind, and I haven't sorted out lseek and llseek yet.
    Paul Ruiz
    @pnru_gitlab
    For my understanding: any access to the output file causes a crash - that is any access via "outFile"? If so, many accesses to "codeFile" and "dataFile" have already worked. Is this what you meant?