Re: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109

[Oleksandr Tymoshenko]

Toomas Soome (tso...@me.com) wrote:
> 
> >> 
> >> From reading U-Boot sources (lib/efi_loader/efi_disk.c) it looks like
> >> names are in the form of typeN:M, where type is interface type,
> >> N is disk id and M is partition id. So 3 disks in my setup
> >> may be mmc0, mmc0:1, mmc0:2. 
> >> 
> >> -- 
> >> gonzo
> > 
> > Okay, so in case of arm or MEDIA_FILEPATH_DP we need to keep the initial 
> > disk handle till there is an disk switch, and use it as first argument for 
> > registering the disk. So the name in last node is probably the same format 
> > and we can identify the disk this way. Worth to check in any case:)
> > 
> 
> 
> Based on current knowledge, I did put together the first sketch of the fix:
> 
> https://reviews.freebsd.org/D9520
> 
> However, it needs to be tested on arm, so I do ask help there:)

Thanks Toomas, rpi3 boots with this patch applied and device
structure is correct:

OK  lsdev
disk devices:
disk0:15564801 X 512 blocks (removable)
  disk0s1: DOS/Windows
  disk0s2: FreeBSD
disk0s2a: FreeBSD UFS
net devices:
net0:

-- 
gonzo
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109

[Toomas Soome]

>> 
>> From reading U-Boot sources (lib/efi_loader/efi_disk.c) it looks like
>> names are in the form of typeN:M, where type is interface type,
>> N is disk id and M is partition id. So 3 disks in my setup
>> may be mmc0, mmc0:1, mmc0:2. 
>> 
>> -- 
>> gonzo
> 
> Okay, so in case of arm or MEDIA_FILEPATH_DP we need to keep the initial disk 
> handle till there is an disk switch, and use it as first argument for 
> registering the disk. So the name in last node is probably the same format 
> and we can identify the disk this way. Worth to check in any case:)
> 


Based on current knowledge, I did put together the first sketch of the fix:

https://reviews.freebsd.org/D9520

However, it needs to be tested on arm, so I do ask help there:)

rgds,
toomas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109

[Oleksandr Tymoshenko]

Toomas Soome (tso...@me.com) wrote:
> 
> > On 9. veebr 2017, at 17:05, Karl Denninger  wrote:
> > 
> > 
> > On 2/9/2017 08:58, Toomas Soome wrote:
> >>> On 9. veebr 2017, at 16:36, Karl Denninger  
> >>>  wrote:
> >>> 
> >>> 
> >>> On 2/8/2017 16:18, Karl Denninger wrote:
>  r313441 blows up on the Pi3 in /boot/loader.efi with:
>  
>  FreeBSD/arm64 EFI loader, Revision 1.1
>  (Tue Feb  7 15:15:52 CST 2017 free...@newfs.denninger.net 
>  )
>  Failed to start image provided by UFS (14)
>  "Synchronous Abort" handler, esr 0x9604
>  ELR: 3af62cec
>  LR:  3af61d60
>  x0 : 0001 x1 : 0001
>  x2 : 3afeb000 x3 : 003f
>  x4 : 0020 x5 : 0010
>  x6 :  x7 : 39b260a4
>  x8 : 3af61d48 x9 : 000d
>  x10: 0030 x11: 
>  x12:  x13: 0002
>  x14:  x15: 
>  x16:  x17: 
>  x18: 3ab30df8 x19: 37a16008
>  x20:  x21: 
>  x22: 39b28000 x23: 39b1d49c
>  x24: 39b28850 x25: 3ab3d740
>  x26: 3af839a0 x27: 39b2e3e8
>  x28:  x29: 3ab2ef60
>  
>  Resetting CPU ...
>  
>  If you copy in a loader.efi from an earlier build (e.g. r313109) then 
>  the system boots but complains about SMP problems, fails to start any of 
>  the other CPUs (although it sees them) and panics before it reaches a 
>  login prompt with what appears to be a problem reading the SD card (I 
>  also get a couple of lor's in here too. not sure if those are "real" 
>  or false positives)
>  
>  B
> >>> This has been isolated to r31 in sys/boot/efi; reverting the EFI
> >>> loader to a previous revision stops the crash.
> >>> 
> >>> Filed here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940 
> >>>  
> >>>  
> >>> 
> >>> 
> >> Does it still crash with r313442? I think it does and this is why:
> >> 
> >> From your log above, the hint is "Failed to start image provided by UFS 
> >> (14)”, so what we can guess here is that for some reason the loader.efi 
> >> main() failed to detect the boot device, and did return back to boot1.
> >> 
> >> Boot1 did print out this error message and did call panic(). So, the 
> >> question is, why it is failing to detect the root fs handle. I’ll try to 
> >> check if I can replicate the issue with x86 + ufs.
> >> 
> >> BTW: sorry for trouble:)
> >> 
> >> rgds,
> >> toomas
> >> 
> > Yes.
> > 
> > It's isolated to that particular revision, which appears to have reworked 
> > the enumeration of the available devices to boot from.  Reverting only 
> > sys/boot/efi to anything before 31 (e.g. "svn update -r 313332 ." in 
> > src/sys/boot/efi) and rebuilding results in a loader.efi that successfully 
> > loads and starts the kernel.
> > 
> 
> Well, the x86 version does not appear to have problems with finding the ufs 
> devices. So this has to be some sort of corner case related to arm:( 
> unfortunately I do not have much variants to test arm, except qemu… so some 
> help would be needed there. Since the only crash is from boot1 call to panic, 
> I am pretty sure the disk detection and setup was ok, so we should get disk 
> list if we insert something like:
> 
> for (i = 0; devsw[i] != NULL; i++) {
> if (devsw[i]->dv_print != NULL){
> if (devsw[i]->dv_print(verbose))
> break;
> }
> }
> 
> after dv_init() loop.
> 
> If thats true, then it should not take too much to find why we fail to get 
> the handle for root fs in case of arm… 


On RPi3 U-Boot EFI API provided by U-Boot and it's somewhat non-standard
comapring to x86 EFI or specialized EFI firmwares of ARM64. I did some
debugging and found that U-Boot reports driver with subtype MEDIA_FILEPATH_DP
so it's not recognized by disk handler. Quick hack below fixed boot
but it's not ideal and the device structure looks like this:

disk devices:
disk0:15564801 X 512 blocks (removable)
  disk0s1: DOS/Windows 49MB
  disk0s2: FreeBSD 1856MB
disk0s2a: FreeBSD UFS  1856MB
disk1:102375 X 512 blocks (removable)
disk2:3802112 X 512 blocks (removable)
  disk2a: FreeBSD UFS  1856MB
net devices:
net0:


disk1 and disk2 are actuallypartitions from disk0.
I can work on proper fix but not sure what should be
considered proper in this case. So some guidelines are welcome

Patch:
Index: 

Re: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109

[Toomas Soome]

> On 10. veebr 2017, at 0:10, Oleksandr Tymoshenko  wrote:
> 
> Toomas Soome (tso...@me.com) wrote:
>> 
>>> On 9. veebr 2017, at 23:39, Oleksandr Tymoshenko  wrote:
>>> 
>>> Toomas Soome (tso...@me.com) wrote:
 
> On 9. veebr 2017, at 17:05, Karl Denninger  wrote:
> 
> 
> On 2/9/2017 08:58, Toomas Soome wrote:
>>> On 9. veebr 2017, at 16:36, Karl Denninger  
>>>  wrote:
>>> 
>>> 
>>> On 2/8/2017 16:18, Karl Denninger wrote:
 r313441 blows up on the Pi3 in /boot/loader.efi with:
 
 FreeBSD/arm64 EFI loader, Revision 1.1
 (Tue Feb  7 15:15:52 CST 2017 free...@newfs.denninger.net 
 )
 Failed to start image provided by UFS (14)
 "Synchronous Abort" handler, esr 0x9604
 ELR: 3af62cec
 LR:  3af61d60
 x0 : 0001 x1 : 0001
 x2 : 3afeb000 x3 : 003f
 x4 : 0020 x5 : 0010
 x6 :  x7 : 39b260a4
 x8 : 3af61d48 x9 : 000d
 x10: 0030 x11: 
 x12:  x13: 0002
 x14:  x15: 
 x16:  x17: 
 x18: 3ab30df8 x19: 37a16008
 x20:  x21: 
 x22: 39b28000 x23: 39b1d49c
 x24: 39b28850 x25: 3ab3d740
 x26: 3af839a0 x27: 39b2e3e8
 x28:  x29: 3ab2ef60
 
 Resetting CPU ...
 
 If you copy in a loader.efi from an earlier build (e.g. r313109) then 
 the system boots but complains about SMP problems, fails to start any 
 of the other CPUs (although it sees them) and panics before it reaches 
 a login prompt with what appears to be a problem reading the SD card 
 (I also get a couple of lor's in here too. not sure if those are 
 "real" or false positives)
 
 B
>>> This has been isolated to r31 in sys/boot/efi; reverting the EFI
>>> loader to a previous revision stops the crash.
>>> 
>>> Filed here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940 
>>>  
>>>  
>>> 
>>> 
>> Does it still crash with r313442? I think it does and this is why:
>> 
>> From your log above, the hint is "Failed to start image provided by UFS 
>> (14)”, so what we can guess here is that for some reason the loader.efi 
>> main() failed to detect the boot device, and did return back to boot1.
>> 
>> Boot1 did print out this error message and did call panic(). So, the 
>> question is, why it is failing to detect the root fs handle. I’ll try to 
>> check if I can replicate the issue with x86 + ufs.
>> 
>> BTW: sorry for trouble:)
>> 
>> rgds,
>> toomas
>> 
> Yes.
> 
> It's isolated to that particular revision, which appears to have reworked 
> the enumeration of the available devices to boot from.  Reverting only 
> sys/boot/efi to anything before 31 (e.g. "svn update -r 313332 ." in 
> src/sys/boot/efi) and rebuilding results in a loader.efi that 
> successfully loads and starts the kernel.
> 
 
 Well, the x86 version does not appear to have problems with finding the 
 ufs devices. So this has to be some sort of corner case related to arm:( 
 unfortunately I do not have much variants to test arm, except qemu… so 
 some help would be needed there. Since the only crash is from boot1 call 
 to panic, I am pretty sure the disk detection and setup was ok, so we 
 should get disk list if we insert something like:
 
 for (i = 0; devsw[i] != NULL; i++) {
   if (devsw[i]->dv_print != NULL){
   if (devsw[i]->dv_print(verbose))
   break;
   }
 }
 
 after dv_init() loop.
 
 If thats true, then it should not take too much to find why we fail to get 
 the handle for root fs in case of arm… 
>>> 
>>> 
>>> On RPi3 U-Boot EFI API provided by U-Boot and it's somewhat non-standard
>>> comapring to x86 EFI or specialized EFI firmwares of ARM64. I did some
>>> debugging and found that U-Boot reports driver with subtype 
>>> MEDIA_FILEPATH_DP
>>> so it's not recognized by disk handler. Quick hack below fixed boot
>>> but it's not ideal and the device structure looks like this:
>>> 
>>> disk devices:
>>>   disk0:15564801 X 512 blocks (removable)
>>> disk0s1: DOS/Windows   

Re: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109

[Oleksandr Tymoshenko]

Toomas Soome (tso...@me.com) wrote:
> 
> > On 9. veebr 2017, at 23:39, Oleksandr Tymoshenko  wrote:
> > 
> > Toomas Soome (tso...@me.com) wrote:
> >> 
> >>> On 9. veebr 2017, at 17:05, Karl Denninger  wrote:
> >>> 
> >>> 
> >>> On 2/9/2017 08:58, Toomas Soome wrote:
> > On 9. veebr 2017, at 16:36, Karl Denninger  
> >  wrote:
> > 
> > 
> > On 2/8/2017 16:18, Karl Denninger wrote:
> >> r313441 blows up on the Pi3 in /boot/loader.efi with:
> >> 
> >> FreeBSD/arm64 EFI loader, Revision 1.1
> >> (Tue Feb  7 15:15:52 CST 2017 free...@newfs.denninger.net 
> >> )
> >> Failed to start image provided by UFS (14)
> >> "Synchronous Abort" handler, esr 0x9604
> >> ELR: 3af62cec
> >> LR:  3af61d60
> >> x0 : 0001 x1 : 0001
> >> x2 : 3afeb000 x3 : 003f
> >> x4 : 0020 x5 : 0010
> >> x6 :  x7 : 39b260a4
> >> x8 : 3af61d48 x9 : 000d
> >> x10: 0030 x11: 
> >> x12:  x13: 0002
> >> x14:  x15: 
> >> x16:  x17: 
> >> x18: 3ab30df8 x19: 37a16008
> >> x20:  x21: 
> >> x22: 39b28000 x23: 39b1d49c
> >> x24: 39b28850 x25: 3ab3d740
> >> x26: 3af839a0 x27: 39b2e3e8
> >> x28:  x29: 3ab2ef60
> >> 
> >> Resetting CPU ...
> >> 
> >> If you copy in a loader.efi from an earlier build (e.g. r313109) then 
> >> the system boots but complains about SMP problems, fails to start any 
> >> of the other CPUs (although it sees them) and panics before it reaches 
> >> a login prompt with what appears to be a problem reading the SD card 
> >> (I also get a couple of lor's in here too. not sure if those are 
> >> "real" or false positives)
> >> 
> >> B
> > This has been isolated to r31 in sys/boot/efi; reverting the EFI
> > loader to a previous revision stops the crash.
> > 
> > Filed here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940 
> >  
> >  
> > 
> > 
>  Does it still crash with r313442? I think it does and this is why:
>  
>  From your log above, the hint is "Failed to start image provided by UFS 
>  (14)”, so what we can guess here is that for some reason the loader.efi 
>  main() failed to detect the boot device, and did return back to boot1.
>  
>  Boot1 did print out this error message and did call panic(). So, the 
>  question is, why it is failing to detect the root fs handle. I’ll try to 
>  check if I can replicate the issue with x86 + ufs.
>  
>  BTW: sorry for trouble:)
>  
>  rgds,
>  toomas
>  
> >>> Yes.
> >>> 
> >>> It's isolated to that particular revision, which appears to have reworked 
> >>> the enumeration of the available devices to boot from.  Reverting only 
> >>> sys/boot/efi to anything before 31 (e.g. "svn update -r 313332 ." in 
> >>> src/sys/boot/efi) and rebuilding results in a loader.efi that 
> >>> successfully loads and starts the kernel.
> >>> 
> >> 
> >> Well, the x86 version does not appear to have problems with finding the 
> >> ufs devices. So this has to be some sort of corner case related to arm:( 
> >> unfortunately I do not have much variants to test arm, except qemu… so 
> >> some help would be needed there. Since the only crash is from boot1 call 
> >> to panic, I am pretty sure the disk detection and setup was ok, so we 
> >> should get disk list if we insert something like:
> >> 
> >> for (i = 0; devsw[i] != NULL; i++) {
> >>if (devsw[i]->dv_print != NULL){
> >>if (devsw[i]->dv_print(verbose))
> >>break;
> >>}
> >> }
> >> 
> >> after dv_init() loop.
> >> 
> >> If thats true, then it should not take too much to find why we fail to get 
> >> the handle for root fs in case of arm… 
> > 
> > 
> > On RPi3 U-Boot EFI API provided by U-Boot and it's somewhat non-standard
> > comapring to x86 EFI or specialized EFI firmwares of ARM64. I did some
> > debugging and found that U-Boot reports driver with subtype 
> > MEDIA_FILEPATH_DP
> > so it's not recognized by disk handler. Quick hack below fixed boot
> > but it's not ideal and the device structure looks like this:
> > 
> > disk devices:
> >disk0:15564801 X 512 blocks (removable)
> >  disk0s1: DOS/Windows 49MB
> >  disk0s2: FreeBSD 1856MB
> >disk0s2a: 

Re: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109

[Toomas Soome]

> On 9. veebr 2017, at 23:39, Oleksandr Tymoshenko  wrote:
> 
> Toomas Soome (tso...@me.com) wrote:
>> 
>>> On 9. veebr 2017, at 17:05, Karl Denninger  wrote:
>>> 
>>> 
>>> On 2/9/2017 08:58, Toomas Soome wrote:
> On 9. veebr 2017, at 16:36, Karl Denninger  
>  wrote:
> 
> 
> On 2/8/2017 16:18, Karl Denninger wrote:
>> r313441 blows up on the Pi3 in /boot/loader.efi with:
>> 
>> FreeBSD/arm64 EFI loader, Revision 1.1
>> (Tue Feb  7 15:15:52 CST 2017 free...@newfs.denninger.net 
>> )
>> Failed to start image provided by UFS (14)
>> "Synchronous Abort" handler, esr 0x9604
>> ELR: 3af62cec
>> LR:  3af61d60
>> x0 : 0001 x1 : 0001
>> x2 : 3afeb000 x3 : 003f
>> x4 : 0020 x5 : 0010
>> x6 :  x7 : 39b260a4
>> x8 : 3af61d48 x9 : 000d
>> x10: 0030 x11: 
>> x12:  x13: 0002
>> x14:  x15: 
>> x16:  x17: 
>> x18: 3ab30df8 x19: 37a16008
>> x20:  x21: 
>> x22: 39b28000 x23: 39b1d49c
>> x24: 39b28850 x25: 3ab3d740
>> x26: 3af839a0 x27: 39b2e3e8
>> x28:  x29: 3ab2ef60
>> 
>> Resetting CPU ...
>> 
>> If you copy in a loader.efi from an earlier build (e.g. r313109) then 
>> the system boots but complains about SMP problems, fails to start any of 
>> the other CPUs (although it sees them) and panics before it reaches a 
>> login prompt with what appears to be a problem reading the SD card (I 
>> also get a couple of lor's in here too. not sure if those are "real" 
>> or false positives)
>> 
>> B
> This has been isolated to r31 in sys/boot/efi; reverting the EFI
> loader to a previous revision stops the crash.
> 
> Filed here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940 
>  
>  
> 
> 
 Does it still crash with r313442? I think it does and this is why:
 
 From your log above, the hint is "Failed to start image provided by UFS 
 (14)”, so what we can guess here is that for some reason the loader.efi 
 main() failed to detect the boot device, and did return back to boot1.
 
 Boot1 did print out this error message and did call panic(). So, the 
 question is, why it is failing to detect the root fs handle. I’ll try to 
 check if I can replicate the issue with x86 + ufs.
 
 BTW: sorry for trouble:)
 
 rgds,
 toomas
 
>>> Yes.
>>> 
>>> It's isolated to that particular revision, which appears to have reworked 
>>> the enumeration of the available devices to boot from.  Reverting only 
>>> sys/boot/efi to anything before 31 (e.g. "svn update -r 313332 ." in 
>>> src/sys/boot/efi) and rebuilding results in a loader.efi that successfully 
>>> loads and starts the kernel.
>>> 
>> 
>> Well, the x86 version does not appear to have problems with finding the ufs 
>> devices. So this has to be some sort of corner case related to arm:( 
>> unfortunately I do not have much variants to test arm, except qemu… so some 
>> help would be needed there. Since the only crash is from boot1 call to 
>> panic, I am pretty sure the disk detection and setup was ok, so we should 
>> get disk list if we insert something like:
>> 
>> for (i = 0; devsw[i] != NULL; i++) {
>>if (devsw[i]->dv_print != NULL){
>>if (devsw[i]->dv_print(verbose))
>>break;
>>}
>> }
>> 
>> after dv_init() loop.
>> 
>> If thats true, then it should not take too much to find why we fail to get 
>> the handle for root fs in case of arm… 
> 
> 
> On RPi3 U-Boot EFI API provided by U-Boot and it's somewhat non-standard
> comapring to x86 EFI or specialized EFI firmwares of ARM64. I did some
> debugging and found that U-Boot reports driver with subtype MEDIA_FILEPATH_DP
> so it's not recognized by disk handler. Quick hack below fixed boot
> but it's not ideal and the device structure looks like this:
> 
> disk devices:
>disk0:15564801 X 512 blocks (removable)
>  disk0s1: DOS/Windows 49MB
>  disk0s2: FreeBSD 1856MB
>disk0s2a: FreeBSD UFS  1856MB
>disk1:102375 X 512 blocks (removable)
>disk2:3802112 X 512 blocks (removable)
>  disk2a: FreeBSD UFS  1856MB
> net devices:
>net0:
> 
> 
> disk1 and disk2 are actuallypartitions from disk0.
> I can work on 

Re: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109

[Karl Denninger]

On 2/9/2017 15:39, Oleksandr Tymoshenko wrote:
> Toomas Soome (tso...@me.com) wrote:
>>> On 9. veebr 2017, at 17:05, Karl Denninger  wrote:
>>>
>>>
>>> On 2/9/2017 08:58, Toomas Soome wrote:
> On 9. veebr 2017, at 16:36, Karl Denninger  
>  wrote:
>
>
> On 2/8/2017 16:18, Karl Denninger wrote:
>> r313441 blows up on the Pi3 in /boot/loader.efi with:
>>
>> FreeBSD/arm64 EFI loader, Revision 1.1
>> (Tue Feb  7 15:15:52 CST 2017 free...@newfs.denninger.net 
>> )
>> Failed to start image provided by UFS (14)
>> "Synchronous Abort" handler, esr 0x9604
>> ELR: 3af62cec
>> LR:  3af61d60
>> x0 : 0001 x1 : 0001
>> x2 : 3afeb000 x3 : 003f
>> x4 : 0020 x5 : 0010
>> x6 :  x7 : 39b260a4
>> x8 : 3af61d48 x9 : 000d
>> x10: 0030 x11: 
>> x12:  x13: 0002
>> x14:  x15: 
>> x16:  x17: 
>> x18: 3ab30df8 x19: 37a16008
>> x20:  x21: 
>> x22: 39b28000 x23: 39b1d49c
>> x24: 39b28850 x25: 3ab3d740
>> x26: 3af839a0 x27: 39b2e3e8
>> x28:  x29: 3ab2ef60
>>
>> Resetting CPU ...
>>
>> If you copy in a loader.efi from an earlier build (e.g. r313109) then 
>> the system boots but complains about SMP problems, fails to start any of 
>> the other CPUs (although it sees them) and panics before it reaches a 
>> login prompt with what appears to be a problem reading the SD card (I 
>> also get a couple of lor's in here too. not sure if those are "real" 
>> or false positives)
>>
>> B
> This has been isolated to r31 in sys/boot/efi; reverting the EFI
> loader to a previous revision stops the crash.
>
> Filed here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940 
>  
>  
> 
>
 Does it still crash with r313442? I think it does and this is why:

 From your log above, the hint is "Failed to start image provided by UFS 
 (14)”, so what we can guess here is that for some reason the loader.efi 
 main() failed to detect the boot device, and did return back to boot1.

 Boot1 did print out this error message and did call panic(). So, the 
 question is, why it is failing to detect the root fs handle. I’ll try to 
 check if I can replicate the issue with x86 + ufs.

 BTW: sorry for trouble:)

 rgds,
 toomas

>>> Yes.
>>>
>>> It's isolated to that particular revision, which appears to have reworked 
>>> the enumeration of the available devices to boot from.  Reverting only 
>>> sys/boot/efi to anything before 31 (e.g. "svn update -r 313332 ." in 
>>> src/sys/boot/efi) and rebuilding results in a loader.efi that successfully 
>>> loads and starts the kernel.
>>>
>> Well, the x86 version does not appear to have problems with finding the ufs 
>> devices. So this has to be some sort of corner case related to arm:( 
>> unfortunately I do not have much variants to test arm, except qemu… so some 
>> help would be needed there. Since the only crash is from boot1 call to 
>> panic, I am pretty sure the disk detection and setup was ok, so we should 
>> get disk list if we insert something like:
>>
>> for (i = 0; devsw[i] != NULL; i++) {
>> if (devsw[i]->dv_print != NULL){
>> if (devsw[i]->dv_print(verbose))
>> break;
>> }
>> }
>>
>> after dv_init() loop.
>>
>> If thats true, then it should not take too much to find why we fail to get 
>> the handle for root fs in case of arm… 
>
> On RPi3 U-Boot EFI API provided by U-Boot and it's somewhat non-standard
> comapring to x86 EFI or specialized EFI firmwares of ARM64. I did some
> debugging and found that U-Boot reports driver with subtype MEDIA_FILEPATH_DP
> so it's not recognized by disk handler. Quick hack below fixed boot
> but it's not ideal and the device structure looks like this:
>
> disk devices:
> disk0:15564801 X 512 blocks (removable)
>   disk0s1: DOS/Windows 49MB
>   disk0s2: FreeBSD 1856MB
> disk0s2a: FreeBSD UFS  1856MB
> disk1:102375 X 512 blocks (removable)
> disk2:3802112 X 512 blocks (removable)
>   disk2a: FreeBSD UFS  1856MB
> net devices:
> net0:
>
>
> disk1 and disk2 are actuallypartitions from disk0.
> I can work on proper fix but not sure what should be
> considered proper in 

Re: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109

[Toomas Soome]

> On 9. veebr 2017, at 17:05, Karl Denninger  wrote:
> 
> 
> On 2/9/2017 08:58, Toomas Soome wrote:
>>> On 9. veebr 2017, at 16:36, Karl Denninger  
>>>  wrote:
>>> 
>>> 
>>> On 2/8/2017 16:18, Karl Denninger wrote:
 r313441 blows up on the Pi3 in /boot/loader.efi with:
 
 FreeBSD/arm64 EFI loader, Revision 1.1
 (Tue Feb  7 15:15:52 CST 2017 free...@newfs.denninger.net 
 )
 Failed to start image provided by UFS (14)
 "Synchronous Abort" handler, esr 0x9604
 ELR: 3af62cec
 LR:  3af61d60
 x0 : 0001 x1 : 0001
 x2 : 3afeb000 x3 : 003f
 x4 : 0020 x5 : 0010
 x6 :  x7 : 39b260a4
 x8 : 3af61d48 x9 : 000d
 x10: 0030 x11: 
 x12:  x13: 0002
 x14:  x15: 
 x16:  x17: 
 x18: 3ab30df8 x19: 37a16008
 x20:  x21: 
 x22: 39b28000 x23: 39b1d49c
 x24: 39b28850 x25: 3ab3d740
 x26: 3af839a0 x27: 39b2e3e8
 x28:  x29: 3ab2ef60
 
 Resetting CPU ...
 
 If you copy in a loader.efi from an earlier build (e.g. r313109) then the 
 system boots but complains about SMP problems, fails to start any of the 
 other CPUs (although it sees them) and panics before it reaches a login 
 prompt with what appears to be a problem reading the SD card (I also get a 
 couple of lor's in here too. not sure if those are "real" or false 
 positives)
 
 B
>>> This has been isolated to r31 in sys/boot/efi; reverting the EFI
>>> loader to a previous revision stops the crash.
>>> 
>>> Filed here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940 
>>>  
>>>  
>>> 
>>> 
>> Does it still crash with r313442? I think it does and this is why:
>> 
>> From your log above, the hint is "Failed to start image provided by UFS 
>> (14)”, so what we can guess here is that for some reason the loader.efi 
>> main() failed to detect the boot device, and did return back to boot1.
>> 
>> Boot1 did print out this error message and did call panic(). So, the 
>> question is, why it is failing to detect the root fs handle. I’ll try to 
>> check if I can replicate the issue with x86 + ufs.
>> 
>> BTW: sorry for trouble:)
>> 
>> rgds,
>> toomas
>> 
> Yes.
> 
> It's isolated to that particular revision, which appears to have reworked the 
> enumeration of the available devices to boot from.  Reverting only 
> sys/boot/efi to anything before 31 (e.g. "svn update -r 313332 ." in 
> src/sys/boot/efi) and rebuilding results in a loader.efi that successfully 
> loads and starts the kernel.
> 

Well, the x86 version does not appear to have problems with finding the ufs 
devices. So this has to be some sort of corner case related to arm:( 
unfortunately I do not have much variants to test arm, except qemu… so some 
help would be needed there. Since the only crash is from boot1 call to panic, I 
am pretty sure the disk detection and setup was ok, so we should get disk list 
if we insert something like:

for (i = 0; devsw[i] != NULL; i++) {
if (devsw[i]->dv_print != NULL){
if (devsw[i]->dv_print(verbose))
break;
}
}

after dv_init() loop.

If thats true, then it should not take too much to find why we fail to get the 
handle for root fs in case of arm… 

rgds,
toomas


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109

[Karl Denninger]

On 2/9/2017 08:58, Toomas Soome wrote:
>> On 9. veebr 2017, at 16:36, Karl Denninger  wrote:
>>
>>
>> On 2/8/2017 16:18, Karl Denninger wrote:
>>> r313441 blows up on the Pi3 in /boot/loader.efi with:
>>>
>>> FreeBSD/arm64 EFI loader, Revision 1.1
>>> (Tue Feb  7 15:15:52 CST 2017 free...@newfs.denninger.net)
>>> Failed to start image provided by UFS (14)
>>> "Synchronous Abort" handler, esr 0x9604
>>> ELR: 3af62cec
>>> LR:  3af61d60
>>> x0 : 0001 x1 : 0001
>>> x2 : 3afeb000 x3 : 003f
>>> x4 : 0020 x5 : 0010
>>> x6 :  x7 : 39b260a4
>>> x8 : 3af61d48 x9 : 000d
>>> x10: 0030 x11: 
>>> x12:  x13: 0002
>>> x14:  x15: 
>>> x16:  x17: 
>>> x18: 3ab30df8 x19: 37a16008
>>> x20:  x21: 
>>> x22: 39b28000 x23: 39b1d49c
>>> x24: 39b28850 x25: 3ab3d740
>>> x26: 3af839a0 x27: 39b2e3e8
>>> x28:  x29: 3ab2ef60
>>>
>>> Resetting CPU ...
>>>
>>> If you copy in a loader.efi from an earlier build (e.g. r313109) then the 
>>> system boots but complains about SMP problems, fails to start any of the 
>>> other CPUs (although it sees them) and panics before it reaches a login 
>>> prompt with what appears to be a problem reading the SD card (I also get a 
>>> couple of lor's in here too. not sure if those are "real" or false 
>>> positives)
>>>
>>> B
>> This has been isolated to r31 in sys/boot/efi; reverting the EFI
>> loader to a previous revision stops the crash.
>>
>> Filed here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940 
>> 
>>
> Does it still crash with r313442? I think it does and this is why:
>
> From your log above, the hint is "Failed to start image provided by UFS 
> (14)”, so what we can guess here is that for some reason the loader.efi 
> main() failed to detect the boot device, and did return back to boot1.
>
> Boot1 did print out this error message and did call panic(). So, the question 
> is, why it is failing to detect the root fs handle. I’ll try to check if I 
> can replicate the issue with x86 + ufs.
>
> BTW: sorry for trouble:)
>
> rgds,
> toomas
>
Yes.

It's isolated to that particular revision, which appears to have
reworked the enumeration of the available devices to boot from. 
Reverting only sys/boot/efi to anything before 31 (e.g. "svn update
-r 313332 ." in src/sys/boot/efi) and rebuilding results in a loader.efi
that successfully loads and starts the kernel.

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109

[Toomas Soome]

> On 9. veebr 2017, at 16:36, Karl Denninger  wrote:
> 
> 
> On 2/8/2017 16:18, Karl Denninger wrote:
>> r313441 blows up on the Pi3 in /boot/loader.efi with:
>> 
>> FreeBSD/arm64 EFI loader, Revision 1.1
>> (Tue Feb  7 15:15:52 CST 2017 free...@newfs.denninger.net)
>> Failed to start image provided by UFS (14)
>> "Synchronous Abort" handler, esr 0x9604
>> ELR: 3af62cec
>> LR:  3af61d60
>> x0 : 0001 x1 : 0001
>> x2 : 3afeb000 x3 : 003f
>> x4 : 0020 x5 : 0010
>> x6 :  x7 : 39b260a4
>> x8 : 3af61d48 x9 : 000d
>> x10: 0030 x11: 
>> x12:  x13: 0002
>> x14:  x15: 
>> x16:  x17: 
>> x18: 3ab30df8 x19: 37a16008
>> x20:  x21: 
>> x22: 39b28000 x23: 39b1d49c
>> x24: 39b28850 x25: 3ab3d740
>> x26: 3af839a0 x27: 39b2e3e8
>> x28:  x29: 3ab2ef60
>> 
>> Resetting CPU ...
>> 
>> If you copy in a loader.efi from an earlier build (e.g. r313109) then the 
>> system boots but complains about SMP problems, fails to start any of the 
>> other CPUs (although it sees them) and panics before it reaches a login 
>> prompt with what appears to be a problem reading the SD card (I also get a 
>> couple of lor's in here too. not sure if those are "real" or false 
>> positives)
>> 
>> B
> 
> This has been isolated to r31 in sys/boot/efi; reverting the EFI
> loader to a previous revision stops the crash.
> 
> Filed here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940 
> 
> 

Does it still crash with r313442? I think it does and this is why:

From your log above, the hint is "Failed to start image provided by UFS (14)”, 
so what we can guess here is that for some reason the loader.efi main() failed 
to detect the boot device, and did return back to boot1.

Boot1 did print out this error message and did call panic(). So, the question 
is, why it is failing to detect the root fs handle. I’ll try to check if I can 
replicate the issue with x86 + ufs.

BTW: sorry for trouble:)

rgds,
toomas


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109

[Karl Denninger]

On 2/8/2017 16:18, Karl Denninger wrote:
> r313441 blows up on the Pi3 in /boot/loader.efi with:
>
> FreeBSD/arm64 EFI loader, Revision 1.1
> (Tue Feb  7 15:15:52 CST 2017 free...@newfs.denninger.net)
> Failed to start image provided by UFS (14)
> "Synchronous Abort" handler, esr 0x9604
> ELR: 3af62cec
> LR:  3af61d60
> x0 : 0001 x1 : 0001
> x2 : 3afeb000 x3 : 003f
> x4 : 0020 x5 : 0010
> x6 :  x7 : 39b260a4
> x8 : 3af61d48 x9 : 000d
> x10: 0030 x11: 
> x12:  x13: 0002
> x14:  x15: 
> x16:  x17: 
> x18: 3ab30df8 x19: 37a16008
> x20:  x21: 
> x22: 39b28000 x23: 39b1d49c
> x24: 39b28850 x25: 3ab3d740
> x26: 3af839a0 x27: 39b2e3e8
> x28:  x29: 3ab2ef60
>
> Resetting CPU ...
>
> If you copy in a loader.efi from an earlier build (e.g. r313109) then the 
> system boots but complains about SMP problems, fails to start any of the 
> other CPUs (although it sees them) and panics before it reaches a login 
> prompt with what appears to be a problem reading the SD card (I also get a 
> couple of lor's in here too. not sure if those are "real" or false 
> positives)
>
> B

This has been isolated to r31 in sys/boot/efi; reverting the EFI
loader to a previous revision stops the crash.

Filed here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature