Re: Debugging efiboot

[Brook Milligan <brook%nmsu.edu@localhost>]

> On Jun 27, 2022, at 12:12 PM, Nick Hudson <nick.hudson%gmx.co.uk@localhost> wrote:
> 
> On 26/06/2022 01:17, Brook Milligan wrote:
>> 
>>> On Jun 25, 2022, at 11:12 AM, Brook Milligan <brook%nmsu.edu@localhost> wrote:
>>> 
>>> What is the best way to debug this?  I’m open to all suggestions.
>> 
>> I’ve been looking into this further.  Here is a reference on arm data exceptions:
>> 
>> 	https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.arm.com%2Fdocumentation%2Fka002692%2Flatest&amp;data=05%7C01%7Cbrook%40biology.nmsu.edu%7Ccfbf1befde79409fece508da5868aea2%7Ca3ec87a89fb84158ba8ff11bace1ebaa%7C1%7C0%7C637919503896291622%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=SGGw19fB9o5HeBO3Cd0dEkDR3RvuwgAK2NykVvQHKQs%3D&amp;reserved=0
>> 
>> Here is part of the output produced by efiboot:
>> 
>> 9137236+2443104+1407136 [455399+757776+576954]=0xe217f4
>> data abort
>> pc : [<9ff5797a>]   lr : [<9ff579b1>]
>> reloc pc : [<8080097a>]   lr : [<808009b1>]
>> sp : 9df35a4c  ip : 00000000 fp : 00000000
>> r10: 9ff57000  r9 : 9df36eb8 r8 : 00019040
>> r7 : 9ff57c00  r6 : 9ff57bb4 r5 : 000000ad  r4 : 0001ac00
>> r3 : 00000000  r2 : 00000050 r1 : 9ff57bb0  r0 : abb1aaad
>> Flags: NzCv  IRQs off  FIQs on  Mode SVC_32
>> Code: ea83428a d1f52010 f856bdf0 40685b04 (f854b2c5)
>> UEFI image [0x9cf03000:0x9cf2b79f] '/\efi\boot\bootarm.efi'
>> Resetting CPU …
>> 
>> If I interpret this correctly, lr is the link register and the illegal memory location is 8 bytes below that, i.e., 0x808009A9 (=2155874729).
> which u-boot are you using?
> 
> Something in u-boot (or less likely bootarm.efi) is dtwt and causing a
> data abort. It's difficult to tell from the information shown without
> understanding where u-boot is loaded, etc.

Here is another thread [1] that started my debugging effort.  Although that serial log was created on a BeagleBone Enhanced, the exact same happens on a BeagleBone Black. The u-boot version (which is default for this platform in pkgsrc) is listed in the log, although other versions have failed as well.

As stated in an earlier post in this thread [2], booting succeeds with the same version of u-boot when netbsd-GENERIC.ub is run directly (via fatload and bootm) and bootarm.efi is not used.

When I have tried to debug the booting via bootarm.efi, it seems to be getting at least all or most of the way to the point of calling ExitBootServices() before the data abort.  I’m not sure how I can track the process further, though, and I’m not sure where I can pick it up in the kernel again.  I also don’t know whether the arguments passed from u-boot to bootarm.efi are all ok; what is the calling convention?

More broadly, is the intent for our codebase to be using UEFI on as many arm platforms as possible or are board-specific combinations of fatload and bootm OK?  See [3] for a related inquiry.

I’m not sure what additional details would be helpful; please advise.  I am, however, happy to recompile and run new kernels, bootarm.efi, u-boot, or anything else to help figure this out.

I would also appreciate any direct reports of tests with any of the armbsd.org images, as they exhibit the same behavior for me as my compiled releases do.

Thanks for your help with this.

Cheers,
Brook

[1] http://mail-index.netbsd.org/port-arm/2022/06/19/msg007696.html
[2] http://mail-index.netbsd.org/port-arm/2022/06/26/msg007703.html
[3] http://mail-index.netbsd.org/port-arm/2022/06/27/msg007704.html