On Thu, Jan 18, 2024 at 12:30:42AM +0700, Francis Laniel wrote:
Le mercredi 17 janvier 2024, 17:05:28 +07 Patrice CHOTARD a écrit :
On 1/16/24 18:25, Francis Laniel wrote:
Le mardi 16 janvier 2024, 00:34:24 +07 Patrice CHOTARD a écrit :
On 1/11/24 18:04, Francesco Dolcini wrote:
On Fri, Dec 29, 2023 at 07:55:37PM +0100, Francis Laniel wrote:
Le jeudi 28 décembre 2023, 21:58:59 CET Tom Rini a écrit : > On Fri, 22 Dec 2023 22:02:20 +0100, Francis Laniel wrote: >> During 2021 summer, Sean Anderson wrote a contribution to add a new >> shell, >> based on LIL, to U-Boot [1, 2]. >> While one of the goals of this contribution was to address the fact >> actual >> U-Boot shell, which is based on Busybox hush, is old there was a >> discussion >> about adding a new shell versus updating the actual one [3, 4]. >> >> So, in this series, with Harald Seiler, we updated the actual U-Boot >> shell >> to reflect what is currently in Busybox source code. >> Basically, this contribution is about taking a snapshot of Busybox >> shell/hush.c file (as it exists in commit 37460f5da) and adapt it to >> suit >> U-Boot needs. >> >> [...] > > Applied to u-boot/next, thanks!
Thank you for the merge! If there is any problem, do not hesitate to mail me and I will take care of it!
This change, specifically setting the modern hush shell as default, is breaking our boot script, just noticed since the current U-Boot master has a regression for us.
We still need to figure out the exact details, here [1] you can find the boot script (that has some placeholder that is replaced during build).
and the error is something like:
## Executing script at 90280000 Loading DeviceTree: k3-am625-verdin-nonwifi-dev.dtb 69025 bytes read in 11 ms (6 MiB/s) 82 bytes read in 9 ms (8.8 KiB/s) Working FDT set to 90200000 syntax error at 'done'HUSH died! resetting ...that I _assume_ comes from this line
env set set_apply_overlays 'env set apply_overlays "for overlay_file in \\${fdt_overlays}; do echo Applying Overlay: \\${overlay_file} && ${load_cmd} \\${loadaddr} \\${overlays_prefix}\\${overlay_file} && fdt apply \\${loadaddr}; env set overlay_file; done; true"'>[1] https://git.toradex.com/cgit/meta-toradex-bsp-common.git/tree/recipes-bs p /u-boot/u-boot-distro-boot/boot.cmd.in
Francesco
Hi all
I observed a similar issue with STM32MP157c-DK2 board. Since commit 78912cfde281 ("cmd: Set modern hush as default shell") U-Boot crashes :
U-Boot 2024.01-00486-g697758e7c81-dirty (Jan 15 2024 - 18:23:52 +0100)
CPU: STM32MP157CAC Rev.B Model: STMicroelectronics STM32MP157C-DK2 Discovery Board Board: stm32mp1 in trusted mode (st,stm32mp157c-dk2) Board: MB1272 Var2.0 Rev.C-01 DRAM: 512 MiB Clocks:
- MPU : 650 MHz
- MCU : 208.878 MHz
- AXI : 266.500 MHz
- PER : 24 MHz
- DDR : 533 MHz
optee optee: OP-TEE: revision 4.0 (e92de4ca) I/TC: Reserved shared memory is disabled I/TC: Dynamic shared memory is enabled I/TC: Normal World virtualization support is disabled I/TC: Asynchronous notifications are disabled Core: 311 devices, 40 uclasses, devicetree: board WDT: Started watchdog@5a002000 with servicing every 1000ms (32s timeout) NAND: 0 MiB MMC: STM32 SD/MMC: 0 Loading Environment from MMC... OK In: No input devices available! Out: No output devices available! Err: No error devices available! Net: eth0: ethernet@5800a000 Hit any key to stop autoboot: 0 Boot over mmc0! switch to partitions #0, OK mmc0 is current device Scanning mmc 0:8... data abort pc : [<ddb3f77a>] lr : [<ddb44c95>] reloc pc : [<c012777a>] lr : [<c012cc95>] sp : dbafc848 ip : ddbfc578 fp : ddbedf18 r10: 00000000 r9 : dbb15e70 r8 : 00000000 r7 : dbb5bf98 r6 : dbb5de10 r5 : dbb5bf98 r4 : ddbeda78 r3 : dbb5dc08 r2 : 000033f8 r1 : 00000071 r0 : ddbede00 Flags: nzcv IRQs off FIQs off Mode SVC_32 (T) Code: 3138 1c48 f854 0030 (eb04) 05c1 Resetting CPU ...
I will take a look at the issue, trying to reproduce it and understand the root cause. I cannot give you any ETA for the fix, so for now I can only advise you to stick with the old parser.
Should we revert the change that set the modern hush shell as default till this is fixed?
This is preventing us to run our automated test suite against current master. Whatever other issue might be introduced we will not be able to report.
Tom?
Francesco