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

Heinrich Schuchardt xypron.glpk at gmx.de
Fri Feb 9 03:43:09 UTC 2018


On 02/09/2018 12:55 AM, Jonathan Gray wrote:
> On Thu, Feb 08, 2018 at 03:44:32PM +0100, Heinrich Schuchardt wrote:
>> 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
> 
> There are multiple regressions with U-Boot master compared to 2018.01.

U-Boot master is a moving target. Please, state the commit.

> 
> sopine_baseboard (pinebook), reported to me I don't have hardware
> rpi_3
> mx6cuboxi
> vexpress_ca15_tc2

It is unclear what this sentence means.

Do you expect to that a pinebook can boot from a U-Boot that is compiled 
with rpi_3_defconfig?

Wouldn't you use a U-Boot image compiled with sopine_baseboard_defconfig 
for your pinebook?

> 
> While qemu_arm64 works.
> 
> Bisecting rpi_3 again, removing obj dir between runs and skipping

What do you mean by obj dir?

> commits where nothing shows up on serial again gives the same:
> 
> commit caf2233b281c03e3e359061a3dfa537d8a25c273
> Author:     Alexander Graf <agraf at suse.de>
> AuthorDate: Tue Jan 23 18:05:21 2018 +0100
> Commit:     Tom Rini <trini at konsulko.com>
> CommitDate: Sun Jan 28 12:27:32 2018 -0500
> 
>      bcm283x: Add pinctrl driver
>      
>      The bcm283x family of SoCs have a GPIO controller that also acts as
>      pinctrl controller.
>      
>      This patch introduces a new pinctrl driver that can actually properly mux
>      devices into their device tree defined pin states and is now the primary
>      owner of the gpio device. The previous GPIO driver gets moved into a
>      subdevice of the pinctrl driver, bound to the same OF node.
>      
>      That way whenever a device asks for pinctrl support, it gets it
>      automatically from the pinctrl driver and GPIO support is still available
>      in the normal command line phase.
>      
>      Signed-off-by: Alexander Graf <agraf at suse.de>
> 
> with master as of e24bd1e79e223aa89854c0be95a53e2d538144a5
> 
> U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 09 2018 - 11:36:18 +1300)
> 
> DRAM:  948 MiB
> RPI 3 Model B (0xa02082)
> MMC:   mmc at 7e202000: 0, sdhci at 7e300000: 1
> Loading Environment from FAT... OK
> 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
> 82748 bytes read in 89 ms (907.2 KiB/s)
> ## Starting EFI application at 01000000 ...
> Scanning disk mmc at 7e202000.blk...
> Card did not respond to voltage select!
> mmc_init: -95, time 25
> Scanning disk sdhci at 7e300000.blk...
>>> OpenBSD/arm64 BOOTAA64 0.11
> open(tftp0a:/etc/boot.conf): Operation not permitted

With this little output it is impossible to analyze what is going on. 
Please, enable debug output using

#define DEBUG 1

in the relevant U-Boot files before the first include.

To disable output for some time critical routines in the same source 
file you could use:

#undef _DEBUG
#define _DEBUG 0

... time critical code ...

#undef _DEBUG
#define _DEBUG 1

I guess Alex has a rpi_3 available. Can he use the following disk image 
for testing?

https://ftp.eu.openbsd.org/pub/OpenBSD/6.2/arm64/miniroot62.fs

Best regards

Heinrich

> boot>
> booting tftp0a:/bsd: open tftp0a:/bsd: Operation not permitted
>   failed(1). will try /bsd
> 
> with vexpress_ca15_tc2, bisects to
> 
> commit d0c221fe7336fc7d9ada57d96f4a8911a3aac041
> Author:     Jean-Jacques Hiblot <jjhiblot at ti.com>
> AuthorDate: Thu Sep 21 16:29:57 2017 +0200
> Commit:     Jaehoon Chung <jh80.chung at samsung.com>
> CommitDate: Fri Jan 12 18:11:04 2018 +0900
> 
>      mmc: refactor SD startup to make it easier to support new modes
>      
>      The SDcard startup process currently handles only 2 modes. To make it
>      easier to add support for more modes, let's make the process more generic
>      and use a list of the modes to try.
>      The major functional change is that when a mode fails we try the next one.
>      Not all modes are tried, only those supported by the card and the host.
>      
>      Signed-off-by: Jean-Jacques Hiblot <jjhiblot at ti.com>
>      Reviewed-by: Simon Glass <sjg at chromium.org>
> 
> with master as of e24bd1e79e223aa89854c0be95a53e2d538144a5
> 
> U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 09 2018 - 11:31:54 +1300)
> 
> DRAM:  1 GiB
> WARNING: Caches not enabled
> Flash: 128 MiB
> MMC:   MMC: 0
> *** Warning - bad CRC, using default environment
> 
> In:    serial
> Out:   serial
> Err:   serial
> Net:   smc911x-0
> Hit any key to stop autoboot:  0
> => load mmc 0:1 ${ramdisk_addr} fdt.dtb
> unable to select a mode
> mmc_init: -524, time 23
> unable to select a mode
> mmc_init: -524, time 22
> ** Bad device mmc 0 **
> => load mmc 0:1 ${loadaddr} efi/boot/bootarm.efi
> unable to select a mode
> mmc_init: -524, time 21
> unable to select a mode
> mmc_init: -524, time 21
> ** Bad device mmc 0 **
> => bootefi ${loadaddr} ${ramdisk_addr}
> ## Starting EFI application at a0008000 ...
> WARNING: using memory device/image path, this may confuse some payloads!
> Scanning disks on mmc...
> unable to select a mode
> mmc_init: -524, time 21
> MMC Device 1 not found
> MMC Device 2 not found
> MMC Device 3 not found
> Found 0 disks
> WARNING: Invalid device tree, expect boot to fail
> efi_load_pe: Invalid DOS Signature
> 
> with mx6cuboxi, bisects to
> 
> commit 64e4db0f119151a1345e1da19d152eda550394e7
> Author:     Heinrich Schuchardt <xypron.glpk at gmx.de>
> AuthorDate: Fri Jan 19 20:24:47 2018 +0100
> Commit:     Alexander Graf <agraf at suse.de>
> CommitDate: Mon Jan 22 23:09:14 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>
> 
> with master as of e24bd1e79e223aa89854c0be95a53e2d538144a5
> 
> U-Boot SPL 2018.03-rc1-00185-g1e19c70639 (Feb 09 2018 - 11:43:18 +1300)
> Trying to boot from MMC1
> 
> 
> U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 09 2018 - 11:43:18 +1300)
> 
> CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
> CPU:   Extended Commercial temperature grade (-20C to 105C) at 24C
> Reset cause: POR
> Board: MX6 Cubox-i
> DRAM:  2 GiB
> MMC:   FSL_SDHC: 0
> Loading Environment from MMC... OK
> No panel detected: default to HDMI
> Display: HDMI (1024x768)
> In:    serial
> Out:   serial
> Err:   serial
> Net:   FEC
> Hit any key to stop autoboot:  0
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> 37503 bytes read in 17 ms (2.1 MiB/s)
> Found EFI removable media binary efi/boot/bootarm.efi
> Scanning disks on usb...
> 76528 bytes read in 31 ms (2.4 MiB/s)
> ## Starting EFI application at 12000000 ...
> BS->LocateHandle() returns -2147483634
> undefined instruction
> pc : [<8e560348>]	   lr : [<8e56444c>]
> reloc pc : [<15de4348>]	   lr : [<15de844c>]
> sp : 8f57af10  ip : 8ffc2474	 fp : 8f57af1c
> r10: 0000b000  r9 : 8f57bee0	 r8 : 0000000b
> r7 : 8ffa1a9d  r6 : 8ffa16ad	 r5 : 8e56f0d0	r4 : 8e56e88a
> r3 : 8e56dac8  r2 : 00000001	 r1 : 00000000	r0 : 00000000
> Flags: nZCv  IRQs off  FIQs off	 Mode SVC_32
> Resetting CPU ...
> 
> resetting ...
> 
> (undefined instruction is used to reset as efi reset was not
> present in earlier U-Boot versions)
> 
> qemu_arm64 with master as of e24bd1e79e223aa89854c0be95a53e2d538144a5
> 
> U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 09 2018 - 12:21:06 +1300)
> 
> DRAM:  2 GiB
> In:    pl011 at 9000000
> Out:   pl011 at 9000000
> Err:   pl011 at 9000000
> Net:   No ethernet found.
> Hit any key to stop autoboot:  0
> scanning bus for devices...
> Target spinup took 0 ms.
> SATA link 1 timeout.
> SATA link 2 timeout.
> SATA link 3 timeout.
> SATA link 4 timeout.
> SATA link 5 timeout.
> AHCI 0001.0000 32 slots 6 ports 1.5 Gbps 0x3f impl SATA mode
> flags: 64bit ncq only
>    Device 0: (0:0) Vendor: ATA Prod.: QEMU HARDDISK Rev: 2.5+
> 	    Type: Hard Disk
> 	    Capacity: 4096.0 MB = 4.0 GB (8388608 x 512)
> 
> Device 0: (0:0) Vendor: ATA Prod.: QEMU HARDDISK Rev: 2.5+
> 	    Type: Hard Disk
> 	    Capacity: 4096.0 MB = 4.0 GB (8388608 x 512)
> ... is now current device
> Scanning scsi 0:1...
> load - load binary file from a filesystem
> 
> Usage:
> load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]]
>      - Load binary file 'filename' from partition 'part' on device
>         type 'interface' instance 'dev' to address 'addr' in memory.
>        'bytes' gives the size to load in bytes.
>        If 'bytes' is 0 or omitted, the file is read until the end.
>        'pos' gives the file byte position to start reading from.
>        If 'pos' is 0 or omitted, the file is read from the start.
> Found EFI removable media binary efi/boot/bootaa64.efi
> Scanning disk ahci_scsi.id0lun0...
> Found 3 disks
> 82748 bytes read in 11 ms (7.2 MiB/s)
> ## Starting EFI application at 40400000 ...
>>> OpenBSD/arm64 BOOTAA64 0.11
> boot>
> booting sd0a:/bsd: 3913300+580492+583920+806432/[279463+96+459168+244083]=0x843970
> 



More information about the U-Boot mailing list