Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    emard
    @emard
    esp32ecp5: micropython v1.13 has bug with uftpd file listing, last file is listed with wrong name. bug is in micropython "for fname in os.listdir():" iterator loop. Use v1.12 for now
    Lawrie Griffiths
    @lawrie
    I have a 4-cpu 85F SaxonSoc version with music, working now.
    Lawrie Griffiths
    @lawrie
    It is now inSmp/bitstreams/ulx3s_85f_blue_4core_saxonsoc.bit
    I renamed images as oldimages and the new one are in Smp/images.
    You need dtb, uImage and you need to untar the new rootfs.tar.
    You will also need:
    root@buildroot:~# cat .asoundrc
    pcm.!default {
        type            plug
        slave.pcm       "softvol"   #make use of softvol
    }
    
    pcm.softvol {
        type         softvol
        slave {
            pcm         "hw:0,0"      #redirect the output to dmix (instead of "hw:0,0")
        }
        control {
               name        "PCM"       #override the PCM slider to set the softvol volume level globally
            card     0
        }
    }
    emard
    @emard
    auuuuuu currently with me I have only green85f where I expect booting issues but I will try anyway.
    Lawrie Griffiths
    @lawrie
    To play music do: mpg123 -T -f 4096 -m file.mp3.
    Or to play in the background nohup mpg123 -T -f 4096 -m file.mp3 &
    It is set up for a 64MB blue 85f.
    emard
    @emard
    If 85F won't boot, is also 12F possilble?
    Lawrie Griffiths
    @lawrie
    Yes, I had a 1-cpu 12F version working. I will rebuild that.
    emard
    @emard
    Ill try both, something will work!
    Dolu1990
    @Dolu1990
    .asoundrc isn't necessary, it just add volume controles in alsamixer app
    I would suggest to not add the .asoundrc for single core versions, as it add quite a bit of overhead
    the -m of mpg123 is for mono, if the mp3 bit rate isn't to high, it might be fine in stereo
    (for single core)
    emard
    @emard
    can rootfs.tar be gzip -9 compressed, Im on mobile net here
    Lawrie Griffiths
    @lawrie
    I have added a gzip version
    There are now two dtbs: dtb.12f and dtb.blue85f
    The new 12F version is in ulx3s_12f_1core_saxonsoc.bit
    Make sure you get the 1core version as the 2core is still for the old version of the images.
    @Dolu1990 Yes stereo seems OK for me.
    Lawrie Griffiths
    @lawrie
    On a 1-core system, playing music slows down compiling with lcc a lot.
    Lawrie Griffiths
    @lawrie
    @emard I did not use -9 on gzip, but I just tried it and it makes practically no difference.
    emard
    @emard
    This is ok! Im getting it
    e2kgh
    @e2kgh
    Did we get any progress on the 32MByte, Green 85F?
    Is it really the flash? Probably it is easier to replace the flash chip then?
    @Lawrie : WIth all the versions floating around, any chance for a configuration string like "32MB,85F,4CORE", or similar? Or just three values for SDRAM, FPGA and NumCores?
    emard
    @emard
    We are not sure is it flash chip but is currently 1st suspect. We have not yet seen any board with this ISSI flash chip to boot saxonsoc, other things work. FLASH chip can be non-destructivelay desoldered and replaced (by users who have practice and tools).
    Regarding FLASH, currently I managed to maintain esp32ecp5 to use the same SPI FLASH commands to R/W all FLASH chips circulating around.
    emard
    @emard
    Something about FLASH is undocumented, for example some chips after WRITE ENABLE need to READ STATUS before ERASE or WRITE BLOCK. Some dont need reading status, some fail if status is not read at this point. I found it by experiment, pdf datasheet not descibing such behaviour
    Lawrie found that FLASH needs some POWER ON command before being useable
    Lawrie Griffiths
    @lawrie
    @e2kgh I You can now do SDRAM_SIZE=32 CPU_COUNT=2 saxon_netlist, and FPGA_SIZE=85 saxon_bitstream. Is that good enough for what you want?
    emard
    @emard
    Also we must be aware that lattice FPGA itself talks to flash initially and sends some commands and potentially leaves it in state different than power on default
    Lawrie Griffiths
    @lawrie
    @emard Yes, waking up the chip was one thing that I thought might be the problem. I had that problem with SaxonSoc on ice40 boards. I don't know if is that or some other issue that @Dolu1990 wants to test.
    If wake-up is the problem, loading the bistream from flash could possible fix it, as that might leave the flash memory powered on. On ice40 boards there is an option in the bitstream to say whether to put the flash chip to sleep or not after loading from flash, but I don't think ecp5 has that option. Alternatively doing something else that powers up the flash chip and leaves it on before programming the bitstream could fix it.
    Lawrie Griffiths
    @lawrie
    @emard I have started looking at putting PPPD and SCREEN bach. We seem to have lost the BR2_PACKAGE_PPPD and BR2_PACKAGE_SCREEN. I have added those but I don't know if I need any other options. The kernel has CONFIG_PPP and CONFIG_PPP_ASYNC, so pppd ought to work.
    When I type screen I get:
    root@buildroot:~# screen
    socket: Address family not supported by protocol
    I seem to remember that from before. How do you plan to use screen?
    emard
    @emard
    I need screen for multi-terminal use. Maybe it needs some IP address or similar assigned to start hmm
    Currently I got 12F booted with latest audio kernel and now I will transfer some mp3
    Lawrie Griffiths
    @lawrie
    I don't think we got screen working before.
    I can add the image of the rootfs that includes screen and pppd if you like, so you can investigate.
    I don't think the problem with flash memory is the wake-up as SaxonSoc does a wake call - https://github.com/SpinalHDL/SaxonSoc/blob/dev-0.1/bsp/radiona/ulx3s/smp/app/bootloaderConfig.h#L70
    emard
    @emard
    great
    Lawrie Griffiths
    @lawrie
    @Dolu1990 Could we add a test that the flash copy to SDRAM has worked in the bootloader. For example check the first few bytes or compare the SDRAM with the flash memory?
    emard
    @emard
    I think screen worked if logged over the network. For flash I can try tu run ecp5.flash_read or similar. I can also try to erase boot flash (passthru) and things like this