Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Lawrie Griffiths
    @lawrie
    --- a/configs/spinal_saxon_ulx3s_defconfig
    +++ b/configs/spinal_saxon_ulx3s_defconfig
    @@ -75,22 +75,31 @@ BR2_PACKAGE_HTOP=y
     BR2_PACKAGE_LYNX=n
     BR2_PACKAGE_LINKS=n
    
    -BR2_PACKAGE_LIBATOMIC_OPS_ARCH_SUPPORTS=n
    -BR2_PACKAGE_LIBATOMIC_OPS=n
    -BR2_PACKAGE_OPENSSL=n
    -BR2_PACKAGE_LIBOPENSSL=n
    -BR2_PACKAGE_OPENSSH=n
    +BR2_PACKAGE_LIBATOMIC_OPS_ARCH_SUPPORTS=y
    +BR2_PACKAGE_LIBATOMIC_OPS=y
    +BR2_PACKAGE_OPENSSL=y
    +BR2_PACKAGE_LIBOPENSSL=y
    +BR2_PACKAGE_OPENSSH=y
    +BR2_PACKAGE_CA_CERTIFICATES=y
    
     BR2_PACKAGE_RNG_TOOLS=n
    -BR2_PACKAGE_HAVEGED=n
    +BR2_PACKAGE_HAVEGED=y
    
     BR2_PACKAGE_DROPBEAR=y
     BR2_PACKAGE_SSHPASS=y
    
     #BR2_PACKAGE_BUSYBOX_SHOW_OTHERS=n
    -BR2_PACKAGE_BASH=n
    +BR2_PACKAGE_BASH=y
    
    -BR2_PACKAGE_GIT=n
    +BR2_PACKAGE_GIT=y
    +
    +BR2_PACKAGE_LIBCURL=y
    +BR2_PACKAGE_LIBCURL_CURL=y
    +BR2_PACKAGE_PPPD=y
    +BR2_PACKAGE_NETCAT=y
    +BR2_PACKAGE_PROXYCHAINS_NG=y
    +
    +BR2_PACKAGE_JPEG=y
    I think it is OPENSSH=y which causes the increased boot times.
    kost
    @kost
    i did not specify any. Is there any default?
    Dobrica Pavlinušić
    @dpavlin
    @kost I just submitted pull request which explains it: https://github.com/SpinalHDL/SaxonSoc/pull/50/files
    default is 1, for multi-cpu build you will also need to do some sed on device tree to enable additional cores
    Lawrie Griffiths
    @lawrie
    @dpavlin Thanks, I never got round to adding that to the README.
    mara
    @vmedea
    i tried to do CPU_COUNT=4 on a green 32MB ULX85F (not a combination that has a default build), naively editing the device tree to have four cores, but linux crashed on boot on an issue regarding DMA dma: unable to request IRQ 0, i assumed i had done something dumb so didn't investigate further at the time
    Lawrie Griffiths
    @lawrie
    There are two lines in the dts that need to be edited.
    mara
    @vmedea

    Don't worry about esp32 firmware you can reflash or even erase it, board is designed to be "unbrickable".

    that's perfect, i'll just try installing that newer micropython then

    Dolu1990
    @Dolu1990
    @mara did you updated the PLIC interrupt mapping on the DTS ? or you used a prebuilt dtb ?
    mara
    @vmedea
    no, i only uncommented the cores, didn't extend the interrupts-extended, that seems like the problem
    would be nice to automate this, the dtb is already run through a preprocessor isn't it?
    Dolu1990
    @Dolu1990

    the dtb is already run through a preprocessor isn't it?

    Yes that's right, and yes you are right

    i recently updated the flow for the DTS to go through the GCC preprocessor
    kost
    @kost
    btw old "dev" branch does not compile any more. I get this error:
    [warn] Multiple main classes detected.  Run 'show discoveredMainClasses' to see the list
    [info] Compiling 74 Scala sources to /home/ulx3s/SaxonSoc/ext/VexRiscv/target/scala-2.11/classes ...
    [error] Missing required plugin: idsl-plugin
    [error] one error found
    [info] Packaging /home/ulx3s/SaxonSoc/ext/SpinalHDL/lib/target/scala-2.11/spinalhdl-lib_2.11-1.4.3.jar ...
    [info] Done packaging.
    [error] (ProjectRef(uri("file:/home/ulx3s/SaxonSoc/ext/VexRiscv/"), "root") / Compile / compileIncremental) Compilation failed
    [error] Total time: 102 s, completed Oct 19, 2020 4:46:47 AM
    make: *** [makefile:32: generate] Error 1
    Dolu1990
    @Dolu1990
    @kost In which configuration the repo is exactly ? did you pulled a new VexRiscv / SpinalHDL version ?
    kost
    @kost
    https://github.com/SpinalHDL/SaxonSoc - branch named "dev" provide error "above".
    https://github.com/SpinalHDL/SaxonSoc - branch named "dev-0.1" (default) completes without errors.
    Just don't know if you care, so not creating issue.
    Dolu1990
    @Dolu1990
    I don't realy, care, as long term the goal is realy to move on dev-0.1
    But basicaly, that issue above should not have come, as the version of the SpinalHDL/VexRIscv repository are older than 1.4.3
    that's curious
    mara
    @vmedea
    update on esp32: micropython update went without a hitch, after that i was able to put back the ecp5-related files and uftpd using webrepl, ubluetooth.BLE works and at least sees the heartrate sensor in gap_scan! now just need to make it subscribe to the right GATT notification, then send the values to the FPGA, but that seems straightforward. thanks for the help !
    Dolu1990
    @Dolu1990
    @vmedea I implemented your preprocessor proposal in the DTS, thanks for the tip ^^
    That's pushed now
    @kost I pulled a fresh dev branch, and had no issue to compile. How did you cloned the repo ?
    (i did all in one git clone https://github.com/SpinalHDL/SaxonSoc.git --recursive --branch dev)
    mara
    @vmedea
    @Dolu1990 perfect, thanks !
    kost
    @kost
    @Dolu1990 same as yours. complete commands => https://github.com/dok3r/ulx3s-saxonsoc/blob/master/scripts/build.sh
    Dolu1990
    @Dolu1990
    I think this is the issue :
    cd SaxonSoc/ext/ && rm -rf SpinalHDL && git clone https://github.com/SpinalHDL/SpinalHDL && cd ../../ && \
    Basicaly it remove the SpinalHDL version and take the last one, which is the issue.
    emard
    @emard
    @pnru_gitlab wonderful explorations :). I can (maybe a bit later) try to replace this cache with current oberon. Currently I have not dvi monitor to see the results but if it compiles I will know :)
    @danrr_au_twitter great results with heartbeat sensors! I never tried BLE pairing,.users most often ask if esp32 can accept BLE keyboard. Maybe not all can work, but even if we can get some known brand names to work that's already great
    mara
    @vmedea
    one good thing about the heartrate sensor is that it doesn't need pairing, keyboard is probably a bit more hassle due to that, and there's nothing about pairing or authentication in the micropython API unfortunately
    Paul Ruiz
    @pnru_gitlab

    @emard. Thank you. I've just posted an update here:
    https://gitlab.com/pnru/ulx3s-misc/-/tree/master/oberonstation

    I realised that if we have shadow ram for video, we do not need the force-flush feature. In the Next186 cache code, force-flush is implemented by overlaying it on the normal state machine. Clever, but it obfuscates the circuit. If we need it in future, I think it is better implemented with some additional states.

    I have extended the sdram controller family for the 68K and 99K with a version for the OberonStation (matched to the cache). This too appears to work in simulation.

    Goran Mahovlic
    @goran-mahovlic
    @vmedea BLE keyboard may be solvable with making ESP32 keyboard :)
    mara
    @vmedea
    heh i found that one as well, there's some examples of using the ESP32 to make different BLE HID devices, but not to connect to them. They use the C++ API which is more powerful than the micropython one and does have pairing/encryption functionality. So with custom firmware it likely should be possible (or by extending micropython)
    i don't have a BLE keyboard to try though, i have an old BT keyboard but pretty sure it's legacy BT
    emard
    @emard
    @pnru_gitlab I've pulled latest changes, interesting! I'd slightly more favourize video frame cache flush and SDRAM, rather than 96K shadow RAM. If 96K works ok, but it is big and may affect performance or become unpredictable at each routing.
    drr
    @danrr_au_twitter
    @vmedea interested in seeing any new BLE stuff you make especially if it works with just Micropython. I noticed sometimes long BLE startup delays and read requests are documented as unsupported in mpy, probably need to go to C API for that

    @emard do you have details on the IDF RAM usage here? I installed IDF to try a few things but in your docs there is:

    idf3 leaves slighty more free RAM than idf4, and ESP32-WROOM modules always need more RAM.

    I mention WROOM compatibility in my app demo doc as I’d like to support the “low ram” part for my projects. Micropython 1.13 has “idf3” prefix in the image, assuming built with IDF3 rather than 4.

    https://github.com/dan-rodrigues/mobile-fpga-bluetooth-demo#esp32-configuration

    Are RAM limit issues likely if Micropython moves to IDF4?

    emard
    @emard
    @pnru_gitlab I have tried to compile your oberon sdram/cache, but currently got errors both with trellis and diamond:
    drr
    @danrr_au_twitter
    I did notice if I make a silly mistake in my python code then ENOMEM happens very quickly
    emard
    @emard
    diamond:
    @E: CG150 :"/mt/scratch/tmp/fpga/oberon/oberon/hdl/pnru/cache.v":199:25:199:40|Can't mix blocking and non-blocking assignments. Bit 16 of mem[0]
    trellis:
    ERROR: Array cell `SDRAM.dbi_FF[2]' of unknown type `IFS1P3BX'.
    @danrr_au_twitter micropython 1.13 has bug in creating lists so uftpd doesnt list last file and similar (I posted them issue, they are looking for bug). IDF4 is newer, bigger and it leaves slightly less free RAM than IDF3. Best results I got with micropython 1.12, doesnt matter is it IDF3 or IDF4 when esp32ecp5 is used
    I have optimized the code so that both IDF3 and IDF4 in most occasions fit esp32ecp5. But if gzip compressed file is loaded, usually it will produce out of memory because gzip itself needs 32K buffer
    If uftp is not loaded and only ecp5.prog() used then gz may work
    All this problems I hope will be gone if 2MB WROVER is used, but still a sparse RAM saving code is more welcome as all boards now have WROOM (small RAM)
    drr
    @danrr_au_twitter

    WROOM compatibility seems best especially if that's what all the Crowdsupply campaign boards have

    I might play with making the ESP32 a BT HID host to connect a mouse or gamepad, looks like I'll have to use the C API for that. I'll see if there's any existing project I can use as a base