Add hardware-verified V536 (0x1816) UART support and fix thunk_addr - #254
Add hardware-verified V536 (0x1816) UART support and fix thunk_addr#254akalime wants to merge 3 commits into
Conversation
|
Tested on real Allwinner V536 hardware (Eonon T86PRO_V101 dashcam). Key difference from previous attempt (Dec 2021): that PR was tested on |
|
$ sudo ./sunxi-fel version uart0: ttyS0 at MMIO 0x5000000 sunxi-wdt 30090a0.watchdog: Watchdog enabled (timeout=16 sec, nowayout=0) sunxi-sid@03006000 |
|
Hi, thanks for looking at this. I've just given it a try on my V536 Lindenis board and the UART part is not good. Indeed The rest looks correct though. |
|
Thanks for reviewing my contribution.As requested I have consolidated both PR's here. On my specific hardware the soc was confirmed via FEL. soc_id 0x1816 = V536 with the UART0 base 0x05000000 confirmed via kernel boot log "uart0: ttyS0 at MMIO 0x5000000 (irq = 31, base_baud = 1500000) - is a 16550A". Here's the build string as well from my specific device as well as soc AWUSBFEX soc=00001816(V536) 00000001 ver=0001 44 08 scratchpad=00027e00 "v536_tccdr1600x600m61_cpapaamc01" PH9/MUX_5 is confirmed working on my specific device however I don't have specific access to V536 datasheet myself. If this is a public link it would be greatly appreciated if you could send that to me or refer to the link directly. Regarding thunk_addr 0x2E000: The upstream value 0x2A200 failed on the specific hardware I'm working with. 0x2E000 was found by trial and error within the valid SRAM range then confirmed by successfully completing a full 16MB SPI NOR flash dump and reflash using sunxi-fel, spiflash-read, and spiflash-write during security research on this device. If interested I can send or host the flash dump directly for you. Kind regards. |
|
After further research — Allwinner's official documentation for the V853 (same silicon family as V536) explicitly shows UART0 on PH9/PH10 at MUX_5. Additionally, the Lindenis V536 wiki notes that ttyS3 is assigned to the Linux console on that board, not ttyS0/UART0. This suggests PH7/MUX_3 may be UART3 on the Lindenis board rather than UART0, which would explain the difference. My kernel boot log confirms ttyS0/UART0 at MMIO 0x5000000 on PH9/MUX_5 Could you possibly verify your board used ttyS0 instead of ttyS3 I'm wondering if that information could bridge this gap. If that's the case it might be worth an extra commit giving both there own dedicated entries. References https://docs.aw-ol.com/v853/en/soft/dev_gpio/ http://wiki.lindeni.org/index.php/Lindenis_V536#Uart
|
|
You can find the manual for V536 at: https://www.lcsc.com/datasheet/C3036459.pdf Also note that V536 is And yes the Lindenis V536 board has UART4 (according to the schematics, not the website) on the J12 debug connector, but I have tested UART0 which has a connector on the SOM. Can you show me where your kenrel log mentions that UART0 is on PH9 mux 5? That still does not look correct to me. |
|
My apologies, I wasn't trying to be ignorant. I just wanted to make sure everything was correct and was going off my notes while at work. Upon further inspection of the live device you are correct, addressing this now. HELLO! BOOT0 is starting! |
|
Did you manage to get the uart0 hello world example running via fel? It works fine here! Now you have one commit introducing the entry and another one changing that entry: it is better to have a single commit introducing its final version directly, so you can squash these two commits into a single one. The commit messages also need to be reworked a bit to be a bit more descriptive and formatted. We generally like to use a prefix like "bare-metal: " to the message to narrow down which part of the code it touches and also mention the affected chip. Something like "bare-metal: Add new device entry for V536" and "soc_info: Fix V536 thunk address". For the latter, it would also be good to write a few words about how the issue with the thunk address was discovered and how the new value was decided and checked. It doesn't need to be very detailed, just enough to know that it comes from experimentation. We are getting closer to something we can merge, keep going! |
|
Yes absolutely I will fix this when I get back. I'm currently away. |
2 participants
bare-metal: Add hardware-verified V536 (0x1816) support
Add V536 to bare-metal.c SoC table and correct thunk_addr in soc_info.c.
bare-metal.c: Add V536 (0x1816) entry with UART0 at 0x05000000 on
SUNXI_GPH(9) MUX_5, verified on Eonon T86PRO_V101 hardware by reading
live UART struct from SRAM via sunxi-fel.
soc_info.c: Correct V536 thunk_addr from 0x2A200 to 0x2E000. Upstream
value was copied from V831 without hardware verification. 0x2E000
confirmed working on real V536 silicon.
Closes #148