Rpi: Add support for second sd host controller

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 <[email protected]>

Quoted 8 lines · Alexander Graf

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.

Quoted 5 lines

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 <[email protected]>

Applied to u-boot/master, thanks!

Quoted 14 lines · Tom Rini

Quoted 12 lines · Alexander Graf

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.

Quoted 3 lines

Quoted 1 line

Signed-off-by Alexander Graf <[email protected]>

Applied to u-boot/master, thanks!

It seems one of the recent commits here has broken booting on rpi_3 with the vendor supplied device tree via efi_loader.

Quoted 15 lines · Jonathan Gray

Quoted 14 lines · Tom Rini

Quoted 12 lines · Alexander Graf

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.

Quoted 6 lines

Quoted 3 lines

Quoted 1 line

Signed-off-by Alexander Graf <[email protected]>

Applied to u-boot/master, thanks!

It seems one of the recent commits here has broken booting on rpi_3 with the vendor supplied device tree via efi_loader.

Do you have a pointer to the dtb? I'm actually using the vendor supplied device tree to boot, but I don't specify it, I just leave it to the RPi fw to pass it in.

Can you please go into detail on your setup?

Alex

Quoted 1 line

OpenBSD/arm64 BOOTAA64 0.8

Quoted 25 lines · Alexander Graf

Quoted 15 lines · Jonathan Gray

Quoted 14 lines · Tom Rini

Quoted 12 lines · Alexander Graf

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.

Quoted 6 lines

Quoted 3 lines

Quoted 1 line

Signed-off-by Alexander Graf <[email protected]>

Applied to u-boot/master, thanks!

It seems one of the recent commits here has broken booting on rpi_3 with the vendor supplied device tree via efi_loader.

Quoted 8 lines

Do you have a pointer to the dtb? I'm actually using the vendor supplied device tree to boot, but I don't specify it, I just leave it to the RPi fw to pass it in.

Can you please go into detail on your setup?

Alex

Sure. Using the most recent release of the firmware
https://github.com/raspberrypi/firmware/releases/tag/1.20171029

https://github.com/raspberrypi/firmware/raw/1.20171029/boot/bcm2710-rpi-3-b.dtb

dtb is placed in the root of the fat partition and loaded by the firmware, it is not placed in a 'broadcom' or 'dtb' directory.

MD5 (bcm2710-rpi-3-b.dtb) = dfa51a479a28d66868e1ff0baab3d6eb MD5 (bootcode.bin) = fd01b240fcc5d4c83560676415081508 MD5 (fixup.dat) = 226cbdc001b39c58a9730675befbe0de MD5 (start.elf) = a65f795ac3ba99373d2194cee1034f8a

$ cat config.txt                                                            
arm_control=0x200
enable_uart=1
device_tree_address=0x100
kernel=u-boot.bin

These files are included in the installation disk image for OpenBSD/arm64 (along with u-boot.bin):

https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot62.fs

In the setup I use U-Boot is loaded off sd card with boot target set to prefer usb (fuse to enable usb boot isn't blown). distro bootcmd finds bootaa64.efi and loads that.

With a U-Boot built from 2e87980580d0bf4781ad0d63efd456aa1a73d03f:

U-Boot 2018.03-rc1-00058-g36d3bd9514 (Feb 03 2018 - 22:13:26 +1100)

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
U-Boot> printenv
arch=arm
baudrate=115200
board=rpi
board_name=3 Model B
board_rev=0x8
board_rev_scheme=1
board_revision=0xA02082
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf
boot_net_usb_start=usb start
boot_prefixes=/ /boot/
boot_script_dhcp=boot.scr.uimg
boot_scripts=boot.scr.uimg boot.scr
boot_targets=usb0 mmc0 pxe dhcp
bootcmd=run distro_bootcmd
bootcmd_dhcp=run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00011:UNDI:003000;setenv bootp_arch 0xb;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci; bootcmd_mmc0=setenv devnum 0; run mmc_boot
bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi
bootcmd_usb0=setenv devnum 0; run usb_boot
bootdelay=2
bootfstype=fat
cpu=armv8
devnum=0
devplist=1
devtype=usb
dhcpuboot=usb start; dhcp u-boot.uimg; bootm
distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported={ro,boot}(blob)0000000000000000
efi_dtb_prefixes=/ /dtb/ /dtb/current/
efi_fdtfile=broadcom/bcm2837-rpi-3-b.dtb
ethaddr=b8:27:eb:18:54:ea
fdt_addr=100
fdt_addr_r=0x00000100
fdt_high=ffffffff
fdtaddr=100
fdtcontroladdr=3b3a3960
fdtfile=broadcom/bcm2837-rpi-3-b.dtb
fileaddr=1000000
filesize=1346f
initrd_high=ffffffff
kernel_addr_r=0x01000000
load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
loadaddr=0x00200000
mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi
preboot=usb start
pxefile_addr_r=0x00100000
ramdisk_addr_r=0x02100000
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done
scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootaa64.efi; then echo Found EFI removable media binary efi/boot/bootaa64.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scriptaddr=0x02000000
serial#=00000000eb1854ea
soc=bcm283x
stderr=serial,vidconsole
stdin=serial,usbkbd
stdout=serial,vidconsole
usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run scan_dev_for_boot_part; fi
usbethaddr=b8:27:eb:18:54:ea
vendor=raspberrypi

Environment size: 4081/16380 bytes
U-Boot> boot

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 78335 bytes read in 79 ms (967.8 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...

Quoted 1 line

Quoted 1 line

OpenBSD/arm64 BOOTAA64 0.8

boot>
cannot open sd0a:/etc/random.seed: Device not configured

booting sd0a:/bsd: open sd0a:/bsd: Device not configured
failed(6). will try /bsd

boot>

U-Boot> part list mmc 0

Partition Map for MMC device 0 -- Partition Type: DOS

Part    Start Sector    Num Sectors     UUID            Type
  1     8192            8192            00000000-01     0c Boot
  4     16384           26624           00000000-04     a6

U-Boot> part list usb 0

Partition Map for USB device 0 -- Partition Type: DOS

Part    Start Sector    Num Sectors     UUID            Type
  1     8192            32768           00000000-01     0c Boot
  4     40960           60021540        00000000-04     a6

U-Boot> ls mmc 0:1 /

Quoted 59 lines · Jonathan Gray

Quoted 25 lines · Alexander Graf

Quoted 15 lines · Jonathan Gray

Quoted 14 lines · Tom Rini

Quoted 12 lines · Alexander Graf

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.

Quoted 6 lines

Quoted 3 lines

Quoted 1 line

Signed-off-by Alexander Graf <[email protected]>

Applied to u-boot/master, thanks!

It seems one of the recent commits here has broken booting on rpi_3 with the vendor supplied device tree via efi_loader.

Quoted 8 lines

Do you have a pointer to the dtb? I'm actually using the vendor supplied device tree to boot, but I don't specify it, I just leave it to the RPi fw to pass it in.

Can you please go into detail on your setup?

Alex

Sure. Using the most recent release of the firmware
https://github.com/raspberrypi/firmware/releases/tag/1.20171029

https://github.com/raspberrypi/firmware/raw/1.20171029/boot/bcm2710-rpi-3-b.dtb

dtb is placed in the root of the fat partition and loaded by the firmware, it is not placed in a 'broadcom' or 'dtb' directory.

MD5 (bcm2710-rpi-3-b.dtb) = dfa51a479a28d66868e1ff0baab3d6eb MD5 (bootcode.bin) = fd01b240fcc5d4c83560676415081508 MD5 (fixup.dat) = 226cbdc001b39c58a9730675befbe0de MD5 (start.elf) = a65f795ac3ba99373d2194cee1034f8a

$ cat config.txt                                                            
arm_control=0x200
enable_uart=1
device_tree_address=0x100
kernel=u-boot.bin

These files are included in the installation disk image for OpenBSD/arm64 (along with u-boot.bin):

https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot62.fs

Quoted 5 lines

In the setup I use U-Boot is loaded off sd card with boot target set to prefer usb (fuse to enable usb boot isn't blown). distro bootcmd finds bootaa64.efi and loads that.

With a U-Boot built from 2e87980580d0bf4781ad0d63efd456aa1a73d03f:

Are you using the defconfig or do you set CONFIG_OF_BOARD to fetch the U-Boot DT from firmware?

Quoted 96 lines

U-Boot 2018.03-rc1-00058-g36d3bd9514 (Feb 03 2018 - 22:13:26 +1100)

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
U-Boot> printenv
arch=arm
baudrate=115200
board=rpi
board_name=3 Model B
board_rev=0x8
board_rev_scheme=1
board_revision=0xA02082
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf
boot_net_usb_start=usb start
boot_prefixes=/ /boot/
boot_script_dhcp=boot.scr.uimg
boot_scripts=boot.scr.uimg boot.scr
boot_targets=usb0 mmc0 pxe dhcp
bootcmd=run distro_bootcmd
bootcmd_dhcp=run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00011:UNDI:003000;setenv bootp_arch 0xb;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci; bootcmd_mmc0=setenv devnum 0; run mmc_boot
bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi
bootcmd_usb0=setenv devnum 0; run usb_boot
bootdelay=2
bootfstype=fat
cpu=armv8
devnum=0
devplist=1
devtype=usb
dhcpuboot=usb start; dhcp u-boot.uimg; bootm
distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported={ro,boot}(blob)0000000000000000
efi_dtb_prefixes=/ /dtb/ /dtb/current/
efi_fdtfile=broadcom/bcm2837-rpi-3-b.dtb
ethaddr=b8:27:eb:18:54:ea
fdt_addr=100
fdt_addr_r=0x00000100
fdt_high=ffffffff
fdtaddr=100
fdtcontroladdr=3b3a3960
fdtfile=broadcom/bcm2837-rpi-3-b.dtb
fileaddr=1000000
filesize=1346f
initrd_high=ffffffff
kernel_addr_r=0x01000000
load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
loadaddr=0x00200000
mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi
preboot=usb start
pxefile_addr_r=0x00100000
ramdisk_addr_r=0x02100000
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done
scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootaa64.efi; then echo Found EFI removable media binary efi/boot/bootaa64.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scriptaddr=0x02000000
serial#=00000000eb1854ea
soc=bcm283x
stderr=serial,vidconsole
stdin=serial,usbkbd
stdout=serial,vidconsole
usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run scan_dev_for_boot_part; fi
usbethaddr=b8:27:eb:18:54:ea
vendor=raspberrypi

Environment size: 4081/16380 bytes
U-Boot> boot

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 78335 bytes read in 79 ms (967.8 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...

Quoted 3 lines

Quoted 1 line

Quoted 1 line

OpenBSD/arm64 BOOTAA64 0.8

boot>
cannot open sd0a:/etc/random.seed: Device not configured

What does that mean? Which EFI call returns which error code here?

Quoted 3 lines

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 only thing I can think of that changed with this commit is that now we're honoring the device tree's pinmuxing rules. So if the DT wants to use the sdhost mmc controller instead of the sdhci one, it will actually get muxed there. Before, we didn't mux, so on the rpi3 we just happened to run on the sdhci.

At least the default Linux dtb uses sdhost for SD card access.

So maybe all that happened was a change in device numbers because we end up creating device nodes for mmc devices that don't have a card plugged in (sdhci).

In that case however, I guess it means you really were booting from MMC before, rather than USB?

Quoted 12 lines

boot>

U-Boot> part list mmc 0

Partition Map for MMC device 0 -- Partition Type: DOS

Part    Start Sector    Num Sectors     UUID            Type
  1     8192            8192            00000000-01     0c Boot
  4     16384           26624           00000000-04     a6

U-Boot> part list usb 0

Quoted 6 lines

Partition Map for USB device 0 -- Partition Type: DOS

Part    Start Sector    Num Sectors     UUID            Type
  1     8192            32768           00000000-01     0c Boot
  4     40960           60021540        00000000-04     a6

U-Boot> ls mmc 0:1 /

I assume "ls usb 0:1 /" also works?

Date: Mon, 5 Feb 2018 21:06:59 +1100
From: Jonathan Gray <[email protected]>

Quoted 4 lines

Quoted 2 lines

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.

Quoted 12 lines

The only thing I can think of that changed with this commit is that now we're honoring the device tree's pinmuxing rules. So if the DT wants to use the sdhost mmc controller instead of the sdhci one, it will actually get muxed there. Before, we didn't mux, so on the rpi3 we just happened to run on the sdhci.

At least the default Linux dtb uses sdhost for SD card access.

So maybe all that happened was a change in device numbers because we end up creating device nodes for mmc devices that don't have a card plugged in (sdhci).

Quoted 2 lines

In that case however, I guess it means you really were booting from MMC before, rather than USB?

There is no driver for either broadcom mmc controller in OpenBSD. U-Boot is loaded of the sd card, then bootaa64.efi is loaded from usb via "boot_targets=usb0 mmc0 pxe dhcp" and distro bootcmd. Root filesystem is then on usb.

Quoted 11 lines

Quoted 11 lines

boot>

U-Boot> part list mmc 0

Partition Map for MMC device 0 -- Partition Type: DOS

Part    Start Sector    Num Sectors     UUID            Type
  1     8192            8192            00000000-01     0c Boot
  4     16384           26624           00000000-04     a6

U-Boot> part list usb 0

Quoted 8 lines

Quoted 6 lines

Partition Map for USB device 0 -- Partition Type: DOS

Part    Start Sector    Num Sectors     UUID            Type
  1     8192            32768           00000000-01     0c Boot
  4     40960           60021540        00000000-04     a6

U-Boot> ls mmc 0:1 /

I assume "ls usb 0:1 /" also works?

U-Boot> ls usb 0:1 /

            efi/
    50248   bootcode.bin
  2820196   start.elf
     6551   fixup.dat
    17794   bcm2710-rpi-3-b.dtb
    16550   bcm2710-rpi-cm3.dtb
   422776   u-boot.bin
       76   config.txt

7 file(s), 1 dir(s)

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
https://lists.denx.de/listinfo/u-boot

Quoted 8 lines

Date: Mon, 5 Feb 2018 21:06:59 +1100
From: Jonathan Gray <[email protected]>

Quoted 4 lines

Quoted 2 lines

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?

Quoted 1 line

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.

Quoted 1 line

OpenBSD/armv7 BOOTARM 1.0

Quoted 1 line

OpenBSD/armv7 BOOTARM 1.0

Am 08.02.2018 um 06:49 schrieb Jonathan Gray <[email protected]>:

Quoted 10 lines · Mark Kettenis

Quoted 9 lines

Date: Mon, 5 Feb 2018 21:06:59 +1100
From: Jonathan Gray <[email protected]>

Quoted 4 lines

Quoted 2 lines

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.

Quoted 5 lines

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:

Quoted 21 lines

Am 08.02.2018 um 06:49 schrieb Jonathan Gray <[email protected]>:

Quoted 15 lines · Mark Kettenis

Quoted 9 lines

Date: Mon, 5 Feb 2018 21:06:59 +1100
From: Jonathan Gray <[email protected]>

Quoted 4 lines

Quoted 2 lines

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.

Quoted 2 lines

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?

Quoted 21 lines · Alexander Graf

Quoted 21 lines

Am 08.02.2018 um 06:49 schrieb Jonathan Gray <[email protected]>:

Quoted 15 lines · Mark Kettenis

Quoted 9 lines

Date: Mon, 5 Feb 2018 21:06:59 +1100
From: Jonathan Gray <[email protected]>

Quoted 4 lines

Quoted 2 lines

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.

Quoted 4 lines

Quoted 2 lines

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 <[email protected]>
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 <[email protected]>

Signed-off-by Alexander Graf <[email protected]>

 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.

Quoted 1 line

OpenBSD/arm64 BOOTAA64 0.11

Quoted 48 lines · Jonathan Gray

Quoted 21 lines · Alexander Graf

Quoted 21 lines

Am 08.02.2018 um 06:49 schrieb Jonathan Gray <[email protected]>:

Quoted 15 lines · Mark Kettenis

Quoted 9 lines

Date: Mon, 5 Feb 2018 21:06:59 +1100
From: Jonathan Gray <[email protected]>

Quoted 4 lines

Quoted 2 lines

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.

Quoted 4 lines

Quoted 2 lines

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 <[email protected]>
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 <[email protected]>

Signed-off-by Alexander Graf <[email protected]>

Quoted 5 lines

 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.

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

Quoted 1 line

Quoted 1 line

OpenBSD/arm64 BOOTAA64 0.11

boot>
booting sd0a:/bsd: 3917796+579072+585220+806860-[280094+96+459168+244083]=0x8442a8

Quoted 49 lines · Jonathan Gray

Quoted 48 lines · Jonathan Gray

Quoted 21 lines · Alexander Graf

Quoted 21 lines

Am 08.02.2018 um 06:49 schrieb Jonathan Gray <[email protected]>:

Quoted 15 lines · Mark Kettenis

Quoted 9 lines

Date: Mon, 5 Feb 2018 21:06:59 +1100
From: Jonathan Gray <[email protected]>

Quoted 4 lines

Quoted 2 lines

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.

Quoted 4 lines

Quoted 2 lines

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 <[email protected]>
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 <[email protected]>

Signed-off-by Alexander Graf <[email protected]>

Quoted 8 lines

Quoted 5 lines

 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

Quoted 1 line

OpenBSD/arm64 BOOTAA64 0.11

Quoted 1 line

OpenBSD/arm64 BOOTAA64 0.11

Quoted 63 lines · Heinrich Schuchardt

Quoted 49 lines · Jonathan Gray

Quoted 48 lines · Jonathan Gray

Quoted 21 lines · Alexander Graf

Quoted 21 lines

Am 08.02.2018 um 06:49 schrieb Jonathan Gray <[email protected]>:

Quoted 15 lines · Mark Kettenis

Quoted 9 lines

Date: Mon, 5 Feb 2018 21:06:59 +1100
From: Jonathan Gray <[email protected]>

Quoted 4 lines

Quoted 2 lines

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.

Quoted 4 lines

Quoted 2 lines

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 <[email protected]>
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 <[email protected]>

Signed-off-by Alexander Graf <[email protected]>

Quoted 8 lines

Quoted 5 lines

  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.

Quoted 6 lines

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 <[email protected]>
AuthorDate: Tue Jan 23 18:05:21 2018 +0100
Commit:     Tom Rini <[email protected]>
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 <[email protected]>

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...

Quoted 1 line

Quoted 1 line

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 <[email protected]>
AuthorDate: Thu Sep 21 16:29:57 2017 +0200
Commit:     Jaehoon Chung <[email protected]>
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 <[email protected]>

Reviewed-by Simon Glass <[email protected]>

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 <[email protected]>
AuthorDate: Fri Jan 19 20:24:47 2018 +0100
Commit:     Alexander Graf <[email protected]>
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 <[email protected]>

Signed-off-by Alexander Graf <[email protected]>

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 ...

Quoted 1 line

Quoted 1 line

OpenBSD/arm64 BOOTAA64 0.11

boot>
booting sd0a:/bsd: 3913300+580492+583920+806432/[279463+96+459168+244083]=0x843970

Quoted 64 lines · Jonathan Gray

Quoted 63 lines · Heinrich Schuchardt

Quoted 46 lines · Jonathan Gray

Quoted 45 lines · Jonathan Gray

Quoted 21 lines · Alexander Graf

Quoted 21 lines

Am 08.02.2018 um 06:49 schrieb Jonathan Gray <[email protected]>:

Quoted 15 lines · Mark Kettenis

Quoted 9 lines

Date: Mon, 5 Feb 2018 21:06:59 +1100
From: Jonathan Gray <[email protected]>

Quoted 4 lines

Quoted 2 lines

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.

Quoted 4 lines

Quoted 2 lines

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 <[email protected]>
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 <[email protected]>

Signed-off-by Alexander Graf <[email protected]>

Quoted 8 lines

Quoted 5 lines

  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?

Quoted 5 lines

Quoted 3 lines

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.

Quoted 6 lines

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?

Quoted 5 lines

While qemu_arm64 works.

Bisecting rpi_3 again, removing obj dir between runs and skipping

What do you mean by obj dir?

Quoted 51 lines

commits where nothing shows up on serial again gives the same:

commit caf2233b281c03e3e359061a3dfa537d8a25c273

Author:     Alexander Graf <[email protected]>
AuthorDate: Tue Jan 23 18:05:21 2018 +0100
Commit:     Tom Rini <[email protected]>
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 <[email protected]>

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...

Quoted 2 lines

Quoted 1 line

Quoted 1 line

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

Quoted 65 lines · Heinrich Schuchardt

Quoted 64 lines · Jonathan Gray

Quoted 63 lines · Heinrich Schuchardt

Quoted 46 lines · Jonathan Gray

Quoted 45 lines · Jonathan Gray

Quoted 21 lines · Alexander Graf

Quoted 21 lines

Am 08.02.2018 um 06:49 schrieb Jonathan Gray <[email protected]>:

Quoted 15 lines · Mark Kettenis

Quoted 9 lines

Date: Mon, 5 Feb 2018 21:06:59 +1100
From: Jonathan Gray <[email protected]>

Quoted 4 lines

Quoted 2 lines

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.

Quoted 4 lines

Quoted 2 lines

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 <[email protected]>
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 <[email protected]>

Signed-off-by Alexander Graf <[email protected]>

Quoted 8 lines

Quoted 5 lines

   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?

Quoted 7 lines

Quoted 5 lines

Quoted 3 lines

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.

The commit was mentioned three times in the mail but you seem to have missed that.

again e24bd1e79e223aa89854c0be95a53e2d538144a5

Quoted 7 lines

Quoted 6 lines

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

Quoted 7 lines

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?

Please read the above. A sopine_baseboard image was used on the pinebook and not by me.

Quoted 7 lines

Quoted 5 lines

While qemu_arm64 works.

Bisecting rpi_3 again, removing obj dir between runs and skipping

What do you mean by obj dir?

build directory, dir used with O= on make calls

Quoted 72 lines

Quoted 51 lines

commits where nothing shows up on serial again gives the same:

commit caf2233b281c03e3e359061a3dfa537d8a25c273

Author:     Alexander Graf <[email protected]>
AuthorDate: Tue Jan 23 18:05:21 2018 +0100
Commit:     Tom Rini <[email protected]>
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 <[email protected]>

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...

Quoted 2 lines

Quoted 1 line

Quoted 1 line

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

Quoted 4 lines

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

https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot62.fs

includes U-Boot 2018.01, raspberry pi 3 firmware files/dtb, and is suitable for dd'ing to a sd card. It is an installer image for OpenBSD/arm64.

Quoted 198 lines · Jonathan Gray

Quoted 73 lines · Heinrich Schuchardt

Quoted 72 lines · Jonathan Gray

Quoted 71 lines · Heinrich Schuchardt

Quoted 57 lines · Jonathan Gray

Quoted 56 lines · Jonathan Gray

Quoted 23 lines · Alexander Graf

Quoted 23 lines

Am 08.02.2018 um 06:49 schrieb Jonathan Gray <[email protected]>:

Quoted 17 lines · Mark Kettenis

Quoted 9 lines

Date: Mon, 5 Feb 2018 21:06:59 +1100
From: Jonathan Gray <[email protected]>

Quoted 4 lines

Quoted 2 lines

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.

Quoted 5 lines

Quoted 2 lines

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 <[email protected]>
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 <[email protected]>

Signed-off-by Alexander Graf <[email protected]>

   include/efi_loader.h      |  4 +++
   lib/efi_loader/efi_disk.c | 84
+++++++++++++++++++++++++++++++++++++++----------------

   2 files changed, 64 insertions(+), 24 deletions(-)

Quoted 5 lines

Quoted 1 line

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?

Quoted 7 lines

Quoted 5 lines

Quoted 3 lines

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.

The commit was mentioned three times in the mail but you seem to have missed that.

again e24bd1e79e223aa89854c0be95a53e2d538144a5

Quoted 7 lines

Quoted 6 lines

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

Quoted 8 lines

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?

Please read the above.  A sopine_baseboard image was used on the pinebook and not by me.

Quoted 7 lines

Quoted 5 lines

While qemu_arm64 works.

Bisecting rpi_3 again, removing obj dir between runs and skipping

What do you mean by obj dir?

build directory, dir used with O= on make calls

Quoted 82 lines

Quoted 56 lines

commits where nothing shows up on serial again gives the same:

commit caf2233b281c03e3e359061a3dfa537d8a25c273 Author:     Alexander Graf <[email protected]>
AuthorDate: Tue Jan 23 18:05:21 2018 +0100 Commit:     Tom Rini <[email protected]>
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 <[email protected]>

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...

Quoted 2 lines

Quoted 1 line

Quoted 1 line

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?

Quoted 3 lines

Quoted 1 line

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

https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot62.fs

This is an image that changes every day.

For testing we should have a stable reference. So I copied the file to
https://www.xypron.de/temp/openbsd/

Quoted 5 lines

includes U-Boot 2018.01, raspberry pi 3 firmware files/dtb, and is suitable for dd'ing to a sd card.  It is an installer image for OpenBSD/arm64.

Quoted 10 lines · Tom Rini

Quoted 8 lines · Alexander Graf

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.

Quoted 7 lines

Quoted 5 lines

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 <[email protected]>

Applied to u-boot/master, thanks!

It seems one of the recent commits here has broken booting on rpi_3 with the vendor supplied device tree via efi_loader.

last working commit seems to be:

8996975ff8422e07f43eb8b3b0c7ed8c2b35442f
powerpc: Drop CONFIG_WALNUT and other related dead code

After that were

caf2233b281c03e3e359061a3dfa537d8a25c273
bcm283x: Add pinctrl driver

c8a73a26d6dd9b7d489e66529fe1412425d8f2d1
mmc: Add bcm2835 sdhost controller

These can't easily be reverted due to other changes.

The BCM2835 family of SoCs has 2 different SD controllers: One based on the SDHCI spec and a custom, home-grown one.

This patch implements a driver for the latter based on the Linux driver. This is needed so that we can make use of device trees that assume driver presence of both SD controllers.

Signed-off-by Alexander Graf <[email protected]>