Hello, On 18.08.24 19:09, Ahmad Fatoum wrote: > Hello Stafford, > > On 18.08.24 09:14, Stafford Horne wrote: >> On Wed, Aug 14, 2024 at 06:14:35PM +0200, Ahmad Fatoum wrote: >>> The newest toolchain bump breaks OpenRISC start-up under QEMU: The console is >>> now completely silent. Steps to reproduce the hang: Turns out the toolchain update was not to blame, but the Debian container bump that accompanied it. It moved the default console as part of adding three more consoles to the platform. I am not sure that move was intended, so I submitted a QEMU patch for that[1]. For barebox, I think we'l just break compatibility with older QEMU, describe all 4 UARTs and use CONFIG_CONSOLE_ACTIVATE_ALL. [1]: https://lore.kernel.org/qemu-devel/20240822163838.3722764-1-a.fatoum@xxxxxxxxxxxxxx/ Should show it once lore has indexed the mail Cheers, Ahmad >>> >>> CONTAINER_GCC13=bdfdd5effcc169ebf8a9df2f1a5956ef34549682f78b450a97aceea2afd76f7a >>> CONTAINER_GCC14=fa35adeae1ab49b4dc09fc3bf4d68f92541a0d1f41e0df91a4879fd331e4b592 >>> CONTAINER_BASE=ghcr.io/barebox/barebox/barebox-ci@sha256:fa35adeae1a >>> >>> export CONTAINER=${CONTAINER_BASE}@sha256:${CONTAINER_GCC14} >>> export LG_BUILDDIR=build-openrisc >>> ./scripts/container.sh ./MAKEALL -a openrisc -O $LG_BUILDDIR >>> ./scripts/container.sh pytest --lg-env test/openrisc/generic_defconfig.yaml \ >>> --interactive >>> >>> Running the same steps, but with the older toolchain boots successfully: >>> >>> export CONTAINER=${CONTAINER_BASE}@sha256:${CONTAINER_GCC13} >>> export LG_BUILDDIR=build-openrisc >>> git checkout v2024.08.0 >>> ./scripts/container.sh ./MAKEALL -a openrisc -O $LG_BUILDDIR >>> ./scripts/container.sh pytest --lg-env test/openrisc/generic_defconfig.yaml \ >>> --interactive >>> >>> The hang happens somewhere before the jump to _start in arch/openrisc/cpu/start.S. >>> Until that's fixed, let's pin the OpenRISC GCC version to the old v13.1.0. >>> >>> Cc: Stafford Horne <shorne@xxxxxxxxx> >>> Signed-off-by: Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> >>> --- >>> @Stafford, do you have an idea what could cause this? >> >> Hi I am not sure about this, no new changes in the or1k-linux toolchain that I >> know about. I will try to reproduce and see what is going wrong. > > That would be great, thanks! I had a typo in the instructions above, > CONTAINER_BASE is not supposed to have @sha256:fa35adeae1a at the end. > > I tried to debug this by importing _emergency_putc from the kernel and > seeing where it's getting stuck. I tried on the working case (GCC13) and > calling _emergency_putc before _start doesn't work. Unfortunately, that's > where it hangs (or maybe, code isn't executed at all?) for GCC14 so that > didn't help me narrow down the issue. > > Cheers, > Ahmad > >> >> -Stafford >> > > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
