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

Thu Feb 8 23:55:49 UTC 2018

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.

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

While qemu_arm64 works.

Bisecting rpi_3 again, removing obj dir between runs and skipping
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
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