Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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.

    drr
    @danrr_au_twitter

    interesting ISSI vs. winbond flash differences in this chat, I'd like to confirm that my stuff (doesn't) work on the ISSI but I only have a blue winbond board here

    @emard do you know if the ISSI parts on the ULX are preconfigured to have the QE enabled by default, if that's possible? I know for the winbond ones you can order them that way but otherwise the QE configuration must be done before trying quad cmds

    emard
    @emard
    @pnru_gitlab yes yes code has some size and everything works the same as compiled on gcc/PC :) so it's a proof lcc is doing very well. Instead of non-blocking probably also interrupt on incoming char or timer will make it. OK I can try few simple tricks on PC first and then the same on LCC
    emard
    @emard
    @danrr_au_twitter flash is nasty because it has memory that will never forget unless explicitely erased :). All of them were bought the same from Mouser, no factory preload of course. Quad can be enabled in the bitstream. FPGA first starts loading it in 1-bit mode slow and then depending on bitstream, switches to Quad and clocks faster. I have used many of them but usually only passthru and selftest and I avoid enabling Quad because then re-flashing from jtag becomes difficult. This flash is never used directly, but thru FPGA with either JTAG-SPI module or USRMCLK module
    I wouldn't say flash has entered quad mode because after failing saxonsoc bitstream, I upload passthru over jtag and from ecp5.py I can continue to talk to flash in 1-bit mode
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab I don't know exactly what was causing the fputc crash. fputc was working on the other two files. When I commented it out for the output file, I got crashes in other uses of the output files. I thought it might be something to do with lseek and fixing lseek fixed it.
    emard
    @emard
    @danrr_au_twitter how do I compile on ulx3s (or can you just provide flash image for 85F+32MB SDRAM)
    make ulx3s_prog
    Makefile:176: icestation-32/software/common/core.mk: No such file or directory
    make: *** No rule to make target 'icestation-32/software/common/core.mk'.  Stop.
    emard
    @emard
    @pnru_gitlab is select() and termios available?
    drr
    @danrr_au_twitter

    @emard Need the submodule cloned to get that file:

    git submodule update --init --recursive
    make ulx3s_prog

    this works for me on a fresh clone, otherwise please share the error and I can make the bit / flash

    emard
    @emard
    OK that countinued but complained on make: riscv-none-embed-cpp: but I have riscv64-linux-gnu-gcc so I will try to fix it later it will probably work
    not, now 28 | # error "rv32i-based targets are not supported"
    better the bitstream if we just need to check flash
    drr
    @danrr_au_twitter
    fujprog -j flash -f 0x200000 prog.bin
    fujprog ulx3s.svf
    @emard This works on my 85F + WInbond. SDRAM is not used.
    emard
    @emard
    Small detail - I dont have DVI monitor here. If I plug 3.5mm earphones should I hear music?
    or some LEDs blinking