On Fri, Jun 10, 2022 at 11:59:23AM +0200, LABBE Corentin wrote:
Hello
I hit a boot regression on am335x-hs-evm. On current uboot, the board does not boot at all. This board uses both MLO and u-boot.img and only MLO was the problem.
After a bisect, I found that e41651fffda7 ("dm: Support parent devices with of-platdata") was the problem. Reverting this patch lead to a success boot.
I cutdown the revert to a minimal fix: --- a/drivers/core/lists.c +++ b/drivers/core/lists.c @@ -120,6 +120,7 @@ int lists_bind_drivers(struct udevice *parent, bool pre_reloc_only) int ret;
ret = bind_drivers_pass(parent, pre_reloc_only);
return ret; if (!ret) break; if (ret != -EAGAIN && !result)I cannot debug further since printf() is not working at this stage.
Since I wanted to know which error was badly handled, I tried to do this: --- a/arch/arm/mach-omap2/sec-common.c +++ b/arch/arm/mach-omap2/sec-common.c @@ -111,6 +111,8 @@ static u32 find_sig_start(char *image, size_t size) return 0; }
+extern int errorcount;
int secure_boot_verify_image(void **image, size_t *size) { int result = 1; @@ -178,6 +180,7 @@ auth_exit: * via YMODEM. This is done to avoid disturbing the YMODEM serial * protocol transactions. */
printf("ERRORCOUNT %d\n", errorcount); if (!(IS_ENABLED(CONFIG_SPL_BUILD) && IS_ENABLED(CONFIG_SPL_YMODEM_SUPPORT) && spl_boot_device() == BOOT_DEVICE_UART))--- a/drivers/core/lists.c +++ b/drivers/core/lists.c @@ -20,6 +20,10 @@ #include <fdtdec.h> #include <linux/compiler.h>
+static int _errorcount; +int errorlist[1024]; +int errorcount;
struct driver *lists_driver_lookup_name(const char *name) { struct driver *drv = @@ -120,8 +124,9 @@ int lists_bind_drivers(struct udevice *parent, bool pre_reloc_only) int ret;
ret = bind_drivers_pass(parent, pre_reloc_only);
if (!ret)break;
errorlist[_errorcount] = ret;_errorcount++;errorcount = _errorcount; if (ret != -EAGAIN && !result) result = ret; }But errorcount is always 0 which is puzzling me since according to my think, lists_bind_drivers() is ran before secure_boot_verify_image().
Any idea on how to debug further ?
You should be able to enable DEBUG_UART and get output that way. But it's likely something related to the space constraints of the HS chip rather than GP.