Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    emard
    @emard
    actually strange - google responds with same packet length but still saxon doesn't hear it - maybe after sending longer packet to google, serial port needs a time for "recovery" in order to listen?
    Dolu1990
    @Dolu1990
    I think we just need a linux uart driver ^^
    Before we have that all, performance testing are a bit pointless
    meanwhile, having a larger RX fifo would help, yes
    I have a few things to finish first, then i can go on the driver
    emard
    @emard
    yes good serial driver is very welcome! I think we have "terrain" prepared for pppd to interface with ESP32 ppp so at least some practical wifi-lan networking should be possible, most things would work but esp32 doesn't do NAT but I guess we can handle that "problem" with slirp running on LAN-networked machine
    Dolu1990
    @Dolu1990
    but i think the peripheral is already at the max rx fifo size XD
    Paul Ruiz
    @pnru_gitlab

    actually strange - google responds with same packet length but still saxon doesn't hear it - maybe after sending longer packet to google, serial port needs a time for "recovery" in order to listen?

    Maybe not strange. When sending, if the UART outbound queue is full Linux will wait for it to empty again. When receiving, if the inbound UART queue is full characters get dropped, i.e. packet loss. 88 bytes of payload + 24 bytes of IP & ICMP header is 112 bytes - very close to the 128 buffer size, especially if some bytes need to be escaped into a 2 byte sequence. Have you tried with h/w flow control on the inbound queue?

    Another option could be to reduce the mtu/mru to 75 bytes or so. TCP should be able to overcome the packet loss as long as at least some packages get through.

    emard
    @emard
    :) yes I thought it also but pppd doesn't accept mtu/mru less than 128 maybe xonxoff I didn't try, I can check is it any better
    Paul Ruiz
    @pnru_gitlab
    The console serial does not offer rts/cts handshake?
    Dolu1990
    @Dolu1990
    currently not rts cts
    Paul Ruiz
    @pnru_gitlab
    Correction: its 28 bytes of IP + ICMP header, so 116 bytes. There are 3 bytes of PPP overhead for a total of 119. If >9 bytes in the 116 need to be escaped because the have value 00, 16, 19 or ff the frame is toast.
    emard
    @emard
    guest@brix4:~$ ssh guest@192.168.5.7
    guest@192.168.5.7's password: 
    guest@buildroot:~$
    further experimentation found out that it's now possible to ssh login over dropbear. Initial asking for password takes very long but it's finally possible
    emard
    @emard
    but xonxoff I guess doesn't make any difference...
    I tried it and behaves mostly the same
    kost
    @kost
    nice progress.
    regarding uart problem. i have tried to lower baudrate on slirp down to 2400 and mtu/mru to 296 which is recommended values for slow links, but it doesn't help.
    I have managed to transfer bigger files by setting block size in ftp to lower value and to introduce delay between transferring of blocks.
    pip install microftp
    microftpcmd --host 192.168.5.7 --delay 0.3 --block 32 -v -d --user root put ~/wget /root/wget
    of course, you should not perform any other action over serial line (like telnet to ulx3s in parallel). and it is pretty slow, of course. so, works for smaller files.
    kost
    @kost
    i find microftp useful to automatize upload of bitstreams to fpga as well as I can do it as oneliner:
    For example:
    microftpcmd --host 192.168.4.1 put  saxonsoc-ulx3s-85f.bit fpga
    Lawrie Griffiths
    @lawrie
    There are u-boot versions in saxonsoc-ulx3s-bin/linus/u-boot now.
    The only difference is that if you are using an 85f with 64MB you need to use sdimage64 which contains a dtb that specifies 64MB of memory, and you should then use saxonsoc-ulx3s-linux-85f-64.bit. For the green 85F with 32MB use saxonsoc-ulx3s-linux-85f-32.bit.
    They should work with any flash chip as they wake up the flash chip.
    Rangel Ivanov
    @ironsteel
    Hi guys! Is the ulx3s pin map (.lpf) identical for all FPGA sizes for the BGA 381 package?
    Lawrie Griffiths
    @lawrie
    I use the same one for the 12F and 85F.
    Rangel Ivanov
    @ironsteel
    cool, thanks! I came to the same conclusion after checking the kicad project but I wanted to make sure
    Lawrie Griffiths
    @lawrie
    Here is a README on building SaxonSoc Linux from source - https://github.com/SpinalHDL/SaxonSoc/tree/dev/bsp/Ulx3sLinuxUboot
    emard
    @emard
    @ironsteel yes lpf is identical for all fpga sizes 12-85F because the PCB is designed to accept all chips. Chips slightly differ in available pins and only common pins to all sizes have been used, so far I think there are no bugs in this direction :)
    Rangel Ivanov
    @ironsteel
    Great! That's really convenient!
    Lawrie Griffiths
    @lawrie
    I added a README for running the u-boot version from binaries - https://github.com/lawrie/saxonsoc-ulx3s-bin/blob/master/linux/u-boot/README.md
    emard
    @emard
    @lawrie great, seems clear and easy for anyone starting from 0 to linux prompt
    emard
    @emard
    @lawrie if sdcard images for 32/64MB RAM differ only in a single small file, I'd have 32MB default and place both dtb_32MB and dtb_64MB on sdcard and have some symlink ln -s dtb_32MB dtb. So after reboot 64MB is used instead of 32MB
    I mean after changing this symlink and reboot then 64MB I forgot to mention but it's obvious
    emard
    @emard
    @lawrie another question, will changing u-boot default commandline parameters permanently work like this (suppose I want to change partition to boot from):
    NAON#setenv bootargs 'root=/dev/mmcblk0p1 rw console=ttyO0,115200n8 earlyprintk mem=176M vram=46M notifyk.vpssm3_sva=0xBF900000'
    NAON#saveenv
    Saving Environment to SPI Flash...
    Erasing SPI flash...Writing to SPI flash...done
    NAON#
    this is copy pasted from another board, please specifiy related parameters for saxonsoc
    Lawrie Griffiths
    @lawrie
    I don't think we have an environment set up for u-boot, so I don't think saveenv will work. I don't think anyone has tried bootargs with it. @Dolu1990 may know more.
    Dolu1990
    @Dolu1990
    @emard i don't know nothing about u-boot env, sorry XD
    But
    normaly that should only be about properly configuring u-boot
    also, i made some additions (on Arty7) to get the SPI flash read/write access from linux itself, and it worked, so should be easy to do with u-boot
    todo
    Lawrie Griffiths
    @lawrie
    @Dolu1990 I think u-boot has options for either using the sd card or SPI flash for storing the environment.
    emard
    @emard
    I want sdcard's 1st partition mmcblk0p1=msdos, 2nd mmcblk0p2=linux. If uboot can get it working great - msdos can contain commandline parameters...
    Lawrie Griffiths
    @lawrie
    @emard Why do you want to change the partition? On the Arty7, @Dolu1990 is using multple partitions. He has the u-boot files in p1 and linux in p2, both ext2. I could build an sdcard, the way you want it.
    Dolu1990
    @Dolu1990
    Hoo then i would prefer sdcard to store the env, if possible
    I thinkg having multiple partitions is the good way to go, especialy if we want :
    • p1 : u-boot
    • p2 : regular linux
    • p3 : Linux used to update P1 and P2 + serial flash