ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
hentai has quit [Remote host closed the connection]
ftg has quit [Read error: Connection reset by peer]
apritzel_ has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
Danct12 has joined #linux-sunxi
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-sunxi
Danct12 has quit [Quit: WeeChat 3.8]
JohnDoe_71Rus has joined #linux-sunxi
apritzel_ has joined #linux-sunxi
rubberduck has quit [Quit: https://quassel-irc.org - Komfortabler Chat. Überall. ]
rubberduck has joined #linux-sunxi
apritzel_ has quit [Ping timeout: 480 seconds]
junari has joined #linux-sunxi
evgeny_boger1 has joined #linux-sunxi
evgeny_boger has quit [Ping timeout: 480 seconds]
evgeny_boger1 has quit [Remote host closed the connection]
evgeny_boger has joined #linux-sunxi
warpme_ has joined #linux-sunxi
warpme has joined #linux-sunxi
warpme has left #linux-sunxi [#linux-sunxi]
warpme has joined #linux-sunxi
<warpme> test
<Jookia> ing
<warpme> guys: i'm trying to get booting h313 board. Uboot I'm using is https://github.com/jernejsk/u-boot/commits/h616-dram-imp with dram params extracted from box emmc (https://pastebin.com/WuvHmD5q). My uboot defconfig is like this: https://github.com/warpme/minimyth2/blob/master/script/bootloaders/u-boot-h313/files/52-add-h313-x96-q-v1-defconfig.patch
<warpme> To test spl i'm using fel mode. Unfortunately "sunxi-fel spl u-boot-sunxi-with-spl.bin" gives me board hang.
junari_ has joined #linux-sunxi
<warpme> sunxi-fel tells me:
<warpme> Stack pointers: sp_irq=0x00021400, sp=0x00053FFC
<warpme> 2:48 PM
<warpme> 2:48 PM
<warpme> => Executing the SPL... done.
<warpme> MMU is not enabled by BROM
<warpme> 2:48 PM
<warpme> usb_bulk_send() ERROR -7: Operation timed out
<warpme> 2:49 PM
<warpme> what can be most probable explanation: dram init?
<warpme> what can be most probable explanation of board hang: failed dram init?
junari has quit [Ping timeout: 480 seconds]
<warpme> btw: as spl seems failing - i started to look for working dram init code and extracted boot0 from vendor android mmc. boot0 used as spl in sunxi-fel gives me: https://pastebin.com/Yzh5u6ra Here i'm stuck as i'm too weak in boot0 disassembly + required fixes in https://github.com/jernejsk/u-boot/blob/152d1a37b4856c23976cfd0758cab654b84336cd/arch/arm/mach-sunxi/dram_sun50i_h616.c to get proper dram init....
bauen1 has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
<apritzel> warpme: there are some known problems with the H616 DRAM init and FEL with some compilers. Are you using GCC 11 or higher, by any chance?
<warpme> yes. i'm using 12.2.0
<apritzel> warpme: can you please try a GCC 10? For instance from here: https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/10.4.0/
<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:
<warpme> [root@hp-probook-piotro-localdomain Desktop]# sunxi-fel -l
<warpme> USB device 003:003 Allwinner H616 33005c00:1c004808:0148880d:0c9b1f0f
<warpme> found DT name in SPL header: sun50i-h313-x96q-v1
<warpme> USB device 000:-1417473798 Allwinner
<warpme> [root@hp-probook-piotro-localdomain Desktop]# sunxi-fel -v uboot u-boot-sunxi-with-spl.bin
<warpme> Stack pointers: sp_irq=0x00021400, sp=0x00053FFC
<warpme> MMU is not enabled by BROM
<warpme> => Executing the SPL... done.
<warpme> usb_bulk_send() ERROR -7: Operation timed out
<warpme> nothing on uart
<warpme> i see "Executing the SPL... done"- so maybe we should go with enabled debug in dram_sun50i_h616.c?
<warpme> btw: uart thing is intruiging me here. inserting sd card with flashed uboot u-boot-sunxi-with-spl.bin gives total silence on uart. nothing.
<LordKalma> I bet you're exited about this stuff
<LordKalma> Wow, ddn0t read the backlog
<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?
<warpme> apritzel : oh no. small summary: 1} uart on android if fully chatty. 2) In fel it is also chatty (https://pastebin.com/ziJww7Fw); 3)mainline uboot: total nothing; 4)sdcard with vendor android boot0 (https://pastebin.com/jNeJBYw6)
<warpme> going with fel with mainline u-boot: nothing on uart
<warpme> i mean executing: "sunxi-fel -v uboot u-boot-sunxi-with-spl.bin"
<warpme> gives nothing on uart
<apritzel> so that means it could just be *not* UART0 that this device is using?
<warpme> well - decompiled android dts has this: bootargs = "earlyprintk=sunxi-uart,0x05000000 initcall_debug=0 console=ttyS0,115200 loglevel=4 root=/dev/mmcblk0p4 rootwait init=/init partitions=bootloader@mmcblk0p1:env@mmcblk0p2:boot@mmcblk0p3:super@mmcblk0p4:misc@mmcblk0p5:recovery@mmcblk0p6:cache@mmcblk0p7:vbmeta@mmcblk0p8:vbmeta_system@mmcblk0p9:vbmeta_vendor@mmcblk0p10:metadata@mmcblk0p11:private@mmcblk0p12:frp@mmcblk0p13:empty@mmcblk0p1
<warpme> 4:media_data@mmcblk0p15:Reserve0@mmcblk0p16:UDISK@mmcblk0p17 cma=64M snum=1c00148880d0c9b1f0f mac_addr=90:0E:B3:49:95:4C wifi_mac= bt_mac= selinux=0 specialstr= gpt=1 androidboot.mode=normal androidboot.serialno=1c00148880d0c9b1f0f androidboot.hardware=sun50iw9p1 boot_type=2 androidboot.boot_type=2 androidboot.secure_os_exist=0 gpt=1 uboot_message=2018.05(07/15/2022-13:48:08) disp_reserve=3686400,0x7bf27940 bootreason=unknow
<apritzel> warpme: does uart0-helloworld-sdboot.sunxi work?
<warpme> firmware_class.path=/vendor/etc/firmware selinux=1 androidboot.selinux=permissive androidboot.dtbo_idx=0,1,2 buildvariant=userdebug";
<apritzel> right, so that suggests UART0, but that's only for the kernel, not boot0. Do you see Android kernel messages on that UART?
<warpme> yes - i see android kernel: https://pastebin.com/ZF9P6tU9
<apritzel> (ignoring for a minute that earlyprintk does not work on arm64 ;-)
<warpme> apritzel : how i should test uart0-helloworld-sdboot.sunxi?
<apritzel> sunxi-fel -v spl uart0-helloworld-sdboot.sunxi
<warpme> should i dd this to sdcard?
<apritzel> you could, but FEL should work as well. This doesn't touch DRAM, just the UART, so less things that could go wrong
<warpme> apritzel : uart works. I'm geting "Hello from Allwinner H616!
<warpme> Returning back to FEL."
<apritzel> boy, reading a vendor kernel boot log is always depressing. Alone that it's a v4.9 kernel, compiled with GCC 5.3 ...
<warpme> indeed. clear pain in the eyes :-)
<apritzel> warpme: interesting. And you don't even see the SPL banner from mainline?
<apritzel> warpme: any chance this box has the secure fuse burnt?
<apritzel> I think on the H616 we cannot detect this in sunxi-fel, as it doesn't have the ARISC SRAM
<warpme> absolutely nothing. even no short led blink on usb->uart module at box power-on
<apritzel> in this case the switch to 64-bit at the very beginning of the SPL would already fail, which would explain why you don't see anything
<warpme> "any chance this box has the secure fuse burnt?"- how can i verify that?
<apritzel> warpme: can you compile the latest mainline version of sunxi-fel, and use the new sid-dump command?
<warpme> yes i'm using latest sunxi-fel git. let me try
<warpme> here it is: https://pastebin.com/9qjtnhe4
<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.......
<warpme> and flashing it to sd card gives: https://pastebin.com/jNeJBYw6
<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 commented all i2c entries except: CONFIG_SPL_I2C=y CONFIG_SPL_SYS_I2C_LEGACY=y (those 2 are needed to compile uboot at all). Also added some DEBUG(testX) in https://github.com/jernejsk/u-boot/blob/152d1a37b4856c23976cfd0758cab654b84336cd/arch/arm/mach-sunxi/board.c#L437 onward. Still silence on uart...
<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?
Moe_Icenowy has quit [Quit: ZNC 1.8.2 - https://znc.in]
<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> damn
<warpme> this gives:
<warpme> Returning back to FEL.
<warpme> U-Boot SPL 2023.01-rc3 (Mar 24 2023 - 18:38:09 +0100)
<warpme> 12
<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
<jernej> that's interesting
apritzel has quit [Ping timeout: 480 seconds]
apritzel_ has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit []
apritzel_ has joined #linux-sunxi
apritzel_ has quit [Ping timeout: 480 seconds]
tlwoerner has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-sunxi
Guest8635 has quit [Ping timeout: 480 seconds]
kilobyte1 has quit [Ping timeout: 480 seconds]
evgeny_boger has quit [Ping timeout: 480 seconds]
apritzel_ has joined #linux-sunxi
bauen1 has joined #linux-sunxi
kilobyte1 has joined #linux-sunxi
apritzel_ has left #linux-sunxi [#linux-sunxi]
apritzel has joined #linux-sunxi
<jakllsch> jernej: no, just checking
kilobyte1 has quit [Ping timeout: 480 seconds]
kilobyte1 has joined #linux-sunxi
kilobyte1 has quit [Ping timeout: 480 seconds]
kilobyte1 has joined #linux-sunxi