Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    emard
    @emard
    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?
    Paul Ruiz
    @pnru_gitlab

    I think system call 62 in Riscv32 Linux is _llseek:
    https://man7.org/linux/man-pages/man2/_llseek.2.html
    It appears to have 5 arguments of 32 bits each (x12-x16).

    The library appears to use only lseek and _lseek, expecting them to be the same. The wrapper for both could be:

    long lseek(int fd, long offs, int whence)
    {
        long ret[2];
    
        _llseek(fd, 0, offs, &ret[0], whence);
        return ret[0];
    }
    Lawrie Griffiths
    @lawrie
    I have a test of llseek working,
    #include <sys/types.h>
    #include <unistd.h>
    #include <errno.h>
    #include <stdio.h>
    #include <fcntl.h>
    
    struct loff {
      long offset0;
      long offset1;
    };
    
    typedef struct loff loff_t;
    
    extern int _llseek(unsigned int fd, unsigned long offset_high,
                       unsigned long offset_low, loff_t *result,
                       unsigned int whence);
    main() {
      int fd;
      char buf[32];
      int r, err;
      loff_t result;
    
      fd = open("test.txt",O_RDONLY);
    
      errno = 0;
      r = _llseek(fd, 0, 8, &result, SEEK_SET);
      err = errno;
    
      printf("Result: %d\n",r);
      printf("errno: %d\n",err);
    
      printf("Offset 0: %d\n", result.offset0);
      printf("Offset 1: %d\n", result.offset1);
    
      read(fd,buf,2);
      printf("Second row:\n");
    
      write(1,buf,2);
    
      return 0;
    }
    And with a dummy lseek the lcc-compiled as does not fail, but obviously produces the wrong output.
    So I will try your version of lseek.
    Lawrie Griffiths
    @lawrie
    I had to define _lseek as well as a copy of your lseek as the library uses that.
    With those in place, the lcc-complied assembler seems to produce the same output as the gcc-compiled one.
    root@buildroot:~# as -o as.o as.s
    Assembling module 'as.s'...
    root@buildroot:~# ./a.out -o as1.o as.s
    Assembling module 'as.s'...
    root@buildroot:~# diff as.o as1.o
    Lawrie Griffiths
    @lawrie
    And the lcc-compiled one is faster:
    root@buildroot:~# time ./lccas -o as1.o as.s
    Assembling module 'as.s'...
    real    0m 2.28s
    user    0m 2.11s
    sys    0m 0.17s
    root@buildroot:~# time as -o as1.o as.s
    Assembling module 'as.s'...
    real    0m 3.01s
    user    0m 2.80s
    sys    0m 0.17s
    emard
    @emard
    https://github.com/emard/tetris4terminals HI I found some low level tetris and lcc compiles it but to be playable it needs non-blocking getchar and putchar. Can LCC do it - if not dont make too much development prilority for this, its just a ugly game
    Paul Ruiz
    @pnru_gitlab

    @lawrie: that is a great result! What was the issue with the fail on fputc? In any case, as is a non-trivial 3,000 line C program. That it compiles and works correctly gives a lot of confidence in what we have now. Maybe the gcc version will be faster if compiled with -O2.

    @emard: I think the game code needs raw input as well as non-blocking. What the current LCC lib offers is ioctl() and you can use it to achieve both, I think.