<jkm>
I remember that I has issues with GCC 12 too when running the kernel compiled for Allwinner H3...
<jkm>
Switching back to GCC 10.2.1 helped me
<warpme>
apritzel: fyi: i done fel test with another h616 box (tanix-tx6s). compiled (in the same build env) u-boot-sunxi-with-spl.bin then used in fel gives me nice boot...
<apritzel>
warpme: we already tried to pin this down. The hang appears only with certain DRAM parameter settings. So indeed one box worked, a different device didn't
<warpme>
by this i was trying to verify: do i use fel correctly and is my build env ok.
<warpme>
ah ok!
<warpme>
so should i compile just uboot with gcc 10 or anything else?
<apritzel>
there is some very obscure fix we found: adding a delay(0); into a certain part of the code
<apritzel>
just U-Boot
<apritzel>
I even tried to mix and match compilers before. At the end I was compiling just one .c file with GCC 10, the rest with GCC 12, and that worked
<apritzel>
and we also starred at the disassemblies, but couldn't spot an obvious problem or difference, just subtle instruction reorders and different register allocation
<apritzel>
the latest theories are: either there was always a missing delay in our DRAM code, and we got lucky so far because the compiler generated less optimal code, and introduced just enough delay to make it work
<apritzel>
or: the GCC 12 generated binary has a different memory footprint (stack usage, for instance), and clobbers some memory that FEL was using (since I think the problem is restricted to FEL booting)
bauen1 has joined #linux-sunxi
<warpme>
ok: i compiled with gcc10.4 and tried with sunxi-fel. issue is the same:
<LordKalma>
So everybody is having trouble with GCC10->12 and DRAM?
<warpme>
to verify is sd card ok for this h313 board i done experiment: flashed android boot0 to sdcard and this gives me: https://pastebin.com/jNeJBYw6 so it look hw is ok....
<LordKalma>
warpme, seems that several people have encountered the same problem independently. In the case I'm studying, we have *some* boards that boot with u-boot built with GCC-12 just fine and some that don't and require gcc-10.
<Jookia>
it's been 17 days and still no sunxi wiki email
<warpme>
LordKalma : indeed: i have h616 tx6s, Zero2 nicelly booting with my distro build on 12.2.0. this x96-q with h313 with nothing on uart is stopper for me :-(. (vendor android is channy on uart - so hw is ok i think)
<warpme>
channy->chatty
warpme_ has quit []
<apritzel>
warpme: so you don't see any UART output from mainline U-Boot, not via FEL and not via SD card?
<apritzel>
mmh, it's all zeroes in the later registers, including LCJS (probably at 0x48), so doesn't look like it
<warpme>
"so doesn't look like it"?
JohnDoe_71Rus has quit []
junari__ has joined #linux-sunxi
<apritzel>
there should be a "1" in one of those zero words if the chip has the secure fuse burnt. Also I think boot0 typically gives a hint if that's the case
junari_ has quit [Ping timeout: 480 seconds]
<apritzel>
so this experiment suggests it's a "non-secure" (read: normal) chip
<apritzel>
warpme: do you have a dump of the vendor's boot0 that's on the eMMC? Does the first line in a hexdump say "eGON" or "TOC0"?
<warpme>
yes i have. It has this: BE 04 00 EA │ 65 47 4F 4E │ 2E 42 54 30 │ E3 C9 6B 55 │ 00 00 01 00 │ 30 00 00 00 │ 00 00 00 00 ....eGON.BT0..kU....0.......
<apritzel>
alright, so that confirms it's a non-secure normal eGON image
<apritzel>
which is a bummer somewhat, because the secure fuse would be a good explanation for what you see ;-)
grming has joined #linux-sunxi
<warpme>
indeed. total silence on uart is very strange. Is there any way to turn-on verbosity on spl i.e. before dram init? (assuming hang is because dram init fails)
<warpme>
or mybe spl not serves properly sdcard? (too low voltage, etc)
<apritzel>
the BROM would load the SPL, that's no difference to boot0. So if boot0 executes, this cannot be the reason for the SPL not showing any signs of life
<apritzel>
any MMC or SD card problems in the U-Boot SPL code would only show later on, when U-Boot proper is loaded
<warpme>
i just checked with multimeter: there is 3v3 on sdcard in both cases (boot0 and spl)
<apritzel>
warpme: you can add "#define DEBUG" to the very top (before any #include lines) of arch/arm/mach-sunxi/board.c and board/sunxi/board.c
<warpme>
sure
<apritzel>
warpme: or try to use a very minimal _defconfig, maybe? Do you have the PMIC enabled in there?
<warpme>
i added "#define DEBUG" at very top (before any #include lines) of arch/arm/mach-sunxi/board.c and board/sunxi/board.c and tried "sunxi-fel -v uboot u-boot-sunxi-with-spl.bin". nothing on uart; fel returns "usb_bulk_send() ERROR -7: Operation timed out"
<warpme>
i can try reduce defconfig. what should i remove?
<apritzel>
warpme: everything with I2C in it, for a start
<warpme>
I don't know enough uboot internal arch: what is earliest possible (in exec sense) place in code where i can put DEBUG msg to see it on uart?
paulk-bis has joined #linux-sunxi
paulk has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has joined #linux-sunxi
<apritzel>
warpme: well, my gut feeling is that something goes wrong before it reaches C code.
<apritzel>
The pinmux is setup in arch/arm/mach-sunxi/board.c:gpio_init(), the UART is then initialised in the call to preloader_console_init()
<apritzel>
but that immediately prints the SPL banner, and since you don't see that, it doesn't really help you
<apritzel>
you can do the following: load uart0-helloworld-sdboot.sunxi via FEL (that should return), then load U-Boot directly afterwards
<apritzel>
uart0-helloworld initialises the UART already, so you can send characters by just writing the ASCII code to 0x50000000
<apritzel>
you can do that in assembly (mov x1, #0x50000000; mov w0, #'1'; str w0, [x1]) or in C (volatile uint32_t *uart = (void *)0x50000000; *uart = '2';)
<warpme>
i tried this: "sunxi-fel -v spl uart0-helloworld-sdboot.sunxi; sunxi-fel -v spl u-boot-sunxi-with-spl.bin". i see "Hello..." then nothing on uart and "usb_bulk_send() ERROR -7: Operation timed out"in fel
<apritzel>
well, yes, you need to add those debug beacons into the code, to see how far you come
<apritzel>
warpme: an good start would be to see if you reach board_init_f(), by adding that C snippet to the beginning of it
cnxsoft has quit []
<warpme>
so i added as first line in bard_init_f() "volatile uint32_t *uart = (void *)0x50000000; *uart = '2';". nothing after "Hello...." :-(
paulk-bis has quit []
paulk has joined #linux-sunxi
<jakllsch>
what's the status of modesetting on H6?
<warpme>
apritzel : there must be something not ok with using "volatile uint32_t *uart = (void *)0x50000000; *uart = '2';" in uboot code: i tested this on well booting h616 tx6s: adding this line gives "usb_bulk_send() ERROR -7: Operation timed out"
<apritzel>
ah yeah, sorry, it's one zero too much :-(
<warpme>
:-)
<apritzel>
it's supposed to be the base address of UART0, so 0x05000000
<warpme>
qll: now i see "2"on working tx6s :-p
<warpme>
and nothing in h313 :-(. I even add it to gpio_init(); return 0; nothing.
<apritzel>
well, I still suspect that something goes wrong well before that, potentially even in the very early switch to AArch64
tlwoerner has quit [Quit: Leaving]
<apritzel>
warpme: try to add the assembly version after the save_boot_params_ret: label in arch/arm/cpu/armv8/start.S
MoeIcenowy has joined #linux-sunxi
<warpme>
hmm - with asm i'm getting "Error: unexpected characters following instruction at operand 2 -- `mov x1, #0x05000000'"
junari__ has quit [Remote host closed the connection]
<warpme>
apritzel : ok I verified asm code in arch/arm/cpu/armv8/start.S on working h616 tx6s. Then i added this code to h313 start.S. noting on uart
<apritzel>
ah, there seems to be some UTF-8 space in the IRC post (after the comma): if I copy & paste the line from hexchat, I get the same error, if I type it, it's fine ;-)
ftg has joined #linux-sunxi
vagrantc has joined #linux-sunxi
paulk has quit [Ping timeout: 480 seconds]
paulk has joined #linux-sunxi
apritzel_ has joined #linux-sunxi
<apritzel>
warpme: can you add: ".needs_smc_workaround_if_zero_word_at_addr = 0xc000," to the H616 stanza in sunxi-tools soc_info.c, then recompile sunxi-fel? Just to rule out that it's not a secure board after all?
evgeny_boger has quit [Ping timeout: 480 seconds]
<warpme>
apritzel : done. with this i'm getting (for Hello test): Applying SMC workaround... done.
<warpme>
found DT name in SPL header:
<warpme>
usb_bulk_send() ERROR -7: Operation timed out
<apritzel>
right, thanks, so it's definitely not a secure board then
<warpme>
oh this seems to me like v. distant light in long tunnel .....
<apritzel>
oh, one more thing to try: can you swap the 0x09010040 with 0x08100040 in U-Boot's arch/arm/include/asm/arch-sunxi/boot0.h?
<warpme>
Error, wrong i2c adapter 0 max 0 possible
<warpme>
Error, wrong i2c adapter 0 max 0 possible
<warpme>
Returning to FEL sp=53a18, lr=53ad8
<warpme>
12 are my debug entries....
<warpme>
on man!
<warpme>
oh man!
<warpme>
i must go but ....FANTASTIC WORK!
<warpme>
FANTASTIC WORK
<apritzel>
warpme: many thanks for your persistence on this! Will post some patch soon, that's what's needed on the T507 as well
<apritzel>
for now we will go with a simple U-Boot config option, I guess, so just one extra line in the _defconfig file
<warpme>
where i should send you beer wagon?
evgeny_boger has joined #linux-sunxi
warpme has quit []
<apritzel>
warpme: can you add a device page to the Wiki instead? Then we can record this oddity there, and then can find out why this H313 is different from the others
stipa has joined #linux-sunxi
<jernej>
apritzel: that bug is only FEL related, or is it visible also when booting from SD card, for example?
<jernej>
anyway, great job!
<jernej>
jakllsch: modesetting on H6 should work fore some time now. Did you encounter any issue or is there any missing feature for you?
<apritzel>
jernej: that's the RVBAR shadow located at a different offset, as we have seen on the T507
<apritzel>
jernej: that affects TF-A, and the aarch64 switch in U-Boot
<apritzel>
so there seem to be either two slightly different dies, or it's some fused property
<apritzel>
it's not only the address, the whole CPU cluster control seems to be different, actually compatible to the R329