[U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver

[Heinrich Schuchardt]

On 02/08/2018 10:49 AM, Jonathan Gray wrote:
> On Thu, Feb 08, 2018 at 08:10:47PM +1100, Jonathan Gray wrote:
>> On Thu, Feb 08, 2018 at 09:11:20AM +0100, Alexander Graf wrote:
>>>
>>>
>>>> Am 08.02.2018 um 06:49 schrieb Jonathan Gray <jsg at jsg.id.au>:
>>>>
>>>> On Mon, Feb 05, 2018 at 11:31:42AM +0100, Mark Kettenis wrote:
>>>>>> Date: Mon, 5 Feb 2018 21:06:59 +1100
>>>>>> From: Jonathan Gray <jsg at jsg.id.au>
>>>>>>
>>>>>>>> booting sd0a:/bsd: open sd0a:/bsd: Device not configured
>>>>>>>> failed(6). will try /bsd
>>>>>>>
>>>>>>> How do you find out that it's sd0a instead of sd1a?
>>>>>>
>>>>>> The loaded image protocol I believe.
>>>>>
>>>>> Actually the OpenBSD bootloader currently only supports loading the
>>>>> bsd kernel from the same device as the bootloader.  It will always
>>>>> call that device sd0.  It invokes the device path protocol on the
>>>>> loaded image handle and then matches that path to a device that
>>>>> supports the block io protocol.
>>>>
>>>> Perhaps the problem is elsewhere as U-Boot master also broke
>>>> vexpress_ca15_tc2 and mx6cuboxi targets:
>>>
>>> Perfect, so can you quickly bisect it now that the bisect doesn???t end at the pinctrl driver?
>>
>> On cubox a bisect points to
>>
>> commit 64e4db0f119151a1345e1da19d152eda550394e7
>> Author: Heinrich Schuchardt <xypron.glpk at gmx.de>
>> Date:   Fri Jan 19 20:24:47 2018 +0100
>>
>>     efi_loader: make efi_disk_create_partitions a global symbol
>>     
>>     Up to now we have been using efi_disk_create_partitions() to create
>>     partitions for block devices that existed before starting an EFI
>>     application.
>>     
>>     We need to call it for block devices created by EFI
>>     applications at run time. The EFI application will define the
>>     handle for the block device and install a device path protocol
>>     on it. We have to use this device path as stem for the partition
>>     device paths.
>>     
>>     Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
>>     Signed-off-by: Alexander Graf <agraf at suse.de>
>>
>>  include/efi_loader.h      |  4 +++
>>  lib/efi_loader/efi_disk.c | 84 +++++++++++++++++++++++++++++++++++++++----------------
>>  2 files changed, 64 insertions(+), 24 deletions(-)
>>
>> If I revert this commit a image built from master works.
> 
> Actually master doesn't build with just that reverted, seems I had stale
> object files.

When bisecting running
'make mrproper && make foo_defconfig && make'
in each round is recommendable.

Do you still assume a problem that requires a change in U-Boot?
Or can we close the topic?

Best regards

Heinrich


> 
> rpi3 with the commit just before boots
> 
> 98d48bdf415e318a11f9f9a44dff2b70aef3fb10
> efi_loader: provide a function to create a partition node
> 
> U-Boot 2018.01-00408-gb7b3517a7f (Feb 08 2018 - 22:35:55 +1300)
> 
> DRAM:  948 MiB
> RPI 3 Model B (0xa02082)
> MMC:   sdhci at 7e300000: 0
> In:    serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   No ethernet found.
> starting USB...
> USB0:	Core Release: 2.80a
> scanning bus 0 for devices... 4 USB Device(s) found
>        scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot:  0
> 
> Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra
> 	    Type: Removable Hard Disk
> 	    Capacity: 29327.3 MB = 28.6 GB (60062500 x 512)
> ... is now current device
> Scanning usb 0:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> unhandled parent class: usb_mass_storage.lun0 (13)
> 82748 bytes read in 89 ms (907.2 KiB/s)
> ## Starting EFI application at 01000000 ...
> Scanning disk sdhci at 7e300000.blk...
> unhandled parent class: sdhci at 7e300000.blk (13)
> unhandled parent class: sdhci at 7e300000.blk (13)
> unhandled parent class: sdhci at 7e300000.blk (13)
> Scanning disk usb_mass_storage.lun0...
> unhandled parent class: usb_mass_storage.lun0 (13)
> unhandled parent class: usb_mass_storage.lun0 (13)
> unhandled parent class: usb_mass_storage.lun0 (13)
> Found 6 disks
>>> OpenBSD/arm64 BOOTAA64 0.11
> boot>
> booting sd0a:/bsd: 3917796+579072+585220+806860-[280094+96+459168+244083]=0x8442a8
>