Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    emard
    @emard
    dowloading extra fresh!
    Lawrie Griffiths
    @lawrie
    I will add setpriority, getprioriity, mkdir and rmdir.
    I don't know what the Linux system calls are for time and stime - perhaps settimeofday, gettimeofday.
    Lawrie Griffiths
    @lawrie
    I don't know what the parameters are for signalfd4, but as you say, we can leave signals for the moment.
    @pnru_gitlab Not sure how do do rmdir. I have unlinkat - perhaps that does it.
    Paul Ruiz
    @pnru_gitlab
    Yes: https://linux.die.net/man/2/unlinkat
    AT_REMOVEDIR is defined as 0x200
    Paul Ruiz
    @pnru_gitlab
    time and stime are clock_gettime and clock_settime on Linux:
    https://man7.org/linux/man-pages/man2/clock_settime.2.html
    Use CLOCK_REALTIME as the clock id (= 0).
    Paul Ruiz
    @pnru_gitlab
    For signals, the right base call is probably sigaction. I've been too focussed on ancient Unix it seems.
    https://man7.org/linux/man-pages/man7/signal.7.html
    Lawrie Griffiths
    @lawrie
    OK, I have added mkdirat, sigaction, clock_gettime, clock_settime, gettimeofday, settimeofday, getpriority and setpriority.
    That should be enough system calls for now. I need to look into wrappers next.
    Lawrie Griffiths
    @lawrie
    I have updated both riscv32_lcc.tar.gz and https://github.com/lawrie/riscv32_lcc/blob/master/lcc/bin/libs/stdlib/syscall.s with the latest system calls.
    emard
    @emard
    getting
    Lawrie Griffiths
    @lawrie
    It won't be much different to the previous one as the new system calls are untested.
    Paul Ruiz
    @pnru_gitlab
    @emard maybe enough works already to compile lcc's assembler.
    emard
    @emard
    I just downloaded and void main(void) printf exits correctly without return 0;. So much functions are added, I need to probably test only time-setting functions
    Lawrie Griffiths
    @lawrie
    One problem with clock_gettime and clock_settime is that tv_nsec (nanoseconds) needs a 64-bit long. A more minor problem, is that the C library does not have the relevant structs sand typedefs defined.
    Lawrie Griffiths
    @lawrie
    #include <stdio.h>
    #include <time.h>
    
    #define CLOCK_REALTIME 0
    
    typedef int clockid_t;
    
    struct timespec {
      time_t tv_sec;
      long tv_nsec;
    };
    
    int main(int argc, char **argv)
    { 
      int result;
      struct timespec tp;
      clockid_t clk_id;
    
      clk_id = CLOCK_REALTIME;
    
      result = clock_gettime(clk_id, &tp);
      printf("result: %i\n", result);
      printf("tp.tv_sec: %lld\n", tp.tv_sec);
      printf("tp.tv_nsec: %ld\n", tp.tv_nsec);
    
      return 0;
    }
    Nanoseconds overflow after about 2 seconds on 32-bit systems.
    emard
    @emard
    hwclock is not likely to execute more than 2 seconds :). It's not related, but if possible I'd also like to try 12F 2-core version if you compile next time upload some 12F smp too
    full wraparound is 4.3s but for signed intverval comparison useable delay is 2.15s
    emard
    @emard
    clock_settime works
    Lawrie Griffiths
    @lawrie
    I am not sure if a 2-cpu system will fit on a 12f. I am trying it.
    emard
    @emard
    Ahaaa, it's not necessary dont worry, if it compiles great, if not, don't optimiize
    emard
    @emard
    I got segfault with atoi(argv[1]) wanted to convert string to integer, any other way? Still I can do it low-level though
    Lawrie Griffiths
    @lawrie
    This works (provided you give in an integer arg):
    #include <stdlib.h>
    
    int main(int argc, char *argv[]) {
      return atoi(argv[1]);
    }
    emard
    @emard
    I got segfault with this
      printf("argc %d\n", argc);
      if(argc > 0)
      {
        val=atoi(argv[1]);   
        printf("argv[1] %d\n", val);
      }
    oh but now I cant reproduce it! :)
    anyway consider it just a glitch...
    Lawrie Griffiths
    @lawrie
    It works for me. But there are obviously still some bug around.
    emard
    @emard
    If something more stubborn bug appears, I'll report, so far so good :)
    Paul Ruiz
    @pnru_gitlab
    I'm surprised get/set_time work in the above. If I understood correctly Risc-V32 Linux uses a 64-bit time type, but LCC does not have 64 bit types and its library defines time_t as 32-bit. Hence the above code passes a buffer with space for two 32-bit words, and the kernel then writes/reads three 32 bit words to/from that space. Maybe time_t is 32 bit on Risc-V32 Linux after all.
    Paul Ruiz
    @pnru_gitlab
    hwclock is not likely to execute more than 2 seconds :). full wraparound is 4.3s but for signed intverval comparison useable delay is 2.15s
    Not sure that is right. I think tv_nsec cycles from 0 to 999999999 and back to 0, increasing tv_sec atomically.
    Paul Ruiz
    @pnru_gitlab
    I got segfault with this if(argc > 0) That should maybe be if(argc > 1) and maybe that crashing test by accident did not have a valid pointer in argv[1].
    Dolu1990
    @Dolu1990
    I have a strange case with a 12F board, depending the seed i use in next-pnr, the design work, or bug in different manners. The FPGA is used as if it was a 25F. Could that be that the device sold as a 12F has broken logic in the 25F side, which depending the seed is hit ?
    emard
    @emard
    @pnru_gitlab I was setting only seconds to 1973 :) who knows for later dates
    @Dolu1990 no, 12F==25F
    David Shah
    @daveshah1
    Diamond just limits the total number of LUTs, afaik, so there isn't a '25F' side
    Sounds like some other bug tbh
    Your nextpnr is from the last few months right?
    Dolu1990
    @Dolu1990
    Ahhh, got it, diamond is allow to use lut of the FPGA without restrictions, until 12K
    thanks ^^
    I'm on next-pnr version 5fa10e1
    David Shah
    @daveshah1
    I would recommend updating nextpnr and trellis
    Dolu1990
    @Dolu1990
    which is quite old, hmm weird, i would have say from memory that it was a few months old XD
    will do ^^
    David Shah
    @daveshah1
    Some time around March/April I fixed a bug that would cause random failures, particularly for designs using certain IO pins
    Those IO pins happened to include some ULX3S SDRAM pins - since that fix I think reliability has improved