Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Goran Mahovlic
    @goran-mahovlic
    I think I used your files as startup with camera
    And it looks really cool on color OLED
    Lawrie Griffiths
    @lawrie
    I do have an OV7670 Pmod as I found one of OSHPark - https://oshpark.com/shared_projects/HAZ1ZB7w
    Goran Mahovlic
    @goran-mahovlic
    is this one working on ULX3S?
    Lawrie Griffiths
    @lawrie
    Haven't tried yet.
    Goran Mahovlic
    @goran-mahovlic
    ok, let me know once you check so I can write in README that it is confirmed :) - It should work it is just a bunch of wires
    I have I2S microphone (i have put ultrasonic there) , but that board needs small rework
    Did not managed to get MLX90640 working even on arduino - will need to recheck that one
    That would be cool in combination with OV7670
    Lawrie Griffiths
    @lawrie
    @emard I am just setting things up for the SaxonSoc Linux u-boot version. Do you still want the Joe editor, or is it too slow?
    Lawrie Griffiths
    @lawrie
    There is a working u-boot version of SaxonSoc Linux now - https://github.com/lawrie/saxonsoc-ulx3s-bin/tree/master/linux/u-boot
    It currently only works on the 12F but includes all the networking and other options that people asked for. Let me know if I missed anything. It does not have the msdos partition.
    It needs the bios at flash@0x300000 and u-boot.bin at flash@0x310000. Everything else is then loaded from the sd card.
    Lawrie Griffiths
    @lawrie
    If you see a blank screen, type enter or press btn 0. If you see the "=>" u-boot prompt, type "boot". It waits for 2 seconds in u-boot and then boots. Not sure what it does when the terminal has not been connected. I think it sticks in u-boot in that case and needs you to type "boot".
    emard
    @emard
    @lawrie joe editor is too slow for practical use. Advantage of joe over nano is to open 2 files in 2 split windows and copy paste things between. Maybe we can retry joe after cache and sdram driver are improved.
    kost
    @kost
    Nice @lawrie
    emard
    @emard
    @lawrie uboot works perfect! I also tried connecting with saxonsoc pppd instead of slirpd but the same thing - can't login with ssh and ftp put hangs with 0-length file created :)
    emard
    @emard
    guest@brix4:/mt/scratch/tmp/fpga/linux/programs$ ping -s 77 192.168.5.7
    PING 192.168.5.7 (192.168.5.7) 77(105) bytes of data.
    85 bytes from 192.168.5.7: icmp_seq=1 ttl=64 time=56.2 ms
    85 bytes from 192.168.5.7: icmp_seq=2 ttl=64 time=1117 ms
    85 bytes from 192.168.5.7: icmp_seq=3 ttl=64 time=84.6 ms
    85 bytes from 192.168.5.7: icmp_seq=4 ttl=64 time=55.4 ms
    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
    emard
    @emard
    yeeees make them 2K each
    Paul Ruiz
    @pnru_gitlab
    DTE may be a half-way point between nano and joe:
    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.