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

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

[Karl Denninger]

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)

Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0x8004000.
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2017 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-CURRENT #0 r313389: Tue Feb  7 10:13:16 CST 2017
   
free...@newfs.denninger.net:/pics/Crochet-work/obj/arm64.aarch64/pics/CrossBuild-12/src/sys/GENERIC
arm64
FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on
LLVM 3.9.1)
WARNING: WITNESS option enabled, expect reduced performance.
VT: init without driver.
can't re-use a leaf (geom_label)!
module_register: cannot register g_label from kernel; already loaded
from geom_label.ko
Module g_label failed to register: 17
Starting CPU 1 (1)
Starting CPU 2 (2)
Starting CPU 3 (3)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
random: entropy device external interface
kbd0 at kbdmux0
ofwbus0: 
simplebus0:  on ofwbus0
ofw_clkbus0:  on ofwbus0
clk_fixed0:  on ofw_clkbus0
clk_fixed1:  on ofw_clkbus0
clk_fixed2:  on ofw_clkbus0
clk_fixed3:  on ofw_clkbus0
clk_fixed4:  on ofw_clkbus0
clk_fixed5:  on ofw_clkbus0
clk_fixed6:  on ofw_clkbus0
psci0:  on ofwbus0
local_intc0:  mem 0x4000-0x40ff on
simplebus0
intc0:  mem 0x7e00b200-0x7e00b3ff irq 16
on simplebus0
generic_timer0:  irq 37,38,39,40 on simplebus0
Timecounter "ARM MPCore Timecounter" frequency 1920 Hz quality 1000
Event timer "ARM MPCore Eventtimer" frequency 1920 Hz quality 1000
bcm_dma0:  mem 0x7e007000-0x7e007eff irq
0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 on simplebus0
mbox0:  mem 0x7e00b880-0x7e00b8bf irq 17 on
simplebus0
bcmwd0:  mem 0x7e10-0x7e100027 on simplebus0
gpio0:  mem 0x7e20-0x7e2000b3 irq
18,19 on simplebus0
gpiobus0:  on gpio0
gpioc0:  on gpio0
uart0:  mem 0x7e201000-0x7e201fff irq 20 on
simplebus0
uart0: console (115200,n,8,1)
spi0:  mem 0x7e204000-0x7e204fff irq 22 on
simplebus0
spibus0:  on spi0
spibus0:  at cs 0 mode 0
spibus0:  at cs 1 mode 0
sdhci_bcm0:  mem 0x7e30-0x7e3000ff
irq 27 on simplebus0
mmc0:  on sdhci_bcm0
iichb0:  mem 0x7e804000-0x7e804fff irq 31
on simplebus0
iicbus0:  on iichb0
bcm283x_dwcotg0:  mem
0x7e98-0x7e98,0x7e006000-0x7e006fff irq 33,34 on simplebus0
usbus0 on bcm283x_dwcotg0
gpioled0:  on simplebus0
gpioled0:  failed to map pin
fb0:  on simplebus0
fbd0 on fb0
VT: initialize with new VT driver "fb".
fb0: 656x416(656x416@0,0) 24bpp
fb0: fbswap: 1, pitch 1968, base 0x3db33000, screen_size 818688
pmu0:  irq 36 on simplebus0
cpulist0:  on ofwbus0
cpu0:  on cpulist0
bcm2835_cpufreq0:  on cpu0
cpu1:  on cpulist0
cpu2:  on cpulist0
cpu3:  on cpulist0
cryptosoft0: 
Timecounters tick every 1.000 msec
The GEOM class LABEL is already loaded.
usbus0: 480Mbps High Speed USB v2.0
ugen0.1:  at usbus0
uhub0:  on usbus0
mmcsd0: 32GB  at mmc0
41.6MHz/4bit/65535-block
bcm2835_cpufreq0: ARM 600MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF
Release APs
APs not started
CPU  0: ARM Cortex-A53 r0p4 affinity:  0
 Instruction Set Attributes 0 = 
 Instruction Set Attributes 1 = <0>
 Processor Features 0 = 
 Processor Features 1 = <0>
  Memory Model Features 0 = <4k Granule,64k Granule,MixedEndian,S/NS
Mem,16bit ASID,1TB PA>
  Memory Model Features 1 = <>
 Debug Features 0 = <2 CTX Breakpoints,4 Watchpoints,6
Breakpoints,PMUv3,Debug v8>
 Debug Features 1 = <0>
 Auxiliary Features 0 = <0>
 Auxiliary Features 1 = <0>
CPU  1: ARM Cortex-A53 r0p4