Open Fusseldieb opened 1 year ago
apritzel
commented
1 year ago Hi, this is simply because no one in possession of an A50 device (and there are not that many!) has ever bothered to send any patches. Since device support is purely community driven, without any interest and effort nothing will happen. So can you try to cook up a patch similar to this: https://github.com/linux-sunxi/sunxi-tools/commit/cbaf572b3d488? And do you actually have something to load (SPL)? Cheers, Andre
Fusseldieb
commented
1 year ago Hi, this is simply because no one in possession of an A50 device (and there are not that many!) has ever bothered to send any patches. Since device support is purely community driven, without any interest and effort nothing will happen. So can you try to cook up a patch similar to this: cbaf572b3d488? And do you actually have something to load (SPL)? Cheers, Andre
Thanks for your answer! Many cheap generic tablet use chipsets like these. It probably comes down to: It's so cheap that no-one bothers to look at them development-wise.
Anyways, I am in possession of 4 identical tablets. I do not have the original fw, neither can I find it on the internet. I asked their support and got a no. I unlocked and flashed another a50 fw on two of them and got a modified boot.img to boot with Magisk support and root it. Maybe this helps in acessing certain areas of the working tablets. Another one I bricked by selecting "multi partitions" in PhoenixSuit. I believe that using that check made it flash "sys_config" and messed up the display driver, since it's all white at boot, fading to black over time. Even all white, I can still feel the tablet booting, since eventually it responds to touches and power presses.
I sent the bricked one into warranty, got it back reflashed and bricked it again the exact same way. This time I forgot to unlock the OEM switch, which apparently did "something". Exact same issue: Boots, but I cannot see anything.
Regarding your question: I do not have a SPL to load. I tried to upload and execute several pointers using sunxi-fel, but most of the time the tablet would just lock up and I would need to reboot it. I remember using the official datasheet of the a50 a while back to try and get the right locations to load certain stuff, but even this made it lock up.
So can you try to cook up a patch similar to this: https://github.com/linux-sunxi/sunxi-tools/commit/cbaf572b3d488?
How do I do that, and what do I need to modify for it to work on the a50? I am dualbooting Ubuntu 20 and Windows 11, so I should have everything I need. Would the working rooted tablet help in detemining something?
Even just backing up the working sys_config and loading it onto the bricked one would already help immensely. I can imagine more people having that exact dilemma.
Any help is greatly appreciated!
apritzel
commented
1 year ago Hi Valentino, thanks for coming back on this. I heard of those A50 tablets, which might also explain the lack of community support, as tablets are harder to enable and also provide a less tempting development system, as graphics support is harder to set up in mainline Linux. Having Android root access is certainly helpful, mostly to dump system information like regulator and GPIO setup, to create a mainline devicetree. Otherwise the Allwinner BSP kernel and bootloaders are vastly different from the mainline code, so cannot be used directly for upstreaming. So the usual first step to enable a new SoC or system is to gather as much information about the system as possible. This involves:
Do you have a serial console? Even tables typically have serial pins or at least pads, thought it requires opening it up. This tremendously helps development, especially with the early boot process.
So there is certainly more to do, though we can definitely help you with that. Most peripherals in the A50 should be very similar, if not identical to ones already supported in mainline, so that's certainly helpful. And since we have the manual, we can fix up the rest. One big blocker is typically DRAM support, though we can work around this for the first time.
I will have a look at the A50 memory map, and can then probably suggest a sunxi-fel patch, though there is typically some experimentation involved, to learn about the BROM stack location and other details. If you could do some test runs, that'd be helpful, will come back to you.
Fusseldieb
commented
1 year ago Thank you for your time @apritzel. Let's do it.
However, remember, the working rooted tablet isn't running the original fw but still works somehow. I think sys_config (or a partition) wasn't overwritten. Maybe this can dumped together with /sys/* ? Anyways...
dumping the regulator setup. /sys/kernel/debug/regulator/regulator_summary (if provided) is a good source of information.
regulator use open bypass voltage current min max
-------------------------------------------------------------------------------
regulator-dummy 0 0 0 0mV 0mA 0mV 0mV
axp22x_dcdc1 9 12 0 3300mV 0mA 1600mV 3400mV
deviceless 0mV 0mV
deviceless 3300mV 3300mV
deviceless 3300mV 3300mV
deviceless 3300mV 3300mV
deviceless 3300mV 3300mV
deviceless 3300mV 3300mV
deviceless 3300mV 3300mV
deviceless 0mV 0mV
deviceless 0mV 0mV
deviceless 0mV 0mV
deviceless 0mV 0mV
deviceless 0mV 0mV
axp22x_dcdc2 1 1 0 960mV 0mA 600mV 1540mV
deviceless 0mV 0mV
axp22x_dcdc3 0 0 0 940mV 0mA 600mV 1860mV
axp22x_dcdc4 0 0 0 900mV 0mA 600mV 1540mV
axp22x_dcdc5 0 0 0 1500mV 0mA 1000mV 2550mV
axp22x_rtc 0 0 0 3000mV 0mA 3000mV 3000mV
axp22x_aldo1 0 0 0 1800mV 0mA 700mV 3300mV
axp22x_aldo2 0 0 0 2500mV 0mA 700mV 3300mV
axp22x_aldo3 0 0 0 3300mV 0mA 700mV 3300mV
axp22x_dldo1 1 1 0 1800mV 0mA 700mV 3300mV
deviceless 0mV 0mV
axp22x_dldo2 1 0 0 3300mV 0mA 700mV 3300mV
axp22x_dldo3 1 0 0 3300mV 0mA 700mV 3300mV
axp22x_dldo4 0 0 0 1800mV 0mA 700mV 3300mV
axp22x_eldo1 1 1 0 1800mV 0mA 700mV 3300mV
deviceless 0mV 0mV
axp22x_eldo2 0 0 0 2800mV 0mA 700mV 3300mV
axp22x_eldo3 0 0 0 1800mV 0mA 700mV 3300mV
axp22x_ldoio0 0 1 0 3300mV 0mA 700mV 3300mV
deviceless 3300mV 3300mV
axp22x_ldoio1 0 0 0 3300mV 0mA 700mV 3300mV
axp22x_dc1sw 0 0 0 3300mV 0mA 3300mV 3300mV
axp22x_dc5ldo 0 0 0 900mV 0mA 700mV 1400mV"# mount -t debugfs debugfs /sys/kernel/debug" if not already done.
Seems already mounted, as previous command worked.
ML-SO06-M7sLite:/ # ls /sys/kernel/debug
asoc dispdbg iommu pinctrl sync
autohotplug dma_buf ion pm_qos tracing
bdi extfrag mali pwm usb
binder f2fs memblock regmap wakeup_sources
bluetooth fault_around_bytes mmc0 regulator xradio_bt_dbg
ccudbg gpio mmc1 sleep_time xradio_host_dbg
clk hid mpp sunxi_pinctrl zsmalloc
cpufreq ieee80211 opp suspend_statsdumping GPIO information: /sys/kernel/debug/gpio, to learn about GPIOs assignments.
ML-SO06-M7sLite:/ # cat /sys/kernel/debug/gpio
gpiochip1: GPIOs 0-255, parent: platform/pio, pio:
gpio-131 ( |? ) in lo
gpio-132 ( |? ) in lo
gpio-133 ( |? ) out lo
gpio-166 ( |cd ) in hi
gpio-229 ( |SPK ) out lo
gpio-231 ( |otg_id ) in hi
gpio-233 ( |? ) out lo
gpio-235 ( |card-pwr-gpios ) out hi
gpiochip0: GPIOs 352-383, parent: platform/r_pio, r_pio:
gpio-354 ( |bt_rst ) out lo
gpio-355 ( |bt_hostwake ) in lo
gpio-356 ( |bt_wake ) out lo
gpio-357 ( |wlan_regon ) out hi
gpio-358 ( |wlan_hostwake ) in lo
gpio-359 ( |chip_en ) out hiAnother way is to use devmem2 or peekpoke to dump the GPIO registers directly, which also gives information about the pinmuxes, so which pins are used for which device.
If you need information about that, I will need some memory adresses to dump, as (your?) tool apparently needs some.
Do you have a serial console?
I opened it up and probed it with a multimeter and my FTDI 3.3V adapter on various test points across the board, but didn't find any active serial communication going on. If you still think there should be one, I can take a photo of the board for you to look around.
EDIT: Maybe it is possible to craft a boot.img that dumps the serial console over some gpio or even to the external SD?
EDIT2: peekpoke mentioned something on /proc/iomem, so I'm documenting this as well:
0300b000-0300b3ff : /soc@03000000/pinctrl@0300b000
030f0000-030f0fff : /iommu@030f0000
04020000-04020fff : /soc@03000000/sdmmc@04020000
04021000-04021fff : /soc@03000000/sdmmc@04021000
05000000-050003ff : uart
05000400-050007ff : uart
05002000-050023ff : /soc@03000000/twi@0x05002000
05002400-050027ff : /soc@03000000/twi@0x05002400
07000000-070003ff : /soc@03000000/rtc@07000000
07022000-070223ff : /soc@03000000/pinctrl@07022000
40000000-7fffffff : System RAM
40008000-40dfffff : Kernel code
40f00000-410c128b : Kernel dataIf you could do some test runs, that'd be helpful, will come back to you.
Again, thank you for your time! If there is anything additional to try, let me know! I'm open to run, try or diagnose additional stuff.
Fusseldieb
commented
1 year ago @apritzel I'll need to send the bricked tablet into warranty asap, therefore if you want me to have a "thinker" unit (that we can flash, reflash, document and eventually even bring back to life) I need to know it in the next 1-2 days, since the warranty will run out if I don't.
After I send it in, I will only have the working tablets where I wouldn't want to thinker with flashing anymore. :)
apritzel
commented
1 year ago Thanks for dumping the information, I will have a look in the next days (am busy with T113s enablement atm).
So normally we don't need to flash anything for Linux enablement, it's actually easier and safer to do everything via SD card or via FEL. Typically most Allwinner boards boot from SD card, though there are exceptions.
Can you boot a vendor image from an SD card? There is uart0-helloworld-sdboot.sunxi in this repo, that usually answers this question easily (by writing it with bs=1k seek=8 to an SD card), but without serial console that's of course hard to prove. You could add:
__asm__ volatile("bx %0\n" :: "r" (0x20));
before the endless loop towards the end of the .c file, to send it into FEL mode, then inspect SRAM A1 from sunxi-fel:
sunxi-fel readl 0x20004, to see if you find the eGON magic string in there (0x4e4f4765). That's of course provided that sunxi-fel works.
If SD card booting doesn't work easily, then that's an annoying setback for later usage, but shouldn't harm development, which is easier with FEL anyway. And IIUC you get the tablet into FEL mode already?
What would be good to retain is a tablet which boots some working vendor firmware, and which we can inspect, so is rooted. So that we can later learn about certain bits and settings that we didn't think of now. But we don't need to flash anything to this "information donor", so you could use it as a normal tablet.
If the "bricked" tablet is just bricked in the sense that it doesn't boot the vendor firmware anymore, but at least goes into FEL mode: that's a perfect development vehicle. We will replace the whole software stack in the process, so don't need any of those bits. As mentioned, it is just helpful to have another device which still boots the vendor firmware.
Regarding UART: typically there are even pins labelled RX and TX on most PCBs, so I'd say it's worth to have another look. It tremendously simplifies development. You can use the UART on the SD pins, but that requires a SD breakout board, and is somewhat fiddly to use if you need the SD card as well. If you can bring the tablet into FEL mode easily (a button?), then this could be a route to explore, since you then could dedicate the SD card slot to the UART.
Fusseldieb
commented
1 year ago Thanks for your answer, I really appreciate it.
I will have a look in the next days (am busy with T113s enablement atm).
Ahh gotcha! No problem.
Can you boot a vendor image from an SD card? There is uart0-helloworld-sdboot.sunxi in this repo
Yes, this seems to work! I'll try to mess with it tomorrow. Any pointers on how to compile the .c file into a workable .bin? Im not in front of the PC rn, so it's best to ask beforehand.
Regarding FEL mode, yes, all 4 tablets enter FEL mode, even the bricked one. Sunxi-fel works too, but it complains an unknown Chipset.
What would be good to retain is a tablet which boots some working vendor firmware, and which we can inspect, so is rooted.
Perfect. The other 3 are on a fully working vendor firmware and rooted. Only one is bricked. By bricked I mean: it turns the display on all white and starts to fade. A flash with all partitions enabled somehow messed up the display driver or pinout. That's why I'm afraid and want to send it in. I spent nearly 2 months on it and didn't get it to display anything anymore. It boots, but I cannot see anything. Eventually the boot sequence appears to complete, as I can lock the screen and hear a "click", while the screen turns off. And yep, it goes into FEL just fine, too.
Anyways...
Regarding UART: typically there are even pins labelled RX and TX on most PCBs, so I'd say it's worth to have another look.
I took a look again earlier today and probed almost the entire board with serial_noise running in a adb shell window, without luck. I asked multiple people at Alibaba for an A50 Pinout, as this isn't provided, but yet without luck.
If we could redirect the UART output to the SD card pins, I could solder cables there directly. This is no issue for me, also no adapter needed.
(A soldering job from earlier today at all the test pins to see if I could get UART. After that I probed everything with a probe)
Let me know what you think. Thanks again!
apritzel
commented
1 year ago To create the hello-world binary, just use: make uart0-helloworld-sdboot.sunxi.
That should do the right thing, if not, chase down what goes wrong in each of the steps and try to fix that.
I use this adapter for the PortF-UART:
https://www.sparkfun.com/products/9419
You need to provision the firmware to use that UART0 pinmux though, mainline U-Boot has support for this via CONFIG_UART0_PORT_F.
While working with an Allwinner A50 chipset I saw that there is basically nil support.
Even sunxi-fel doesn't recognize it. (0x1755)