Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    emard
    @emard
    I'm tracking the problem with packet size - pings up to size 76 work, from size 77 and higher there is 1 second delay, longer pings like 1000 no chance to work
    Lawrie Griffiths
    @lawrie
    I wonder if a larger hardware fifo would help - https://github.com/SpinalHDL/SaxonSoc/blob/dev/hardware/scala/saxon/board/ulx3s/Ulx3sLinuxUboot.scala#L84-L88
    emard
    @emard
    yeeees make them 2K each
    Paul Ruiz
    @pnru_gitlab
    DTE may be a half-way point between nano and joe:
    https://craigbarnes.gitlab.io/dte/index.html
    Lawrie Griffiths
    @lawrie
    @emard I will look at increasing the fifo sizes tomorrow.
    emard
    @emard
    @lawrie ok let's try buffers later
    @pnru_gitlab cool finding! only missing feature would be block mode (may move python code few spaces left-right). But basically I don't get why "joe" is so slow here. I tried joe on similar 100MHz/32MB routers like openwrt and joe jumped open almost immediately.
    emard
    @emard
    using pppd at saxonsoc side I was able to ping google, however with extreme packet loss due to serial port problems 
    root@buildroot:~# ping 172.217.18.68
PING 172.217.18.68 (172.217.18.68): 56 data bytes
64 bytes from 172.217.18.68: seq=6 ttl=54 time=62.658 ms
64 bytes from 172.217.18.68: seq=15 ttl=54 time=66.016 ms
...
root@buildroot:~# cat ppp.sh 
#!/bin/sh
stty raw
pppd \
asyncmap 000A0000 \
escape 0,FF \
mru 1492 mtu 1492 \
noauth local debug dump nodefaultroute nocrtscts \
    emard
    @emard
    root@buildroot:~# ping -s 88 www.google.com
PING www.google.com (172.217.16.100): 88 data bytes
76 bytes from 172.217.16.100: seq=0 ttl=54 time=59.833 ms
76 bytes from 172.217.16.100: seq=1 ttl=54 time=61.755 ms
76 bytes from 172.217.16.100: seq=2 ttl=54 time=58.294 ms
^C
--- www.google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 58.294/59.960/61.755 ms
root@buildroot:~# ping -s 89 www.google.com
PING www.google.com (172.217.16.100): 89 data bytes
^C
--- www.google.com ping statistics ---
20 packets transmitted, 0 packets received, 100% packet loss
    this is example for resolv.conf set to ping www.google.com - packet sizes: 88 still works, 89 doesn't work
    problem is when saxsonsoc is receiving serial traffic. google responds and router sends icmp response back to saxonsoc which doesn't "hear" longer packets
    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):