07:26 <rrq> need some advice re booting debian armhf kernel on my orangepi-3-lts;... ; it runs armv7, doing SPL, my own bl31, then u-boot then using sysboot for entering the kernel binary, but therafter all quiet; ... works fine to enter my own "pretend kernel" (checks FDT and whatnot), but real kernel is all quiet.

07:28 <rrq> does armhf kernel use FDT to determine serial/uart?

07:28 <arnd> rrq: the usual method for debugging this would be CONFIG_DEBUG_LL, which lets you hardcode uart settings for early console output

07:31 <arnd> The configured console from DT should get picked up a little later when you pass the 'earlycon' argument on the command line, but there are more things that can go wrong. Without 'earlycon' the normal 'console=ttyS0' or similar lets you pick a fully functional uart, but that happens much later than debug_ll or earlycon

07:31 <rrq> ok.. I have CONFIG_DEBUG_LL=y ... mmm but CONFIG_DEBUG_LL_INCLUDE="debug/8250.S" might be wrong as it's an 16550 (in u-boot)

07:32 <arnd> For CONFIG_DEBUG_LL, you need to pass 'earlyprintk' on the command line to actually activate it

07:32 <arnd> 8250 and 16550 is the same one (for the purpose of the early output

07:32 <arnd> just make sure you get the correct one

07:33 <rrq> I have: APPEND earlyprintk verbose loglevel=8 ro root=LABEL=armhf rootfstype=ext4 console=ttyS0,115200

07:34 <arnd> right, so ttyS0 is also what is configuered in /chosen/stdout-path for earlycon

07:36 <rrq> stdout-path says "serial0:115200" and the alias serial0=/soc/uart0 (I need to check)

07:37 <arnd> for earlyprintk you need to config CONFIG_DEBUG_UART_{VIRT,PHYS} correctly, presumably using the defaults for CONFIG_DEBUG_SUNXI_UART0

07:37 <arnd> rrq: I see that orangepi-3-lts uses a H6 chip, which is a armv8, not armv7, so I would not expect an armhf kernel to run at all

07:38 <rrq> PHYS=0x05000000 is right, I didn;t change VIRT=0xf1c28000

07:39 <rrq> hmm it does run armv7 my code and the armv7 compilaed u-boot

07:39 <rrq> it boots in aarch32 mode

07:40 <arnd> yes, it can do that in theory, but Linux doesn't really support 32-bit kernels on 64-bit CPUs

07:40 <rrq> the "standard" TF-A reboots it into aarch64 mode, but I don;t use that one

07:41 <arnd> VIRT=0xf1c28000 sounds wrong for PHYS=0x05000000, I'm fairly sure the low 20 address bits all need to match for the initial section map

07:41 <arnd> it may be easier to just turn off DEBUG_LL and see if earlycon gets the console up as it would on a 64-bit kernel

07:42 <rrq> it doesn't start the stock armhf

07:43 <arnd> do you mean the normal 64-bit kernel fails to boot with armhf userland? That case should normally be well supported, and independent of the SoC

07:44 <rrq> no.. a 64 bit boot (SPL+TF-A+u-boot) boots debian arm64 fine

07:45 <rrq> the 64 bit boot can run armhf code; but esp "meson" refuses to compile some armhf code because it requires the kernel to say it is an armhf kernel

07:46 <arnd> are you using 'setarch' to change the uname output?

07:46 <rrq> no... where/how would that be (sounds easier :)

07:48 <arnd> you can run individual commands or a shell like 'linux32 /bin/bash' to be in an environment that looks close to a native 32-bit system. I think systemd has a setting to do the same by default, but I don't remember how that is configured

07:50 <rrq> thanks! ... I'll explore that ... (leave armhf on hold)

07:51 <arnd> I think what most people do for building 32-bit packages is to boot a normal 64-bit userland but have a 32-bit chroot environment. E.g. using schroot you set up the linux32 personality in /etc/schroot

07:52 <rrq> yes that's what we tried. but something failed ... I need to go back to the problem cause and investigate using setarch

07:52 <rrq> (afair it was at compiling util-linux)

07:53 <rrq> thanks again. you opened a new door for me :)

07:55 <arnd> There are some packages that rely on the kernel to emulate a couple of instructions that are no longer part of armv8, so you may also need to enable /proc/sys/abi/{swp,cp15_barrier,setend}

07:56 <arnd> those are mostly workarounds for application bugs, as normal userland should use those intructions even on armv7, but it's always possible that something still uses htem

08:02 <rrq> great; thanks; I'll shift back to the arm64 setup and try this ..

08:04 <rrq> hmmm this might even make an opening for emulated armhf build on an amd64

11:12 <rrq> arnd: re H6 chip (on orangepi-3-lts); is that a show stopper in the kernel? I know it runs armv7 code.. down to and including my "fake kernel" binary but does it mean that the actual kernel has some logic making it refuse?

11:29 <rrq> btw. after correcting VIRT I now get 2.5 initial lines .. the last .5 is: CPU: ARMv7 Processor [410fd034] r.c0[ [ 00[

11:30 <rrq> I think 410fd034 is the h/w machine id while r1 is given as 0

11:32 <rrq> (I'll patch u-boot to offer r1=0x410fd034)

11:39 <rrq> (nope.. not that easy)

12:18 <rrq> I guess the cpu type need its proc.info.init entry (and more?)

13:48 <arnd> rrq: there is no reason it can'tt work, but I really don't want to merge more 64-bit platforms in arch/arm/, as even the ones we do support in theory (mainly raspberry pi 3 and 4) tend to cause more problems than it's worth:

13:49 <arnd> - 32-bit with more than 1GB RAM is really tight, and highmem is an ugly hack that we want to remove

13:49 <arnd> - errata workarounds for 64-bit CPUs are incomplete, even for cortex-a53

13:50 <arnd> - many security features are not implemented, or impossible, in 32-bit mode

13:51 <arnd> - even debian doesn't ship a 32-bit kernel any more, the only way to install armhf Debian Trixie is to use the 64-bit kernel package or a custom 32-bit build