µConsole GPIO breakout board



so: sketchy 3rd party straight through FPC adapter is confirmed to work.
no heating up the core, device works normally (although i didn’t tested thoroughly, dangling fpc isn’t that comfortable).
Pins 1-6 gives 3v3, pins 2-6 gives 5v so i’d say it’s success. Today i’ll try to hook up UART and see where this leads me to

2 Likes

okay, so something is pretty shitty here.

With UART (gpio14/15, pins 8/10) plugged in WIFI doesn’t work.
What’s more interesting, only FPC ribbon plugged at the µConsole’s end makes WIFI unavailable.
i’ve compared two dmesges

sunxi-rtc 7090000.rtc: setting system clock to 1970-01-01T00: |	sunxi-rtc 7090000.rtc: setting system clock to 1970-01-01T00:
random: fast init done					      <
							      >	random: fast init done
mmc1: error -110 whilst initialising SDIO card		      |	mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
sunxi-mmc 4021000.sdmmc: sdc set ios:clk 0Hz bm PP pm OFF vdd <
							      >	mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
							      >	mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
							      >	mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
							      >	mmc1: queuing unknown CIS tuple 0x81 (9 bytes)
							      >	sunxi-mmc 4021000.sdmmc: sdc set ios:clk 400000Hz bm PP pm ON
							      >	sunxi-mmc 4021000.sdmmc: sdc set ios:clk 50000000Hz bm PP pm 
							      >	sunxi-mmc 4021000.sdmmc: sdc set ios:clk 50000000Hz bm PP pm 
							      >	mmc1: new high speed SDIO card at address 0001
systemd[1]: Detected architecture riscv64.		      <
systemd[1]: Hostname set to <uConsole-R01>.		      <
							      >	systemd[1]: Detected architecture riscv64.
							      >	systemd[1]: Hostname set to <uConsole-R01>.
random: lvmconfig: uninitialized urandom read (4 bytes read)  <
							      >	random: lvmconfig: uninitialized urandom read (4 bytes read)
systemd[1]: Starting Coldplug All udev Devices...	      <
							      >	systemd[1]: Starting Coldplug All udev Devices...
							      >	systemd[1]: Finished Remount Root and Kernel File Systems.
							      >	systemd[1]: Mounting FUSE Control File System...
							      >	systemd[1]: Mounting Kernel Configuration File System...
							      >	systemd[1]: Starting Load/Save Random Seed...
							      >	systemd[1]: Starting Create System Users...
random: crng init done					      <
random: 6 urandom warning(s) missed due to ratelimiting	      <
							      >	random: crng init done
							      >	random: 6 urandom warning(s) missed due to ratelimiting
							      >	brcmfmac: F1 signature read @0x18000000=0x15294345
							      >	brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sd
							      >	brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sd
							      >	brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (er
							      >	brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/9 wl0: Feb
							      >	systemd-journald[102]: Failed to read journal file /var/log/j
							      >	IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

this is rather electrical problem, like high impedance etc, but bottom line is: UART is dead :C

so overall buying BB was pointless because as stated in the ‘booby trapped devterm’ topic all gpios are in use where most of them drives sdio wifi/bt chip. which is utterly dissapointing given that r01 variant especially was advertised as device for tinkerers and those bave ones.

what to tinker about if i can’t even communicate with device before OS drives lcd because uart is hardwired to wifi for god knows what reason?

at the moment only reasonable option to develop anything lowlevel for r01 is to buy lichee rv dock, do work there and move results into uconsole. which sucks.

maybe i think about cutting rx tx traces leading to wifi to see if actual serial isn’t somehow pulled down by wifi chip while wifi isn’t initialized. but really, i was expecting way more hackability than creating custom expansion cards with usb-stuff attached to them. Even driving stupid ssd1306 is beyond this devices capabilities at the moment so bye bye fantasies about external ‘notifications counter’ or ‘battery status’.

This may be of interest to you: uPico Expansion Card

Yes, Pico is connected via internal USB

i see your point, but what i eventually wanted to use was serial console. one where u-boot spits out OS selectors, possibly some SBI messages to see why official openSBI from RISC-V foundation doesn’t let machine to boot.

One might say i am only complaining, but attaching arduino over usb to have usb-serial device on OS level to drive a LED on this arduino board i consider an overkill where underlying device has all busess which i might want to use.

Any breakthroughs for the uConsole/DevTerm are welcome. The GPIO situation does sound frustrating, however.

So, after much frustration and many failed attemps there’s finally some progress.

TX pin on R01-based µConsole is on GPIO 32. Serial connection uses 3v3 logic so one has to use at least CP2102/ FTDI usbserial converters with selectable IO standards.

Anyway

[49]HELLO! BOOT0 is starting!
[52]BOOT0 commit : 
[54]set pll start
[55]periph0 has been enabled
[58]set pll end
[60]board init ok
[62]DRAM only have internal ZQ!!
[65]get_pmu_exist() = -1
[67]ddr_efuse_type: 0x0
[70][AUTO DEBUG] two rank and full DQ!
[74]ddr_efuse_type: 0x0
[77][AUTO DEBUG] rank 0 row = 15 
[80][AUTO DEBUG] rank 0 bank = 8 
[83][AUTO DEBUG] rank 0 page size = 2 KB 
[87][AUTO DEBUG] rank 1 row = 15 
[90][AUTO DEBUG] rank 1 bank = 8 
[93][AUTO DEBUG] rank 1 page size = 2 KB 
[97]rank1 config same as rank0
[99]DRAM BOOT DRIVE INFO: V0.24
[102]DRAM CLK = 792 MHz
[105]DRAM Type = 3 (2:DDR2,3:DDR3)
[108]DRAMC ZQ value: 0x7b7bfb
[110]DRAM ODT value: 0x42.
[113]ddr_efuse_type: 0x0
[116]DRAM SIZE =1024 M
[120]DRAM simple test OK.
[122]dram size =1024
[124]card no is 0
[126]sdcard 0 line count 4
[128][mmc]: mmc driver ver 2021-04-2 16:45
[137][mmc]: Wrong media type 0x0
[140][mmc]: ***Try SD card 0***
[150][mmc]: HSSDR52/SDR25 4 bit
[153][mmc]: 50000000 Hz
[156][mmc]: 30003 MB
[158][mmc]: ***SD/MMC 0 init OK!!!***
[205]Loading boot-pkg Succeed(index=0).
[209]Entry_name        = opensbi
[212]Entry_name        = dtb
[215]Entry_name        = u-boot
[218]Jump to second Boot.

OpenSBI v0.9-204-gc9024b5
Build time: 2024-07-13 16:25:15 +0200
Build compiler: gcc version 11.4.0 (Debian 11.4.0-5)
   ____                    _____ ____ _____
  / __ \                  / ____|  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |____) | |_) || |_
  \____/| .__/ \___|_| |_|_____/|____/_____|
        | |
        |_|

Platform Name             : Allwinner D1 NeZha
Platform Features         : medeleg
Platform HART Count       : 1
Platform IPI Device       : aclint-mswi
Platform Timer Device     : aclint-mtimer @ 24000000Hz
Platform Console Device   : uart8250
Platform HSM Device       : ---
Platform Reboot Device    : sunxi-wdt-reset
Platform Shutdown Device  : ---
Firmware Base             : 0x40000000
Firmware Size             : 252 KB
Runtime SBI Version       : 0.3

Domain0 Name              : root
Domain0 Boot HART         : 0
Domain0 HARTs             : 0*
Domain0 Region00          : 0x0000000014008000-0x000000001400bfff (I)
Domain0 Region01          : 0x0000000014000000-0x0000000014007fff (I)
Domain0 Region02          : 0x0000000040000000-0x000000004003ffff ()
Domain0 Region03          : 0x0000000000000000-0xffffffffffffffff (R,W,X)
Domain0 Next Address      : 0x000000004a000000
Domain0 Next Arg1         : 0x0000000044000000
Domain0 Next Mode         : S-mode
Domain0 SysReset          : yes

Boot HART ID              : 0
Boot HART Domain          : root
Boot HART ISA             : rv64imafdcvsux
Boot HART Features        : scounteren,mcounteren,mcountinhibit,time
Boot HART PMP Count       : 16
Boot HART PMP Granularity : 2048
Boot HART PMP Address Bits: 38
Boot HART MHPM Count      : 0
Boot HART MIDELEG         : 0x0000000000000222
Boot HART MEDELEG         : 0x000000000000b109


U-Boot 2022.01-17750-gd5c119c132 (Jul 13 2024 - 14:29:00 +0200)

CPU:   rv64imafdc
Model: Allwinner D1 NeZha
DRAM:  512 MiB
Core:  57 devices, 21 uclasses, devicetree: separate
WDT:   Started watchdog@6011000 with servicing (16s timeout)
MMC:   mmc@4020000: 0, mmc@4021000: 1
Loading Environment from nowhere... OK
In:    serial@2500000
Out:   serial@2500000
Err:   serial@2500000
Net:   
Warning: ethernet@4500000 (eth0) using random MAC address - 3a:48:e8:34:9b:2d
eth0: ethernet@4500000
Hit any key to stop autoboot:  2  1  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:3...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
1:	DevTerm R01 OS 5.4.61
Retrieving file: /vmlinuz-5.4.61+
append: root=/dev/mmcblk0p4 earlyprintk=sunxi-uart,0x02500400 clk_ignore_unused initcall_debug=0 console=ttyS0,115200 console=tty0 cma=64M LANG=en_US.UTF-8 fbcon=rotate:1 vt.cur_default=0xF00058 consoleblank=240 loglevel=8 random.trust_cpu=on console=ttyS1,115200
Retrieving file: /uc_board.dtb
   Uncompressing Kernel Image
## Flattened Device Tree blob at 4fa00000
   Booting using the fdt blob at 0x4fa00000
ERROR: reserving fdt memory region failed (addr=42000000 size=100000 flags=0)
ERROR: reserving fdt memory region failed (addr=41fc0000 size=20000 flags=0)
   Loading Device Tree to 0000000049fef000, end 0000000049fff331 ... OK

Starting kernel ...

[    0.000000] OF: fdt: Ignoring memory range 0x40000000 - 0x40200000
[    0.000000] Linux version 5.4.61+ (cpi@cpi-X79) (riscv64-unknown-linux-gnu-gcc (C-SKY RISCV Tools V1.8.4 B20200702) 8.1.0, GNU ld (GNU Binutils) 2.32) #7 PREEMPT Thu Aug 31 14:36:23 CST 2023

Why it’s like that is beyond me. Anyway, i’ve learned that ZSBL (zero stage boot loader) may pass DTB to OpenSBI, which then passes control to U-Boot, which in our case boots extlinux with another DTB ;d

Bottom line of this dominoes is that FDT which is present in /boot might not exactly be same which OpenSBI is given, therefore it’s possible that serial0’s definition which i’ve posted earlier doesn’t neccesairly must be “the right one”.

Here in chapter Generate u-boot toc author is generating first 32M of SD card which consists of, amongst others of DTB. I am pretty positive that this DTB is one which determines where serial0 is.

For those of you like @isaacwoods - just grab GND and GPIO32 from EXT slot to CP2102 and you’re somewhat good to go.

probably RX pin is biggest PEBCAK in my whole life. While dealing with soft-bricked TheA500 Mini i’ve found that terminal program that i am using (minicom) does come with hardware flow control (CTS/DTR) turned on by default ;d This means that unless application won’t be ‘convinced’ that connection was established, it won’t sent a single bit over wire. Today i am bit tired, but tommorow i want to ultimately solve “mystery of uart”.

@isaacwoods do you still want to develeop an extension with serial broken out? ;d

So RX is GPIO33 (mic drop)

1 Like