Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab @emard I looked at the lcc risc-v compiler a bit. The compiler generates as output a .s assembler file. The assembler (as) in binutils and ld produce a.out format files. This is now deprecated in Linux and not supported in 64-bit systems. I am not sure if it is supported in the 32-bit buildroot system that SaxonSoc uses. It probably needs configuration options to include it (CONFIG_HAVE_AOUT, CONFIG_BINFMT_AOUT).
    emard
    @emard
    For me, anything that native compiles to exe is good, I don't care for intermediate *.s files. I think also cortex compiler does the same
    Paul Ruiz
    @pnru_gitlab
    @lawrie There are a few routes that you could consider. One is to use the LCC compiler output with the GNU binutils (as, ld, etc.). This would give at least give you a quick way to check. However, probably the binutils are as fat as gcc itself. Your other route is to build an a.out to elf converter. For static binaries this is maybe not too hard a thing to do. Extracting a binary from a.out is very easy and wrapping that in a minimal elf header sounds doable as well. It does require diving into the details of elf, which might be very time consuming.
    Paul Ruiz
    @pnru_gitlab
    @emard The cortex compiler also goes via .s files. If you do cc -v hello.c you can see the individual steps. First it runs the pre-processor (turning .c into .i) and then the c0 pass. This pass essentially converts C source into parse trees. This is followed by the c1 pass, which uses a tile covering algorithm to convert the parse trees into assembler (i.e. generating a .s file). Optionally, there is a c2 pass which does peephole and a few other optimizations. Then it runs the assembler 'as' to generate a relocatable object file (an .o file). As a last step it invokes the linker ld to combine this object file with routines from the C library and generating a static binary (the a.out file).
    By the way, I got the compile time for hello.c down from 14s to 8s now, mainly through better sorting of the C library archive. The linker still takes half of total compilation time.
    emard
    @emard
    8s is super-comfortable! Btw I wonder how did cortex start, before it ever booted they need some filesystem to hold files. Is cortex filesystem mountable by modern linux? How did they made it in early times?
    Lawrie Griffiths
    @lawrie
    I suspect the GNU binutils will drag in a lot of stuff, so I am not too keen on that. a.out format may be supported, so that may still be an option, but Linux will probably not support it for a lot longer. I did consider an a.out to elf converter. I think there is a fairly simple subset of elf.
    emard
    @emard
    When linux drops a.out, some new riscv-friendly cc solution may appear. Most of riscv systems are small and I guess are looking for native compilers
    Paul Ruiz
    @pnru_gitlab
    @lawrie here is a fun post about wrapping an executable in a minimal elf shell: https://www.muppetlabs.com/~breadbox/software/tiny/teensy.html
    The middle part of the write up is the most interesting for the problem at hand, I think.
    Paul Ruiz
    @pnru_gitlab
    @emard Or they move to a leaner kernel than standard Linux - maybe uClinux, maybe Plan9, etc.
    emard
    @emard
    @pnru_gitlab ahahhaaa fantastic writeup this about elf stripper! It was thrilled text and I thought that it would make exe that returns 42 also 42 bytes long, but it turned out to have 45 bytes! Almost! Still amazing article :)
    Lawrie Griffiths
    @lawrie
    Yes, very amusing.
    emard
    @emard
    And for practical side of about some simple i2c (RTC) and SPI (display) things on saxonsoc, what are our other options - can micropython do it to properly intialize i2c and spi bus at saxonsoc. Micropython has "viper" options on some platforms that compiles integer-only python code to something that runs at near C speed
    Paul Ruiz
    @pnru_gitlab
    Wikipedia has some practical overview information:
    https://en.wikipedia.org/wiki/Executable_and_Linkable_Format
    Also this tool may provide a place to start when writing an a.out to ELF converter:
    http://elfdump.sourceforge.net
    And 42 is of course the Answer to the Ultimate Question of Life, the Universe, and Everything
    emard
    @emard
    Yes, yes making exe file size from 45 to 42 would require infinite amount of time and energy, something like accelerating from 99% speed of light to 100% :)
    Paul Ruiz
    @pnru_gitlab
    @emard if your goal is to provide an easy environment for working with i2c and SPI devices, why not add Lua to your pre-built Linux/Saxon system? Conceivably, you could also run Lua on bare metal nano Risc-V.
    emard
    @emard
    It is also good idea!
    Paul Ruiz
    @pnru_gitlab

    8s is super-comfortable! Btw I wonder how did cortex start, before it ever booted they need some filesystem to hold files. Is cortex filesystem mountable by modern linux? How did they made it in early times?

    The Cortex was a traditional home computer with Basic in its day. Running Unix on it was my project some 6-7 years ago. It was a long journey: porting a C compiler and tool chain, building simple kernels with a linked in user program (downloaded to the H/W via something similar to S-records), etc. When the time for disk access came, I used a tool to create & manage disk images.

    For the original Unix, the file system was almost the first thing that was built, after the assembler (that is how a.out got its name: assembler output). An empty disk image was written by a custom format program. Files were then loaded from paper tape. Some 1969/1970 Unix code can be found here:
    https://www.tuhs.org/cgi-bin/utree.pl
    In its first incarnations it was all assembler, but many of the core ideas were already there. Some more background is here:
    https://www.bell-labs.com/usr/dmr/www/hist.html

    emard
    @emard
    Ahaaaa so unix was not all the time available on cortex hardware. Still I'd wanted to know how did you initially start with populated filesystem. Normally e.g. if we have linux on riscv, we can mount the same partition on x86 PC, copy files and and it will work on riscv, but how was this done on cortex?
    emard
    @emard
    So If I understood, you have a tool that from a directory creates disk image, but there's currently no support to actually mount cortex fs on linux for example. linux has some possibility to write a user-space fs driver like "fuse" but I ghess thats difficult and fragile
    Paul Ruiz
    @pnru_gitlab

    You can follow my journey here, in 315 commits:
    https://www.jslite.net/cgi-bin/9995/timeline?n=400&y=all&v=0

    I use a program ("ufs") which creates a disk image from scratch and then adds files to it. The source code is here:
    https://www.jslite.net/cgi-bin/9995/dir?ci=84b2a75947eb76db&name=fsutil

    Even on the mini Cortex hardware, the CF Card uses FAT formatting and has an image file on it. I make sure the image is contiguous and the boot loader lets the Unix disk driver know in which sector the image starts. This way I can simply copy disk images to the CF card without needing to use special tools.

    Actually, the card also has disk images for other OS's as well - MDEX and NOS, which are somewhat similar to CP/M and MS-DOS 3 respectively.

    emard
    @emard
    There has been a lot of concentrated effort! The idea to use contiguous file in FAT is very good, so the CF itself can be easily written from laptop.
    Paul Ruiz
    @pnru_gitlab
    Thank you. The ulx3s Cortex has it even easier: because of the ESP32, now I don't even have to worry about things being contiguous and I can ftp disk images without having to handle the SD card.
    emard
    @emard
    yeees it was a piece of luck that for esp32 appeared good micropython support with almost all important things working and that spi-jtag adventure turned out successful. I have ulx3s with SD in a box and once inserted SD I never move out, just ftp files. Things will be even better when WROVER-E prototype starts working, 4MB RAM, 16MB FLASH no more out of memory. Bitstreams could be unzipped on-the-fly, even larger FLASH chips supported with 64K and 256K erase blocks (esp32 must buffer data size of erase block and now we are struggling with 4K buffers)
    Kristin Davidson
    @aphistic
    Hey! I saw the news on crowdsupply that the preorders are on their way to mouser, congrats! I was curious if there's any idea when those might start arriving to people? I know that's an annoying question, so feel free to ignore it. The reason I ask is because I'll have 3 weeks of free time in the beginning of October and I'm hoping to be able to start experimenting. Only problem is I won't be able to receive any shipments after the last week of September, so I'm curious if it might arrive before then.
    emard
    @emard
    Currently all I know that shipment with about 800pcs of ulx3s is in Köln germany, first it needs to reach mouser, USA then they will ship. Normally if everything else is fast you should get one in USA if you live in popular cities. If you are on some island near canada, it will travel thru usa additional month
    Goran Mahovlic
    @goran-mahovlic
    @aphistic Today packet was released from Germany and it is on the way to Mouser - They should have it next week. Then they need to add those boards to system and they will ship campaign orders first. Mouser is using fast shipping service like DHL and FedEX so it usually takes few days to get in US/EU and probably few days more to reach other countries ...
    e2kgh
    @e2kgh
    ULX3S is a "Power Management IC Development Tools ULX3S with ECP5 12F" at mouser.com ;-)
    emard
    @emard
    Yes that seems to be first iteration while guessing where it should belong :). I wanted the board to work as big SMPS and motor control board. They seem to be able to read thoughts remotely :)
    Kristin Davidson
    @aphistic
    @goran-mahovlic @emard great! sounds like there's a good chance I'll get it just before I leave then. thanks! :)
    Goran Mahovlic
    @goran-mahovlic
    @pietrushnic Boxes are in US waiting for clearence.
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab @emard I finished the QL sound with an attempt at everything (increments, wrap, random, fuzz), but I don't know how close to the original it is.
    emard
    @emard
    Ohoohooo I must test :)
    Kid CUDA
    @KidCUDA_gitlab
    anyone used a PS2 keyboard with ULX3S?
    like a proper PS2 keyboard with the pins adapted to USB?
    is a level shifter needed or is the USB port 5V-data-tolerant?
    from the schematic it doesn't look 5V tolerant but I'm not sure how else it would work with just a pure PS2 adapter as suggested in the docs
    emard
    @emard
    @KidCUDA_gitlab US2 pins are 5V tolerant, limited by R and Zener diodes. Still some PS/2 keyboards don't accept 3.3V levels. Best is to obtain combo PS/2+USB they usually work in both modes for ULX3S
    PS/2 is normally used over OTG connector for most of our retro-computing cores, apple1-2, ti99, zx, vic20, QL just to name a few
    Lawrie Griffiths
    @lawrie
    SaxonSoc 2-CPU version on Ulx3s 85F:
    root@buildroot:~# cat /proc/cpuinfo
    processor       : 0
    hart            : 1
    isa             : rv32im
    mmu             : sv32
    
    processor       : 1
    hart            : 0
    isa             : rv32im
    mmu             : sv32
    Lawrie Griffiths
    @lawrie
    A 3-CPU version also runs, but a 4-CPU version did not, probably due to failing the timing by too much.
    e2kgh
    @e2kgh
    @lawrie " how much of the 85F does the 2-Core version use?
    Lawrie Griffiths
    @lawrie
    From memory it was 36%
    But apparently it takes a lot less if built with Lattice Diamond rather than the open source tools.
    Lawrie Griffiths
    @lawrie
    Info: Device utilisation:
    Info:            TRELLIS_SLICE: 15356/41820    36%
    Info:               TRELLIS_IO:    83/  365    22%
    Info:                     DCCA:     3/   56     5%
    Info:                   DP16KD:    48/  208    23%
    Info:               MULT18X18D:     8/  156     5%
    Info:                   ALU54B:     0/   78     0%
    Info:                  EHXPLLL:     1/    4    25%
    Info:                  EXTREFB:     0/    2     0%
    Info:                     DCUA:     0/    2     0%
    Info:                PCSCLKDIV:     0/    2     0%
    Info:                  IOLOGIC:    39/  224    17%
    Info:                 SIOLOGIC:     0/  141     0%
    Info:                      GSR:     0/    1     0%
    Info:                    JTAGG:     0/    1     0%
    Info:                     OSCG:     0/    1     0%
    Info:                    SEDGA:     0/    1     0%
    Info:                      DTR:     0/    1     0%
    Info:                  USRMCLK:     1/    1   100%
    Info:                  CLKDIVF:     0/    4     0%
    Info:                ECLKSYNCB:     0/   10     0%
    Info:                  DLLDELD:     0/    8     0%
    Info:                   DDRDLL:     0/    4     0%
    Info:                  DQSBUFM:     0/   14     0%
    Info:          TRELLIS_ECLKBUF:     0/    8     0%
    Info:             ECLKBRIDGECS:     0/    2     0%
    e2kgh
    @e2kgh
    Does the 4-Core fail on Diamond too?
    Lawrie Griffiths
    @lawrie
    I don't have Diamond installed to test it at the moment.
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab @emard I have started looking at riscv_lcc. It is not straightforward to cross-compile. Some parts (such as lburg) seem to be compile-time utilities so need to be natively compiled. Then I had some problems with the run time library. There were problems with getcwd not being found. I commented out the code that used that, as it did not look critical, Then there was a problem with getopt being duplicated, so I omitted the getopt.c source. I could then compile some of the directories.
    The way the build happens seems to be that a binary called rcc is compiled using gcc, and then that is used to recompile the source, producing the lcc binary. I could compile rcc, but not lcc as the latter had some missing library routines, such as access.