ftg^ has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 480 seconds]
<smaeul>
upnix: with vendor u-boot, you may have to press specifically the 's' key, even though the message says any key
vagrantc has quit [Quit: leaving]
buZz has quit [Remote host closed the connection]
JohnDoe_71Rus has joined #linux-sunxi
apritzel has joined #linux-sunxi
junari has joined #linux-sunxi
<junari>
Does anyone have boot0_sdcard.elf from H616 BSP?
junari has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
evgeny_boger has joined #linux-sunxi
Guest361 is now known as ynezz
apritzel has joined #linux-sunxi
junari has joined #linux-sunxi
junari has quit [Remote host closed the connection]
junari has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
evgeny_boger has quit [Quit: evgeny_boger]
apritzel has joined #linux-sunxi
evgeny_boger has joined #linux-sunxi
buZz has joined #linux-sunxi
paulk-bis has joined #linux-sunxi
paulk has quit [Read error: Connection reset by peer]
paulk-bis has quit []
paulk has joined #linux-sunxi
paulk has quit [Read error: Connection reset by peer]
paulk has joined #linux-sunxi
evgeny_boger has quit [Remote host closed the connection]
JohnDoe_71Rus has quit []
junari_ has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
junari_ has quit []
evgeny_boger has joined #linux-sunxi
Net147 has quit [Ping timeout: 480 seconds]
cnxsoft has quit []
grming has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
Net147 has joined #linux-sunxi
jelly has quit [Remote host closed the connection]
<upnix>
apritzel: This is amazing information, thank you so much! I'm working on it now and will let you know how it goes.
<LordKalma>
I know it's a vague question, but if I extract the uboot bootloader from an image, is there any special address that I load it at in ghidra to get the pointers right?
<LordKalma>
the strings look okay, but the pointers are all wrong
<apritzel>
LordKalma: the "canonical" U-Boot load address for Allwinner is 0x4a00.0000, at least for U-Boot proper
<LordKalma>
thanks :) will try that
<apritzel>
LordKalma: mainline links against that, and I think we copied that address from the BSP U-Boot
<LordKalma>
I read the datasheet of the LCD panel of hell says the panel needs to be reset once on boot
<LordKalma>
and now we're theorizing the u-boot is doing the initialization
<LordKalma>
since there is a splash screen, the panel is working on the uboot side
<LordKalma>
so the missing magic is probably coming from that
<apritzel>
upnix: what are you after, with this box? Running mainline kernels? Then please don't waste any time on the vendor firmware ...
<LordKalma>
upnix, I'm since 3 months trying to jailbreak from vendor :D :D :D
<LordKalma>
and apritzel is a saint
<LordKalma>
and tolerates me
<upnix>
I'm trying to turn them into wireless mesh access points. But struggled with the onboard wifi enough that I started trying to compile my own kernel modules. When I wasn't able to succeed in getting my own modules loaded by the Android kernel, I started to gently poke at the boot image to see if I could swap out the 4.9.170 kernel with my own 4.9.170 kernel. When I bricked the T95 is when I cracked open the case to get a serial
<upnix>
So now.. I'm in so deep I'm not sure what my real goal is. This was supposed to be a networking project for me, but I'm surprised how interesting I'm finding the hardware.
jelly has joined #linux-sunxi
<jernej>
junari: there are no elf files for H616 in BSP for SPL. Only standalone bin files. But you can extract that from vendor image or even device itself.
<jernej>
junari: what do you want to achieve?
<apritzel>
upnix: the WiFi in those boxes is one of the nasty ones, although I believe some people started with some code
<apritzel>
upnix: anyway I wonder if that chip is good anyway (typically there are not only undocumented, but also crap), or if you are not better off with some cheap USB-WiFi
<jernej>
which wifi is that?
<apritzel>
it's either AW859, some boxes seem to even ship with an XR819 ...
<jernej>
you mean UW something
<jernej>
I have code for both, but XR819 is actually much better. Only reason why I didn't send any patches is because it prevents sleep via Crust
<jernej>
I mean in much better shape.
<apritzel>
but the XR819 had quite bad performance, right? And was also unreliable (dropping connection), or was this a driver problem?
<jernej>
either FW or driver
<jernej>
well, even HW too
<jernej>
anyway, I didn't do extensive tests but I didn't notice any connection drops in an hour long connection
<jernej>
so that needs to be tested
<upnix>
apritzel: I know the wi-fi as the Broadcom bcm43342, the way I was interacting with it at least. You're talking about the Allwinner-assembled wireless package/chip, I think?
<apritzel>
yeah, those ones, there are pretty s**t, but popular, because cheap ;-)
mehdix has quit []
mehdix has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit []
apritzel has joined #linux-sunxi
<LordKalma>
apritzel, you'll be happy to know we made the LCD panel work
<LordKalma>
so we're inching closer
<LordKalma>
apparently my firmware build with the original uboot flashed over it makes it work
<LordKalma>
so there is some secret sauce in the uboot image that's initing the panel
<LordKalma>
U boot question: the disassemble at 0x4a000000 seems to be working fine
<LordKalma>
but there are a lot of references to memory at 0x000047e3-ish range
<LordKalma>
in red because Ghidra doesn't know this memory
<LordKalma>
what would be at this low addresses?
<apritzel>
the 32-bit parts have the SRAM A1 there, this is where the SPL lives, or boot0, when using a vendor image
<LordKalma>
okay, thanks. probably not important for my use, just wanted to know
<LordKalma>
also some DAT_01c20064
<LordKalma>
what would be at 0x1c20000 range?
<apritzel>
the clock controller (CCU)
<LordKalma>
thanks! :)
<LordKalma>
where are panel and similar drivers in the uboot source?
<apritzel>
everywhere
<apritzel>
panel drivers are a complete mess
<apritzel>
could it be simply a regulator enablement missing? Some GPIO, for instance?
<LordKalma>
I found two functions so far relevant
<LordKalma>
ds "jlt4013a-spi-clk", ds "jlt4013a-spi-cs", ds "jlt4013a-spi-mosi" are referenced by FUN_4a021be4 and ds "jlt4013a-dcx" is referenced by FUN_4a01cebc
<LordKalma>
But funnily, "Error cannot request jlt4013a spi-mosi,%s\n" is referenced by FUN_4a01cebc, not FUN_4a021be4
<LordKalma>
this code is heavily optimized, functions were clearly inlined
<apritzel>
that doesn't require "heavy" optimisation, it's super common and we actually rely on this for mainline U-Boot, otherwise the SPL would never fit into SRAM
<LordKalma>
yes, of course
<apritzel>
just keep looking, you will get there ;-)
<LordKalma>
I mean this because the same function seems to reference like ALL the error messages
<apritzel>
LordKalma: can you break into the vendor U-Boot?
<apritzel>
then you could try to dump all GPIOs
<LordKalma>
what you mean break in?
<LordKalma>
as in stop the boot and get the console?
<apritzel>
yes
<LordKalma>
maybe if i'm fast enough
<apritzel>
or even better: but into Linux, and check /sys/kernel/debug/
<apritzel>
s/but/boot/
<LordKalma>
that we can 100% do
<LordKalma>
we have root terminal access
<LordKalma>
it's root/123 :)
<apritzel>
cat /sys/kernel/debug/gpio
<apritzel>
though I am not sure if that reflect the actual pinctrl hardware state, or rather Linux' view of it
<LordKalma>
cat: can't open '/sys/kernel/debug/gpio': No such file or directory
<LordKalma>
but nice try
<apritzel>
mount -t debugfs debugfs /sys/kernel/debug