|
Weblog: recent changes
in Dobrica Pavlinušić's random unstructured stuff
|
|
|
HDMI expander
http://www.fnirsi.com.cn/home?lang=en-us http://www.fnirsi.com.cn/product/704369228916068352 http://www.fnirsi.com.cn/download/usb https://goughlui.com/2023/04/29/review-tested-fnirsi-fnb58-usb-fast-charge-tester/ usb serialhttps://github.com/baryluk/fnirsi-usb-power-data-logger blehttps://github.com/losonsky/FNB58 root@rpi4:/home/pi/FNB58# git remote -v origin https://github.com/losonsky/FNB58 (fetch) origin https://github.com/losonsky/FNB58 (push) root@rpi4:/home/pi/FNB58# git diff diff --git a/fnb58_dump.sh b/fnb58_dump.sh index 2a63e7f..2f74a74 100755 --- a/fnb58_dump.sh +++ b/fnb58_dump.sh @@ -2,6 +2,8 @@ # just change to your MAC.... BT_MAC="BA:03:1C:67:56:22"; +# 98:DA:B0:01:D6:15 FNB58-047732 +BT_MAC="98:DA:B0:01:D6:15"; OLD_IFS=$IFS; root@rpi4:/home/pi/FNB58# root@rpi4:/home/pi/FNB58# ./fnb58_dump.sh connect to 98:DA:B0:01:D6:15: Function not implemented (38) RD TC66/TC66C Type-C PD trigger USB-C Voltmeter ammeter voltage 2 way current meter multimeter PD charger battery USB Tester https://www.aliexpress.com/item/32968303350.html https://sigrok.org/wiki/RDTech_TC66C https://www.youtube.com/watch?v=rOlhibDUJgs bluetooth le range is very losy, it's about 30cm so you almost have to put Android phone on top of TC66C to make it work :-( TC66C Reverse Engineeringhttps://ralimtek.com/reverse%20engineering/software/tc66c-reverse-engineering/ https://github.com/Ralim/TC66C newer version: https://github.com/Ircama/TC66C pi@rpi2 ~/TC66C $ git remote -v origin https://github.com/Ircama/TC66C (fetch) origin https://github.com/Ircama/TC66C (push) pi@rpi2 ~/TC66C $ git branch -a * keyboard_mgmt master remotes/origin/HEAD -> origin/master remotes/origin/keyboard_mgmt remotes/origin/master pi@rpi2 ~/TC66C $ sudo apt install python3-curtsies pi@rpi2 ~/TC66C $ sudo pip3 install bluepy pi@rpi2 ~/TC66C $ sudo ./scan.py
https://www.pine64.org/pinephone/ https://wiki.pine64.org/index.php/PinePhone https://wiki.pine64.org/wiki/PinePhone_v1.1_-_Braveheart Full specifications
postmarketoshttps://wiki.postmarketos.org/wiki/PINE64_PinePhone_(pine64-pinephone)#Installation wget https://images.postmarketos.org/bpo/v21.12/pine64-pinephone/sxmo-de-sway/20220202-0445/20220202-0445-postmarketOS-v21.12-sxmo-de-sway-1.7.0-pine64-pinephone.img.xz dpavlin@nuc:/tmp$ xz --decompress --stdout 20220202-0445-postmarketOS-v21.12-sxmo-de-sway-1.7.0-pine64-pinephone.img.xz | \ sudo dd of=/dev/sdc bs=4M status=progress iflag=fullblock oflag=direct conv=fsync modem upgradehttps://github.com/the-modem-distro/pinephone_modem_sdk/ https://github.com/the-modem-distro/pinephone_modem_sdk/blob/kirkstone/docs/AT_INTERFACE.md pine64-pinephone:~$ sh -x ./modem-serial.sh + sudo picocom --echo --omap ignlf /dev/ttyUSB2 ati Quectel EG25 Revision: EG25GGBR07A07M2G OK # battery AT+CBC +CBC: 0,93,4114 # versions AT+CGMI Quectel AT+CGMM EG25 AT+CGMR EG25GGBR07A07M2G # Get ADSP firmware version AT+QGMR EG25GGBR07A07M2G_01.002.01.002 upgrade modem firmware
pine64-pinephone:/home/user/modem-firmware# sh -x flashall
+ echo 'Sending AT+QFASTBOOT...'
Sending AT+QFASTBOOT...
+ sudo sh -c 'echo -ne "AT+QFASTBOOT\r" > /dev/ttyUSB2'
+ fastboot oem stay
< waiting for any device >
[Mon Jun 12 10:52:53 2023] usb 2-1: USB disconnect, device number 8
[Mon Jun 12 10:52:53 2023] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
[Mon Jun 12 10:52:53 2023] option 2-1:1.0: device disconnected
[Mon Jun 12 10:52:53 2023] option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1
[Mon Jun 12 10:52:53 2023] option 2-1:1.1: device disconnected
[Mon Jun 12 10:52:53 2023] option1 ttyUSB2: GSM modem (1-port) converter now disconnected from ttyUSB2
[Mon Jun 12 10:52:53 2023] option 2-1:1.2: device disconnected
[Mon Jun 12 10:52:53 2023] option1 ttyUSB3: GSM modem (1-port) converter now disconnected from ttyUSB3
[Mon Jun 12 10:52:53 2023] option 2-1:1.3: device disconnected
[Mon Jun 12 10:52:53 2023] qmi_wwan 2-1:1.4 wwan0: unregister 'qmi_wwan' usb-1c1b000.usb-1, WWAN/QMI device
Jun 12 10:52:54 pine64-pinephone authpriv.notice sudo: root : TTY=pts/0 ; PWD=/home/user/modem-firmware ; USER=root ; COMMAND=/bin/sh -c echo -ne "AT+QFASTBOOT\r" > /dev/ttyUSB2
Jun 12 10:52:54 pine64-pinephone daemon.info [1966]: <info> [base-manager] port ttyUSB0 released by device '/sys/devices/platform/soc/1c1b000.usb/usb2/2-1'
Jun 12 10:52:54 pine64-pinephone daemon.info [1966]: <info> [base-manager] port ttyUSB1 released by device '/sys/devices/platform/soc/1c1b000.usb/usb2/2-1'
Jun 12 10:52:54 pine64-pinephone daemon.info [1966]: <info> [base-manager] port ttyUSB2 released by device '/sys/devices/platform/soc/1c1b000.usb/usb2/2-1'
Jun 12 10:52:54 pine64-pinephone daemon.info [1966]: <info> [base-manager] port ttyUSB3 released by device '/sys/devices/platform/soc/1c1b000.usb/usb2/2-1'
Jun 12 10:52:54 pine64-pinephone daemon.info [1966]: <info> [base-manager] port wwan0 released by device '/sys/devices/platform/soc/1c1b000.usb/usb2/2-1'
Jun 12 10:52:54 pine64-pinephone daemon.warn [1966]: <warn> Cannot read from istream: connection broken
Jun 12 10:52:54 pine64-pinephone daemon.info [1966]: <info> [modem6] port 'cdc-wdm0' no longer controllable, reprobing
Jun 12 10:52:54 pine64-pinephone daemon.info NetworkManager[2272]: <info> [1686559974.1549] device (cdc-wdm0): state change: disconnected -> unmanaged (reason 'removed', sys-iface-state: 'removed')
Jun 12 10:52:54 pine64-pinephone daemon.info [1966]: <info> [base-manager] port cdc-wdm0 released by device '/sys/devices/platform/soc/1c1b000.usb/usb2/2-1'
[Mon Jun 12 10:52:54 2023] usb 2-1: new high-speed USB device number 9 using ehci-platform
FAILED (remote: 'unknown command')
fastboot: error: Command failed
+ fastboot flash aboot appsboot.mbn
Sending 'aboot' (279 KB) OKAY [ 0.012s]
Writing 'aboot' OKAY [ 0.145s]
Finished. Total time: 0.168s
+ fastboot reboot
Rebooting OKAY [ 0.017s]
[Mon Jun 12 10:52:55 2023] usb 2-1: USB disconnect, device number 9
Finished. Total time: 0.067s
+ sleep 1
+ fastboot oem stay
< waiting for any device >
[Mon Jun 12 10:52:56 2023] usb 2-1: new high-speed USB device number 10 using ehci-platform
OKAY [ 0.002s]
Finished. Total time: 0.002s
+ sleep 1
+ fastboot flash:raw boot boot-mdm9607.img
< waiting for any device >
Sending 'boot' (4600 KB) OKAY [ 0.166s]
Writing 'boot' OKAY [ 1.753s]
Finished. Total time: 1.937s
+ fastboot flash:raw recovery boot-mdm9607.img
Sending 'recovery' (4600 KB) OKAY [ 0.162s]
Writing 'recovery' OKAY [ 1.752s]
Finished. Total time: 1.932s
+ fastboot flash system rootfs-mdm9607.ubi
Sending 'system' (27648 KB) OKAY [ 0.958s]
Writing 'system' OKAY [ 11.163s]
Finished. Total time: 12.133s
+ fastboot flash recoveryfs recoveryfs.ubi
Sending 'recoveryfs' (13056 KB) OKAY [ 0.454s]
Writing 'recoveryfs' OKAY [ 4.686s]
Finished. Total time: 5.153s
+ fastboot reboot
Rebooting OKAY [ 0.004s]
[Mon Jun 12 10:53:20 2023] usb 2-1: USB disconnect, device number 10
Finished. Total time: 0.055s
+ echo 'Done!'
Done!
pine64-pinephone:/home/user/modem-firmware# [Mon Jun 12 10:53:21 2023] usb 2-1: new high-speed USB device number 11 using ehci-platform
[Mon Jun 12 10:53:26 2023] usb 2-1: USB disconnect, device number 11
[Mon Jun 12 10:53:42 2023] usb 2-1: new high-speed USB device number 12 using ehci-platform
[Mon Jun 12 10:53:42 2023] option 2-1:1.0: GSM modem (1-port) converter detected
[Mon Jun 12 10:53:42 2023] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB0
[Mon Jun 12 10:53:42 2023] option 2-1:1.1: GSM modem (1-port) converter detected
[Mon Jun 12 10:53:42 2023] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB1
[Mon Jun 12 10:53:42 2023] option 2-1:1.2: GSM modem (1-port) converter detected
[Mon Jun 12 10:53:42 2023] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB2
[Mon Jun 12 10:53:42 2023] option 2-1:1.3: GSM modem (1-port) converter detected
[Mon Jun 12 10:53:42 2023] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB3
[Mon Jun 12 10:53:42 2023] qmi_wwan 2-1:1.4: cdc-wdm0: USB WDM device
[Mon Jun 12 10:53:42 2023] qmi_wwan 2-1:1.4 wwan0: register 'qmi_wwan' at usb-1c1b000.usb-1, WWAN/QMI device, 32:5f:5b:44:e8:c1
Jun 12 10:53:43 pine64-pinephone user.notice postmarketOS:modem-setup: Modem already configured
Jun 12 10:53:54 pine64-pinephone daemon.info [1966]: <info> [device /sys/devices/platform/soc/1c1b000.usb/usb2/2-1] creating modem with plugin 'quectel' and '6' ports
Jun 12 10:53:54 pine64-pinephone daemon.warn [1966]: <warn> [plugin/quectel] could not grab port ttyUSB3: Cannot add port 'tty/ttyUSB3', unhandled port type
Jun 12 10:53:54 pine64-pinephone daemon.info [1966]: <info> [base-manager] modem for device '/sys/devices/platform/soc/1c1b000.usb/usb2/2-1' successfully created
Jun 12 10:53:55 pine64-pinephone daemon.warn [1966]: <warn> [modem7] couldn't query SIM slots: QMI protocol error (94): 'NotSupported'
Jun 12 10:53:56 pine64-pinephone daemon.warn [1966]: <warn> [modem7/sim5] couldn't load list of emergency numbers: uninitialized emergency numbers list
Jun 12 10:53:56 pine64-pinephone daemon.warn [1966]: <warn> [modem7] couldn't load list of own numbers: Couldn't get MSISDN: QMI protocol error (16): 'NotProvisioned'
Jun 12 10:53:56 pine64-pinephone daemon.info [1966]: <info> [modem7] state changed (unknown -> disabled)
Jun 12 10:53:56 pine64-pinephone daemon.info NetworkManager[2272]: <info> [1686560036.9081] manager: (cdc-wdm0): new Broadband device (/org/freedesktop/NetworkManager/Devices/10)
Jun 12 10:53:56 pine64-pinephone daemon.info NetworkManager[2272]: <info> [1686560036.9131] device (cdc-wdm0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external')
Jun 12 10:53:56 pine64-pinephone daemon.info NetworkManager[2272]: <info> [1686560036.9154] device (cdc-wdm0): modem state 'enabling'
Jun 12 10:53:56 pine64-pinephone daemon.info NetworkManager[2272]: <info> [1686560036.9182] device (cdc-wdm0): state change: unavailable -> disconnected (reason 'none', sys-iface-state: 'managed')
Jun 12 10:53:56 pine64-pinephone daemon.info [1966]: <info> [modem7] state changed (disabled -> enabling)
Jun 12 10:53:57 pine64-pinephone daemon.info [1966]: <info> [modem7] power state updated: on
Jun 12 10:53:57 pine64-pinephone daemon.info [1966]: <info> [modem7] state changed (enabling -> enabled)
Jun 12 10:53:57 pine64-pinephone daemon.info [1966]: <info> [modem7] 3GPP registration state changed (unknown -> registering)
Jun 12 10:53:57 pine64-pinephone daemon.info [1966]: <info> [modem7] 3GPP registration state changed (registering -> roaming)
Jun 12 10:53:57 pine64-pinephone daemon.info [1966]: <info> [modem7] state changed (enabled -> registered)
Jun 12 10:54:06 pine64-pinephone daemon.warn [1966]: <warn> [modem7] couldn't load network timezone from the current network
pine64-pinephone:/home/user/modem-firmware#
pine64-pinephone:/home/user/modem-firmware# fwupdmgr get-devices
Jun 12 10:54:17 pine64-pinephone authpriv.notice polkitd[2031]: Registered Authentication Agent for unix-process:28593:6556826 (system bus name :1.92 [/usr/bin/pkttyagent --notify-fd 6 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale C.UTF-8)
WARNING: UEFI capsule updates not available or enabled in firmware setup
See https://github.com/fwupd/fwupd/wiki/PluginFlag:capsules-unsupported for more information.
WARNING: This package has not been validated, it may not work properly.
pine64 Pine64 PinePhone Braveheart (1.1)
│
├─Unknown Device:
│ Device ID: 0e0c93c8b4bb222157feedbde8f863e23bd1a8f7
│ Current version: 0x1400000000000000
│ Vendor: EMMC:0x0000e1
│ GUID: ba81658c-572e-5097-a08f-f9f023bb4224 ← EMMC\MAN_00E1&OEM_0116
│ Device Flags: • Internal device
│ • Updatable
│
└─QUECTEL Mobile Broadband Module:
Device ID: 976c4a39e87f61e6940ea6a8d39c583cfa99615f
Summary: Quectel EG25-G modem
Current version: EG25GGBR07A07M2G_01.002.01.002
Vendor: Qualcomm (USB:0x2C7C, USB:0x18D1)
GUIDs: db379a33-254f-5140-b37e-d36ae7e5c039
d18f31f1-a3fa-55a2-b4ed-decfbc1e004d ← USB\VID_2C7C&PID_0125&REV_0318&NAME_EG25GGB
1a2996cb-f86e-5583-a464-e1b96e1c6ae9 ← USB\VID_2C7C&PID_0125&REV_0318
587bf468-6859-5522-93a7-6cce552a0aa3 ← USB\VID_2C7C&PID_0125
22ae45db-f68e-5c55-9c02-4557dca238ec ← USB\VID_2C7C
Device Flags: • Updatable
• System requires external power source
• Supported on remote server
• Device supports switching to a different branch of firmware
• Unsigned Payload
FLE wristband with heart rate monitor nRF51822
Brand: Makibes Android APK VeryFit 2.0: https://apkpure.com/veryfit/com.watch.life/versions Possible free firmware for similar but newer device: https://github.com/StarGate01/chrzwatch-firmware Unfortunately not compatible with https://gadgetbridge.org/ root@rpi2:/home/pi# grep Wrist screenlog.0 CD:57:1B:79:77:B2 Wristband CD:57:1B:79:77:B2 Wristband CD:57:1B:79:77:B2 Wristband CD:57:1B:79:77:B2 Wristband Also known as Huawei Honor 7 Lite, Huawei GT3 but 5c doesn't have finger printer server (EU model)
specs
[167374.310193] usb 3-2: new high-speed USB device number 8 using ehci-pci [167374.467237] usb 3-2: New USB device found, idVendor=12d1, idProduct=107e, bcdDevice= 2.99 [167374.467244] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [167374.467247] usb 3-2: Product: NEM-L21 [167374.467250] usb 3-2: Manufacturer: HUAWEI [167374.467253] usb 3-2: SerialNumber: 8SC4C17419000317 [167374.472036] usb-storage 3-2:1.1: USB Mass Storage device detected [167374.476015] scsi host4: usb-storage 3-2:1.1 [167375.503071] scsi 4:0:0:0: CD-ROM Linux File-CD Gadget 0401 PQ: 0 ANSI: 2 [167375.504618] sr 4:0:0:0: Power-on or device reset occurred [167375.511385] sr 4:0:0:0: [sr0] scsi-1 drive [167375.513109] sr 4:0:0:0: Attached scsi CD-ROM sr0 [167375.513522] sr 4:0:0:0: Attached scsi generic sg1 type 5 but doesn't show in adb devices Dial *#*#1357946#*#* unlock bootloaderhuawei doesn't provide official way to do so any more. https://www.droidthunder.com/unlock-bootloader-of-huawei/ huawei exploit(not for 5c, but interesting)
inspiron-mini9_service manual_en-us.pdf
dpavlin@mini2:~$ lscpu
Architecture: i686
CPU op-mode(s): 32-bit
Address sizes: 32 bits physical, 32 bits virtual
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Vendor ID: GenuineIntel
Model name: Intel(R) Atom(TM) CPU N270 @ 1.60GHz
CPU family: 6
Model: 28
Thread(s) per core: 2
Core(s) per socket: 1
Socket(s): 1
Stepping: 2
CPU(s) scaling MHz: 100%
CPU max MHz: 1600.0000
CPU min MHz: 800.0000
BogoMIPS: 3191.78
Flags: fpu vme de tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx cons
tant_tsc arch_perfmon pebs bts cpuid aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 xtpr pdcm movbe lahf_lm dther
m
Caches (sum of all):
L1d: 24 KiB (1 instance)
L1i: 32 KiB (1 instance)
L2: 512 KiB (1 instance)
dmidecode
System Information
Manufacturer: Dell Inc.
Product Name: Inspiron 910
Version: A04
Serial Number: DRRZWF1
UUID: 20202020-2020-2020-2020-202020202020
Wake-up Type: Power Switch
SKU Number: Not Specified
Family: Not Specified
bios cell bateryManual claims there is battery holder for BIOS cell battery -- there isn't. You will have to have battery with spot welded wings to which you can solder original wire to change it. Helpful notes from chat about ULX3S i2chttps://gitter.im/ulx3s/Lobby?at=5dfcf29acf771f7708ff69e9 It should not be that hard. I have i2c in SaxonSoc in other projects such as https://github.com/SpinalHDL/SaxonSoc/blob/dev/hardware/scala/saxon/board/blackice/BlackiceSocArduino.scala#L25 The generated board support packages include a generated dts, but it is not used yet and the simple i2c generator that I wrote does not generate the dts. There is a problem building SaxonSoc Linux, that some build randomly do not work. It seems to be something to do with SDRAM access. @Dolu1990 is about to redo the SDRAM access for the Ulx3s, which should make it more reliable and faster, as he plans to support double frequency access. There is a lot of information on the development of the u-boot version here , which might be useful to you - SpinalHDL/SaxonSoc#7 https://github.com/SpinalHDL/SaxonSoc/pull/7 I2c Linux support will also need a spinal.lib driver here - https://github.com/SpinalHDL/linux/tree/linux-5.0.y/drivers/i2c The terasic De1Soc version of SaxonSoc Linux has a dts entry for an led for disk access - https://github.com/SpinalHDL/buildroot/blob/saxon/board/spinal/saxon_default/spinal_saxon_default_de1_soc.dts#L194 We really need a better GPIO mapping for the Ulx3s. That might involve including adding a second gpio peripheral to the hardware (gpioB) and doing a better lpf file mapping to pins. It might mean increasing the niumbers of pins that support interrupts. It would be good to include access to the buttons and switches and to make it easy to add Pmods that need interrupt support like the enc28j60 one. ecp5pllMario Hoffmann @hoffma_gitlab Aug 05 16:11 Hello, I wanted to have a 90 degree shifted clock. I was trying out the ecp5pll from @emard. I get it running and the clock adjustment seems to work, but somehow it does not get shifted for me. Is this currently not working with yosys and so forth, is there anything I have to take care of, or might it just be a bug on my side? Tried to search this chat a bit and just searched a bit on the internet but the things I found about it were quite old and not necessarily about my problem. Any ideas? I am using the vhdl version btw emard @emard Aug 05 16:59 There's some order of signals and small delays between them for dynamic shifting to work. https://github.com/emard/ulx3s-misc/blob/master/examples/sdram/memtest_mister/hdl/top/top_memtest.v#L73 here is module to control phase shifts by pressing of BTN for testing of SDRAM with variable phase shift of the clock to chip Mario Hoffmann @hoffma_gitlab Aug 05 17:01 alright, ill look at that. thanks Mario Hoffmann @hoffma_gitlab Aug 05 17:53 Oh nice it works. My thinking was just a bit wrong and there was a little bug too. Thanks emard @emard Aug 05 18:07 ecp5pll has possibility for fine-precision phase adjustment but this simple BTN module doesn't generate proper phaseloadreg signal https://github.com/emard/ulx3s-misc/blob/master/examples/sdram/memtest_mister/hdl/btn_ecp5pll_phase.v#L51 displayhttps://gitter.im/ulx3s/Lobby?at=5f3b7df7ee58011680b36cb0 emard @emard Aug 18 09:06 SSD1331 96x64 is full featured OLED beautiful contrast, but currently best buy is ST7789 1.3" 240x240 LCD less contrast but more pix and less $. Do not solder directly the display. Solder female 7-pin header and plug the display. Mechanical stabilization can be 3D printed https://github.com/emard/ulx3s/tree/master/box it will "work" properly only if whole box is printed. There is no problem with heat normally to FPGA but SSD1331 with wrong software commands can become hot to fry fingers and smoke, it happened to me once, colors faded and I just replaced display. Onboard USB-SERIAL can provide 2nd JTAG channel for openocd debugger of RISCV processor it will work but it will be VERY slow (for debug single step ok, but for transferring Mbps no). rtchttps://gitter.im/ulx3s/Lobby?at=5f3b86a1a8c178017657caf6 emard @emard Aug 18 09:43 Yes for RTC I first saw it "works" but after few reboots I found out that it resets to compile time or something. Core could consult onboard RTC using i2c and then set unix time integer counter which will continue ticking afterwards. For setting RTC we have esp32 and other options. Btw import ntptime; ntptime.settime() will set ESP32 localtime() from a pool of network NTP servers and then esp32 can initialize onboard RTC here I have played with this https://github.com/emard/ulx3s-misc/tree/master/examples/rtc/micropython-mcp7940n/esp32 https://gitter.im/ulx3s/Lobby?at=5f3dbb34750a2741302ea427 emard @emard Aug 20 01:52 @pnru_gitlab here is 8-bit master interface. I haven't tested it very simple by reading seconds and seems ok https://github.com/emard/ulx3s-misc/blob/master/examples/rtc/i2c_master/proj/hdl/i2c_master_8bit.v https://gitter.im/ulx3s/Lobby?at=5f3e2d1c07c30d132a9c4f58 emard @emard Aug 20 09:58 when we are at verilog, I have found on the net several i2c bidirectional bridges. Only one code worked at our board but it works only if compiled by diamond. trellis compiles but doesn't work. Can someone take a look what I have missed: bridge: https://github.com/emard/ulx3s-misc/blob/master/examples/rtc/micropython-mcp7940n/proj/hdl/i2c_bridge.v toplevel usage: https://github.com/emard/ulx3s-misc/blob/master/examples/rtc/micropython-mcp7940n/proj/top/top_i2c_bridge.v emard @emard Aug 20 22:04 for me it works for any gpdi_scl/sda PULLMODE=UP, DOWN, or NONE so it's not pull setting. I can prepare a bitstream and micropython to ulx3s-bin example that initializes the clock setting time from NTP emard @emard Aug 20 22:18 https://github.com/emard/ulx3s-bin/tree/master/esp32/micropython/rtc can you try this RTC esp32 example for NTP setting? >>> rtcdemo.mcp.time should advance seconds emard @emard Aug 21 00:04
RTC traffic also appears at GPDI connector (if there's i2c chip 3.3V->5V adapter soldered on board PCA9306D). Some monitors may hold i2c lines. Also gpdi connector can be used to monitor traffic if e.g. you have hdmi breakout board emard @emard Aug 21 00:09
UPS but we have problem there will be 2 RTC chips colliding address :) emard @emard Aug 21 18:14 I fixed i2c_bridge.v to work with both trellis and diamond. Paul Ruiz @pnru_gitlab Aug 21 23:35
Which way does the battery go? I think with the + side (cap) up and the - side (ribbed) to the PCB? emard @emard Aug 21 23:59
Battery goes + up (larger part of battery should be in contact with metallic holder soldered) - down (smaller part of battery in contact to big circular pad on the PCB scopeiohttps://gitter.im/ulx3s/Lobby?at=5f3c27ffa05e464346d2f6ea emard @emard Aug 18 21:11 @gkankanh MAX11125 is 1Msa/s total so e.g. if you use 4ch then each channel will be 0.25MSa/s per channel. For oscilloscope it, we have ready solution at hdl4fpga/ULX3S/scopeio you will see traces on monitor. For analysis, onboard USB-serial can do 3Mbps so it could be nearly useable. For faster ADC, yes 100 Mbit ethernet ETH8720 from ebay, module for 2.2$ and for example ebay's AN108 AD/DA module 32MSa/s input, 125MSa/s output https://www.ebay.com/itm/ADDA-Module-Data-Signal-Acquisition-High-speed-Directly-pluggable-connector-/253556250998 also scopeio supports it how to solder headershttps://gitter.im/ulx3s/Lobby?at=5f3cd88378f4a801801336cb emard @emard Aug 19 09:45 To have GP/GN not be swapped from "default" design, Either solder 90° FEMALE headers on top side of board (nice for PMODs directly) or straight 0° MALE pins down on bottom side of board. PMODs can also plug to other end of flat cable and pinout will be identical as if 90° was soldered onboard. nmingenhttps://gitter.im/ulx3s/Lobby?at=5f3cfbce8b8d4f633effcea7 Lawrie Griffiths @lawrie Aug 19 12:15
I am using Ubuntu 20.04, so I need to use pip3 not pip. (You can't get python2 pip on 20.04 easily).
from nmigen import *
from nmigen_boards.ulx3s import *
class Blinky(Elaboratable):
def elaborate(self, platform):
led = platform.request("led", 0)
timer = Signal(26)
m = Module()
m.d.sync += timer.eq(timer + 1)
m.d.comb += led.o.eq(timer[-1])
return m
if __name__ == "__main__":
platform = ULX3S_85F_Platform()
platform.build(Blinky(), do_program=True)
https://github.com/GuzTech/ulx3s-nmigen-examples https://github.com/greatscottgadgets/luna SDRAM memtesthttps://gitter.im/ulx3s/Lobby?at=5f4ea96249a1df0a12c0d83e Lawrie Griffiths @lawrie Sep 01 22:04
@pnru_gitlab @Dolu1990 asked these questions about using the SDRAM, which I thought you might know something about from all your recent work on SDRAM drivers: Dolu1990 @Dolu1990 Sep 01 22:05 Moaaaar powaaaaaaaa emard @emard Sep 01 22:36 oooh yeea :)) if you want to push SDRAM near the edge and give it some heat, on selected designs it can push 133MHz chips to 180-200 MHz, fmax depends on each board. 12F performs better than 85F. Here's memtest https://github.com/emard/ulx3s-misc/tree/master/examples/sdram/memtest_mister shows results on DVI monitor and with BTNs can adjust phase shift dynamically and watch for errors. Dolu1990 @Dolu1990 Sep 01 23:01
<3 emard @emard Sep 01 23:08 Yes this has a classic sdram driver that normally needs 90° phase offset to chip hardware, but as fmax is getting higher the actual phase shift which makes it really work moves. PLL is used to provide phase shift. Paul has made a better sdram driver with cool vendor-independent delay solution with a number of NOT gates.Only ns delay per NOT gate remains vendor dependent Dolu1990 @Dolu1990 Sep 01 23:09 ok :D Paul Ruiz @pnru_gitlab 00:02
@lawrie @Dolu1990 I am not sure I understand the SDRAM questions. In any case, my latest version is here: https://gitlab.com/pnru/cortex/-/blob/master/sdram.v I am not sure what you mean by "using DDR io" - does the SDRAM chip on the ULX3S support DDR? Maybe you mean by DDR that it runs at twice the speed of the CPU or that it uses burst size 2? I don't know what the critical path in the SDRAM chip is, but I do have a hypothesis. When working with a CAS delay of 3 clocks, the data really arrives after 2 clocks plus 6-7ns (spending on the speed grade). If you clock a grade 6 chip (PC166) faster, a clock cycle will take less than 6ns and the data will only arrive after the third rising clock edge. My guess is that the 6-7ns is related to the speed of the sense amplifiers or something like that. resource utilizationhttps://gitter.im/ulx3s/Lobby?at=5f4f8c30d4f0f55ebbf93007 Dolu1990 @Dolu1990 Sep 02 14:12
Is somebody aware of a way to get hearchical ressource utilisation report out from yosys/next-pnr for ECP5 ? David Shah @daveshah1 Sep 02 14:18 You can get a hierarchical report with Yosys by passing -noflatten to synth_ecp5 ps2 keyboardhttps://gitter.im/ulx3s/Lobby?at=5f57e59c59ac794e02f71d14 Kid CUDA @KidCUDA_gitlab Sep 08 22:12
anyone used a PS2 keyboard with ULX3S? emard @emard Sep 08 22:52
@KidCUDA_gitlab US2 pins are 5V tolerant, limited by R and Zener diodes. Still some PS/2 keyboards don't accept 3.3V levels. Best is to obtain combo PS/2+USB they usually work in both modes for ULX3S cortexsource: https://gitlab.com/pnru/cortex https://gitter.im/ulx3s/Lobby?at=5f500a7eec534f584fdbeb15 Paul Ruiz @pnru_gitlab Sep 02 23:11 8s is super-comfortable! Btw I wonder how did cortex start, before it ever booted they need some filesystem to hold files. Is cortex filesystem mountable by modern linux? How did they made it in early times? The Cortex was a traditional home computer with Basic in its day. Running Unix on it was my project some 6-7 years ago. It was a long journey: porting a C compiler and tool chain, building simple kernels with a linked in user program (downloaded to the H/W via something similar to S-records), etc. When the time for disk access came, I used a tool to create & manage disk images.
For the original Unix, the file system was almost the first thing that was built, after the assembler (that is how a.out got its name: assembler output). An empty disk image was written by a custom format program. Files were then loaded from paper tape. Some 1969/1970 Unix code can be found here: emard @emard Sep 02 23:14 Ahaaaa so unix was not all the time available on cortex hardware. Still I'd wanted to know how did you initially start with populated filesystem. Normally e.g. if we have linux on riscv, we can mount the same partition on x86 PC, copy files and and it will work on riscv, but how was this done on cortex? So If I understood, you have a tool that from a directory creates disk image, but there's currently no support to actually mount cortex fs on linux for example. linux has some possibility to write a user-space fs driver like "fuse" but I ghess thats difficult and fragile Paul Ruiz @pnru_gitlab Sep 02 23:29
You can follow my journey here, in 315 commits:
I use a program ("ufs") which creates a disk image from scratch and then adds files to it. The source code is here: Even on the mini Cortex hardware, the CF Card uses FAT formatting and has an image file on it. I make sure the image is contiguous and the boot loader lets the Unix disk driver know in which sector the image starts. This way I can simply copy disk images to the CF card without needing to use special tools. Actually, the card also has disk images for other OS's as well - MDEX and NOS, which are somewhat similar to CP/M and MS-DOS 3 respectively. emard @emard Sep 02 23:44 There has been a lot of concentrated effort! The idea to use contiguous file in FAT is very good, so the CF itself can be easily written from laptop. Paul Ruiz @pnru_gitlab Sep 02 23:53 Thank you. The ulx3s Cortex has it even easier: because of the ESP32, now I don't even have to worry about things being contiguous and I can ftp disk images without having to handle the SD card. emard @emard Sep 03 00:34 yeees it was a piece of luck that for esp32 appeared good micropython support with almost all important things working and that spi-jtag adventure turned out successful. I have ulx3s with SD in a box and once inserted SD I never move out, just ftp files. Things will be even better when WROVER-E prototype starts working, 4MB RAM, 16MB FLASH no more out of memory. Bitstreams could be unzipped on-the-fly, even larger FLASH chips supported with 64K and 256K erase blocks (esp32 must buffer data size of erase block and now we are struggling with 4K buffers) saxonsoc audiohttps://gitter.im/ulx3s/Lobby?at=5f6482c3603d0b37f43d3ec0 Lawrie Griffiths @lawrie Sep 18 11:49 I have a 4-cpu 85F SaxonSoc version with music, working now.
It is now inSmp/bitstreams/ulx3s_85f_blue_4core_saxonsoc.bit
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
}
}
To play music do: mpg123 -T -f 4096 -m file.mp3. https://gitter.im/ulx3s/Lobby?at=5f648d8cf51808513b4f7db5 olu1990 @Dolu1990 Sep 18 12:35
.asoundrc isn't necessary, it just add volume controles in alsamixer app saxonsoc rtchttps://gitter.im/ulx3s/Lobby?at=5f69eb5d6a6e094525ac61f5 https://gitter.im/ulx3s/Lobby?at=5f69f087e1dd7c19548aad12 Dolu1990 @Dolu1990 Sep 22 14:39 got the rtc to start counting seconds and read it via : i2cset -y 0 0x6F 0x00 0x80 sleep 4 i2cget -y 0 0x6F 0x00 https://gitter.im/ulx3s/Lobby?at=5f6a4562e1dd7c19548b96f0 Lawrie Griffiths @lawrie Sep 22 20:41
oot@buildroot:~# cat date.sh
R6=`i2cget -y 0 0x6f 0x06`
R5=`i2cget -y 0 0x6f 0x05`
R4=`i2cget -y 0 0x6f 0x04`
R2=`i2cget -y 0 0x6f 0x02`
R1=`i2cget -y 0 0x6f 0x01`
YY="${R6:2:2}"
MON="$((${R5:2:2}-20))"
DD="${R4:2:2}"
HH="${R2:2:2}"
MM="${R1:2:2}"
echo "20$YY-$MON-$DD $HH:$MM"
root@buildroot:~# ./date.sh
2020-9-22 19:40
date -s "`./date.sh`"
https://gitter.im/ulx3s/Lobby?at=5f6a69588fe6f11963554984 emard @emard Sep 22 23:15
#include <stdio.h>
#include <stdlib.h>
#define I2C_SLAVE 0x703
#define O_RDWR 2
int i2c_rtc;
void rtc_open(int addr)
{
i2c_rtc = open("/dev/i2c-0", O_RDWR);
ioctl(i2c_rtc, I2C_SLAVE, addr);
}
void rtc_read(unsigned char *buf, int reg, int n)
{
buf[0] = reg;
write(i2c_rtc, buf, 1);
read(i2c_rtc, buf, n);
}
void i2cdemo(void)
{
int i;
unsigned char buf[7];
// mask for BCD SEC MIN HOUR WKDAY DAY MONTH YEAR
unsigned char mask[7] = {0x7F, 0x7F, 0x3F, 0x07, 0x3F, 0x1F, 0xFF};
rtc_read(buf, 0, sizeof(buf));
for(i = sizeof(buf)-1; i >= 0; i--)
printf(" %02x", buf[i] & mask[i]);
printf("\n");
}
int main(int argc, char *argv[])
{
int i;
rtc_open(0x6F);
for(i = 0; i < 60; i++)
{
i2cdemo();
sleep(1);
}
return 0;
}
root@buildroot:/home/root/rtc# ./a.out
20 09 22 02 21 14 27
20 09 22 02 21 14 28
20 09 22 02 21 14 29
20 09 22 02 21 14 30
20 09 22 02 21 14 31
saxonsoc jtaghttps://gitter.im/ulx3s/Lobby?at=5f78c209dfe47e4d57464c10 Lawrie Griffiths @lawrie Oct 03 20:25 The pins to connect to are these - https://github.com/SpinalHDL/SaxonSoc/blob/dev-0.1/hardware/synthesis/radiona/ulx3s/smp/ulx3s_v20_linux_uboot.lpf#L342-L348 emard @emard Oct 03 20:26
I tried to upload SVF file and it works, (fast). Yes, this pins connection is important. Is there a simple JTAG openocd scan command I can test it to make sure I connected all jtag newtap lfe5 tap -expected-id 0x21111043 -irlen 8 -irmask 0xFF -ircapture 0x5 Dolu1990 @Dolu1990 Oct 03 20:29 hoo when openocd run it scan everything emard @emard Oct 03 20:29 yes yes I see it on above linked script Dolu1990 @Dolu1990 Oct 03 20:30 i'm not sur there a command to rescan, just rerun it ^^ emard @emard Oct 03 20:31 OK I need to make a bit on the solder and pins to board, then I will test it and when I get vexrisc scanned by openocd jtag I will put it online for remote access Dolu1990 @Dolu1990 Oct 03 20:31 you should get a scan like 0x10001FFF Lawrie Griffiths @lawrie Oct 03 20:33 @Dolu1990 Doesn't @emard need to build your version of openocd - https://github.com/SpinalHDL/openocd_riscv Dolu1990 @Dolu1990 Oct 03 20:34
Yes Dolu1990 @Dolu1990 Oct 03 21:02 sudo apt-get install libtool automake libusb-1.0.0-dev texinfo libusb-dev libyaml-dev pkg-config for the full depedency on debian emard @emard 00:00 Escape character is '^]'. Open On-Chip Debugger > init > scan_chain TapName Enabled IdCode Expected IrLen IrCap IrMask -- ------------------- -------- ---------- ---------- ----- ----- ------ 0 fpga_spinal.bridge Y 0x10001fff 0x10001fff 4 0x01 0x0f Got openocd to connect https://gitter.im/ulx3s/Lobby?at=5f7c33646e0eb844696af0a2 Lawrie Griffiths @lawrie 11:05 You then need a usb JTAG device, preferably an FT2232 one, and you connect the pins to gn0 - gn3. I have not used openocd with SaxonSoc for a while, but @Dolu1990 uses it all the time. micropython sockshttps://gitter.im/ulx3s/Lobby/archives/2020/10/10?at=5f820bfb07361f0cc6430489 kost @kost Oct 10 19:31 UTC
since you guys around SaxonSoc made such a great progress. I had to do my part of the promise.
import upip
upip.install('micropython-socks')
and then you can just simply say: import socks socks.start()
it will start listening on 0.0.0.0:1080 for SOCKS5 connections. curl --socks5 192.168.4.1:1080 http://ifconfig.co nmigen - OV7670 with st7789https://gitter.im/ulx3s/Lobby?at=5f949a4e6c8d484be2a6df34 Lawrie Griffiths @lawrie Oct 24 23:19 @goran-mahovlic I now have a version of the OV7670 camera application working in nmigen with the st7789 display - https://github.com/lawrie/ulx3s-nmigen-examples/tree/master/ov7670 oberonhttps://gitter.im/ulx3s/Lobby?at=5f949d40270d004bcfea9716 Charles Perkins @charlesap Oct 24 23:31 @pnru_gitlab @emard I have created a new disk image based on the www.projectoberon.com sources, only adding some more LED output in the inner core boot process. Here's a zip file of a disk image that you should be able to directly write to an SD card: https://github.com/io-core/io/blob/main/images/ledboot.img.zip ... this image has the Oberon partition at the correct offset but I did not bother to format the first part with a FAT partition. It boots on my ulx3s with the earlier Oberon .bit file. Here's the meaning of the LEDs on booting: LEDs: 7------- In BootLoad Firmware LEDs: 7-----1- In BootLoad Firmware LEDs: 7----2-- In BootLoad Firmware LEDs: -------0 Control transferred to Modules LEDs: ------1- Control transferred to Files LEDs: -----2-- Control transferred to Kernel LEDs: ----3--- In Kernel - Temporary Trap installed LEDs: ---4---- In Kernel - Stack and heap origins and limits configured LEDs: --5----- Kernel SecMap initialized, control transferred to FileDir LEDs: -6------ Directory traversal complete LEDs: 7------- Sectors marked, control transferred to Modules which has loaded Oberon. LEDs: -------- Icons are defined, display subsystem initialized, ready to load System. LEDs: --5----0 GC in the Oberon Loop LEDs: --5---10 GC in the Oberon Loop LEDs: --5--210 GC in the Oberon Loop LEDs: --5-----
If there is an early trap before the system introduces a nicer printing trap the leds will fast-blink now with the trap value (0-7). The Oberon source code modified with the LED output is here:
https://github.com/io-orig/projectoberon/blob/main/Kernel.Mod.NL oled pinshttps://gitter.im/ulx3s/Lobby?at=5fa2bcb374152347c213d4ae emard @emard Nov 04 11:59
@sthornington yes bitstream projects do rearrange pins. At least GND and 3.3V must match, FPGA is flexible about pins, practical is to plug display directly without wires. Original markings are for SSD1331. ST7789 7-pin is similar but I think pin has BL (backlight) function instead of CS. wifi_gpio17 refers to the same thing and also ESP32 is flexible about SPI pinout so you can match practicaly any combination. @sthornington of course GND and VCC can't be swapped by FPGA, because OLED draws current and must connect to hard power supply, can't be powered from FPGA 16mA pins (so low power devices actually could swap even GND/VCC). new board will have 8-pin LCD header instead of 7-pin but there's really crowded with routing so additional 2 pins are nearly impossible. But if display has GND and VCC swapped, then it will fit to external connector GN/GN 0-27 so there's still a possibility to plug such display directly on board on the side rtc - i2c master examplehttps://gitter.im/ulx3s/Lobby?at=5fa7ba79c6fe0131d4e19d31 emard @emard Nov 08 10:29 There is example https://github.com/emard/ulx3s-misc/tree/master/examples/rtc/i2c_master/proj which makes i2c master in verilog, talks to RTC and displays time as HEX on DVI and LCD. There can't be interference with ESP32 because ESP32 is not directly connected to RTC, FPGA is between them. rt2232 second channel openocdhttps://gitter.im/ulx3s/Lobby?at=5fc57a82150b213e980592d8 emard @emard 00:04 @sthornington if you have external ft2232 it is fastest and normally used as openocd jtag debugger for softcore cpus like litex or saxonsoc linux. Secondary US1 channel is possible and fully supported by openocd, but it will be unacceptably slow to transfer big files like kernel or root fs images. https://github.com/emard/ulx3s-jtagthru/blob/master/scripts/ft231x2.ocd here is some project that has openocd script to export secondard jtag channel to external pins but normally you can use it internally to soft-core too. See also the schematics for your board (v3.0.8) how FTDI is connected to FPGA Simon Thornington @sthornington 01:04 @emard thanks, mostly what I want to get going is an on-board scope to dump traces, is there any particular recommended F2232 interface? Does that plug into the jtag header of the below the oled one? emard @emard 02:56 any FT2232 breakout board or programmer is ok. It should connect to external pins GP/GN something, depends on where litex/saxonsoc expects them, usually pins 0-5 I guess. I does not plug to JTAG header, it doesn't need to program ECP5 but the CPU RISC5 done by FPGA. If you need onboard scope to display traces in realtime check hdl4fpga project, it has great scope for our boards. esp32 passthroughhttps://gitter.im/ulx3s/Lobby?at=601c699dd0d32d7d4fc94dfc liebman @liebman Feb 04 22:39 @emard this one is improved. It tristates gpio0 instead if setting it high so that it can be used elsewhere if needed. Also added an enable that can be used as a reset for the esp32. module ulx3s_passthru ( input wire txd, output wire rxd, input wire dtr, input wire rts, input wire esp_txd, output wire esp_rxd, output wire esp_en, output wire esp_io0, input wire en, ); // TX/RX passthru assign rxd = esp_txd; assign esp_rxd = txd; // Programming logic // SERIAL -> ESP32 // DTR RTS -> EN IO0 // 1 1 1 Z // 0 0 1 Z // 1 0 0 Z // 0 1 1 0 assign esp_en = (~dtr | rts) & en; assign esp_io0 = ( dtr | ~rts) ? 1'bz : 1'b0; // we only want to drive this pin low endmodule can be called like
module top(
input wire clk_25mhz,
output wire ftdi_rxd,
input wire ftdi_txd,
inout wire ftdi_ndtr,
inout wire ftdi_nrts,
output wire wifi_rxd,
input wire wifi_txd,
inout wire wifi_en,
inout wire wifi_gpio0,
output [7:0] led,
input [6:0] btn,
output wire shutdown,
);
ulx3s_passthru passthru(.txd(ftdi_txd),
.rxd(ftdi_rxd),
.dtr(ftdi_ndtr),
.rts(ftdi_nrts),
.esp_txd(wifi_txd),
.esp_rxd(wifi_rxd),
.esp_en(wifi_en),
.esp_io0(wifi_gpio0),
.en(btn[0]), // btn[0] will work as a reset for esp
);
// blinky for something to do so we know its operational
assign led[0] = btn[1];
assign led[6:1] = 0;
assign led[7] = wifi_gpio0;
endmodule
liebman @liebman Feb 04 23:18
thats good to know, which are the (non esp) pins that are clock capable? emard @emard Feb 04 23:19
They are mentioned on pdf schematics_v3.0.8 let me see PCLK .. means primary clock capable pins. they are best. GR_PCLK are second best, general routed to primary clock capable A small fix could be possible with a jumper GN11-GN12 this will connect ESP32 pin 25 GN11 which is output capable to FPGA clock input capable at GN12 lpf documentationhttps://gitter.im/ulx3s/Lobby?at=601fa45432e01b4f717e0ebb Dave Anderson @danderson 09:27
Couldn't find any decent docs other than nextpnr source code and poorly explained technical notes from lattice, so I wrote https://github.com/danderson/ulxs/blob/main/lpf.md hdmihttps://gitter.im/ulx3s/Lobby?at=6029a8349337c51bc688733e splinedrive @splinedrive Feb 14 23:46 Hi, I have done a hdmi reimplementation for ulx3s and blackicemx (ice40) they have the same code base. I hope you like it. I learned from other projects to take the semantic (ulx3s-examples-dvi, fpga4fun, ...) . ulx3s has DDR and SRD support and blackicemx can only DDR. I used the pmod from Luke Wren. It works only with passive resistors and works with long hdmi cables without any problems. https://github.com/splinedrive/my_hdmi_device osdhttps://gitter.im/ulx3s/Lobby?at=603a1016457d6b4a948f3208 Lawrie Griffiths @lawrie 10:25
@sylefeb I am not sure that between us, @emard and I, have documented the OSD and rom loader very well. There are lots of versions of the code in different projects. This is the spi slave from my Z80 template project - https://github.com/lawrie/ulx3s_z80_template/blob/main/src/osd/spirw_slave_v.v
This is my TRS 80 Model 1 implementation that has a short description on using the OSD - https://github.com/lawrie/ulx3s_z80_trs80
The OSD and loader is used by many Ulx3s projects including the Apple II, C64, ZX Spectrum, Mac Plus, QL, TI-99/4A, Amiga (OSD only), Vic 20, NES, SNES, Sega Master System, Orao, etc. emard @emard 12:16 @sylefeb @lawrie OSD loader behaves similar as SPI RAM using 32-bit byte address. FPGA behaves as SPI slave, ESP32 as SPI master. If slave needs to initiate transfer, there is additional IRQ line. Resources at SPI address space are memory mapped, RAM to upload for CPU, reset/halt control, buttons, OSD video chars, floppy disks etc. All is very simple and protocol is not too much standardized so it can be adapted to completely unusual usage. Generally for apple2 c64 vic20 mac trs80 etc we just copy-paste the same thing saxonsoc memory maphttps://gitter.im/ulx3s/Lobby?at=606dcc72bc8e6f2e0d2e5be9 Dolu1990 @Dolu1990 Apr 07 17:14 @irvise:matrix.org 0x340000 That's the flash address. the CPU copy that part of the flash to the SDRAM at 0x80F80000 (global address). See :
Memory copy : https://github.com/SpinalHDL/SaxonSoc/blob/dev-0.3/bsp/radiona/ulx3s/smp/app/bootloaderConfig.h#L99 Then it does similar things with uboot but with that set of addresses : https://github.com/SpinalHDL/SaxonSoc/blob/dev-0.3/bsp/radiona/ulx3s/smp/app/bootloaderConfig.h#L22 if I generate a program that load to the address 0x380000 it should "just work" Yes, as long you programe is complied to sit at 0x80F00000 in the global memory space And where can I find more info on what memory addresses are being used for MMIO This autogenerated header file contains all the peripheral addresses : https://github.com/SpinalHDL/SaxonSoc/blob/dev-0.3/bsp/radiona/ulx3s/smp/include/soc.h#L64 blink
See https://github.com/SpinalHDL/SaxonSoc/blob/dev-0.3/software/standalone/blinkAndEcho/src/main.c you can compile it using the command "saxon_standalone_compile blinkAndEcho" It will sit where uboot sit (see https://github.com/SpinalHDL/SaxonSoc/blob/dev-0.3/bsp/radiona/ulx3s/smp/linker/default.ld#L1) nmigenhttps://gitter.im/ulx3s/Lobby?at=608e7b59d5e2793379e961a8 Lawrie Griffiths @lawrie May 02 12:13
I am currently working on my nmigen OV7670 camera application - https://github.com/lawrie/ulx3s-nmigen-examples/blob/master/image/camtest.py The latest code that I have pushed calculates the mouse pointer (p_x, p_y) - https://github.com/lawrie/ulx3s-nmigen-examples/blob/master/image/image_stream.py If you set the ImageStream filter switch then pixels with a red channel value less than some threshold are filtered out and the remaining pixels are displayed on the HDMI monitor as pure red. You can adjust the threshold with the up and down arrows, and a value of about 30 seems best. As the threshold is increased the picture turns black except where the laser pointer points, and the spot gets smaller as the threshold is increased. I then calculate the min and max x and y values for those red pixels, and calculate the mid points as p_x and p_y. It seems to be working. saxon esp32ecp5 starthttps://gitter.im/ulx3s/Lobby?at=60b93a55a10461235db71cff emard @emard Jun 03 22:23 I have just checked saxonsoc linux and it still works, lAN8720 ethernet (ssh) works out of the box. Tetris still compiles and works. A small hint here is the esp32 script for new esp32ecp5 to start linux
import os
from machine import SDCard, Pin
import ecp5
os.mount(SDCard(slot=3),"/sd")
# copy to root of SD card: dtb, rootfs.cpio.uboot, uImage
# flash with "False" without starting the bitstream
ecp5.flash("/sd/linux/smp/fw_jump.bin@0x340000",0x340000,False)
ecp5.flash("/sd/linux/smp/u-boot.bin@0x380000",0x380000,False)
ecp5.prog("/sd/linux/smp/ulx3s_12f_1core_saxonsoc.bit")
os.umount("/sd")
p12=Pin(12,Pin.IN)
p13=Pin(13,Pin.IN)
p14=Pin(14,Pin.IN)
p15=Pin(15,Pin.IN)
With esp32ecp5 I'd recommend micropython builds with idf3 because idf4 builds reboot ad SD card deinit (ftp> site umount) dfu and openfpgaloaderhttps://gitter.im/ulx3s/Lobby?at=6213c5d29a09ab24f36e464d I suggest new passthru with DFU integrated. Get or compile latest openFPGALoader. connect to US1 and flash this first: You don't need to unzip, openfpgaloader will detect .gz and unzip on-the-fly download https://github.com/emard/ulx3s-bin/blob/master/fpga/dfu/85f-v317/multiboot.img.gz openFPGALoader -b ulx3s -f --unprotect-flash --file-type raw multiboot.img.gz If you hold BTN1 or set DIP SW1 ON and plug board to US2 (optionally press BTN0 if it doesn't power up at plug) then USB DFU compatible device should be detected and you can use much faster flashing like this openFPGALoader -b ulx3s_dfu bitstream.bit This is for user-bitstream, if you need to reflash bootloader DFU itself from US2, hold BTN1 and BTN2 together and use DFU alternate 5 option back to ESP32: plug to US1 again and try to erase and flash ESP32 bootloader switcheshttps://gitter.im/ulx3s/Lobby?at=62370af9f43b6d783f0de7d8 emard @emard 12:07 @NostosArch bootloader checks DIP SW1 state on power up. Switching it afterwards doesn't matter. 3 LEDs ON means it is DFU bootloader and passthru, and US2 should enumerate DFU with 3 LEDS it should be possible to flash esp32 with 3 LEDs on. 7 LEDs on means it is in passthru only (not DFU) mode. esp32 should be able to be flashed from passthru-only mode like from DFU+passthru mode. Apart from that I can either say esp32 is flashed with something difficult to get rid of or another PC and OS should be tried. I didn't follow, but are you using linux microsoft or apple? Does ESP32 respond with ">>>" usbserial 115200 micropyhton prompt on US1? If you upload blink, then passthru-only mode is overwritten. Still DFU+passthru mode (3 LEDs) is kept (write protected from fujprog, only openfpgaloader can overwrite bootloader). So DFU+passthru 3 LEDS should allow flashing esp32 but of course PCs and OSs compatibility and contents of esp32 already flashed may cause difficulty OverviewSTM32F107 RBT6 + QCA8337 AL3C based router with serial and swd headers Mainstream Connectivity line, ARM Cortex-M3 MCU with 128 Kbytes Flash, 72 MHz CPU, Ethernet MAC, CAN and USB 2.0 OTG FirmwareAccording to https://wiki.mikrotik.com/wiki/SwOS/RB250_RB260#Summary new RB260GS (CSS106-5G-1S), new RB260GSP(CSS106-1G-4P-1S) supports SwOS v2.0 and newer. Example working (as of 2018-07-06) url download links which work for CSS106-5G-1S:
https://download2.mikrotik.com/swos2/css106/swos-css1061g4p1s-2.0.bin dpavlin@lib10:/lib10/arh-hw/backup/Mikrotik-RB260GS-CSS106-5G-1S/rb260gsp$ md5sum * bf110ca7e1cd0558cefeacd9e0b62c19 swos-css1061g4p1s-2.0.bin a491bbf2732937839e6a8222a876cc7a swos-css1061g4p1s-2.2.bin f098106dfc8ac5ad0fedf0181c68d8de swos-css1061g4p1s-2.3.bin f4f74f697039a83baa99d37017251805 swos-css1061g4p1s-2.4.bin 90d2ec8571dd9d9aeab1bfbaaa99dea2 swos-css1061g4p1s-2.5.bin a7f046fc8a12b5ebeb85f9a4bb0dd275 swos-css1061g4p1s-2.6.bin a1e7adc6ad63e5560156b0f2b6f272ce swos-css1061g4p1s-2.7.bin https://mikrotik.com/download (SwitchOS) latest version: https://download.mikrotik.com/swos2/css106/swos-css106-2.13.bin versionfrom web interface Firmware Current Installed Version 2.7 (built at Fri Dec 15 2017 09:42:48 GMT+0100 (CET)) Latest Available Version 2.7 (built at Fri Dec 15 2017 09:42:48 GMT+0100 (CET)) reset
SwOS v2.x - RB260GS(CSS106-5G-1S) and RB260GSP(CSS106-1G-4P-1S) The new RB260GS(CSS106-5G-1S) and RB260GSP(CSS106-1G-4P-1S) has built-in backup SwOS firmware which can be loaded in case standard firmware breaks or upgrade fails:
Holding Reset button for few seconds while device is booting resets configuration and loads backup firmware SwOS 2.0p. default ip: 192.168.88.1Current Installed Version 2.0p (built at Fri Oct 21 2016 10:18:39 GMT+0200 (CEST)) Latest Available Version 2.7 (built at Fri Dec 15 2017 09:42:48 GMT+0100 (CET)) After this, router knows that there is new version, but can't download it from http://upgrade.mikrotik.com/swos2/css106/swos-css106-2.7.bin Linux setupdpavlin@x230:~$ sudo ifconfig enp0s25 192.168.88.240 wget --http-user=admin --http-password='' 'http://192.168.88.1/!stats.b' find on networkhttps://forum.mikrotik.com/viewtopic.php?t=162881 https://wiki.mikrotik.com/wiki/MAC_access MNDP frames sudo apt install mactelnet-client dpavlin@klin:~$ mndp Searching for MikroTik routers... Abort with CTRL+C. IP MAC-Address Identity (platform version hardware) uptime 192.168.88.1 c4:ad:34:47:12:91 MikroTik (MikroTik 2.7 CSS106-5G-1S) up 113 days 4 hours 10.60.0.1 d4:ca:6d:1:4c:ed ccr (MikroTik 6.46.6 (testing) CCR1036-8G-2S+) up 113 days 4 hours XYIT-4UTW bridge60/sfp2-60 https://gregdavill.github.io/OrangeCrab/ https://github.com/gregdavill/OrangeCrab [Mon Sep 14 13:46:12 2020] usb 2-2.3: new full-speed USB device number 8 using xhci_hcd [Mon Sep 14 13:46:12 2020] usb 2-2.3: New USB device found, idVendor=1209, idProduct=5af0, bcdDevice= 1.01 [Mon Sep 14 13:46:12 2020] usb 2-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [Mon Sep 14 13:46:12 2020] usb 2-2.3: Product: OrangeCrab r0.2 DFU Bootloader v3.1 [Mon Sep 14 13:46:12 2020] usb 2-2.3: Manufacturer: GsD Microwatt with Linux on OrangeCrabhttps://codeconstruct.com.au/docs/microwatt-orangecrab/ ⦗OSS CAD Suite⦘ dpavlin@klin:/klin/FPGA/microwatt$ make microwatt.bit 2>&1 | tee ~/tmp/build1.txt |
Weblog Archives
|
