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

Message ID	20180123170522.6581-2-agraf@suse.de
State	Accepted
Commit	caf2233b281c03e3e359061a3dfa537d8a25c273
Headers	show Delivered-To: patch@linaro.org Received-SPF: pass (google.com: best guess record for domain of u-boot-bounces@lists.denx.de designates 81.169.180.215 as permitted sender) client-ip=81.169.180.215; From: Alexander Graf <agraf@suse.de> To: u-boot@lists.denx.de Date: Tue, 23 Jan 2018 18:05:21 +0100 Message-Id: <20180123170522.6581-2-agraf@suse.de> In-Reply-To: <20180123170522.6581-1-agraf@suse.de> References: <20180123170522.6581-1-agraf@suse.de> Subject: [U-Boot] [PATCH v3 1/2] bcm283x: Add pinctrl driver Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" <u-boot-bounces@lists.denx.de>
Series	Rpi: Add support for second sd host controller \| expand [v3,0/2] Rpi: Add support for second sd host controller [v3,1/2] bcm283x: Add pinctrl driver [v3,2/2] mmc: Add bcm2835 sdhost controller

Alexander Graf Jan. 23, 2018, 5:05 p.m. UTC

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@suse.de>

---

v2 -> v3:

  - use dev_read
  - add comment on why GPIO failure is non-fatal
---
 MAINTAINERS                                |   1 +
 arch/arm/mach-bcm283x/include/mach/gpio.h  |   2 -
 board/raspberrypi/rpi/rpi.c                |   5 +-
 configs/rpi_0_w_defconfig                  |   4 +
 configs/rpi_2_defconfig                    |   4 +
 configs/rpi_3_32b_defconfig                |   4 +
 configs/rpi_3_defconfig                    |   4 +
 configs/rpi_defconfig                      |   4 +
 drivers/gpio/bcm2835_gpio.c                |  29 ++----
 drivers/pinctrl/Kconfig                    |   1 +
 drivers/pinctrl/Makefile                   |   1 +
 drivers/pinctrl/broadcom/Kconfig           |   7 ++
 drivers/pinctrl/broadcom/Makefile          |   7 ++
 drivers/pinctrl/broadcom/pinctrl-bcm283x.c | 152 +++++++++++++++++++++++++++++
 14 files changed, 202 insertions(+), 23 deletions(-)
 create mode 100644 drivers/pinctrl/broadcom/Kconfig
 create mode 100644 drivers/pinctrl/broadcom/Makefile
 create mode 100644 drivers/pinctrl/broadcom/pinctrl-bcm283x.c

Tom Rini Jan. 28, 2018, 6:54 p.m. UTC | #1

On Tue, Jan 23, 2018 at 06:05:21PM +0100, Alexander Graf wrote:

> 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@suse.de>


Applied to u-boot/master, thanks!

-- 
Tom

Jonathan Gray Feb. 3, 2018, 1:47 a.m. UTC | #2

On Sun, Jan 28, 2018 at 01:54:25PM -0500, Tom Rini wrote:
> On Tue, Jan 23, 2018 at 06:05:21PM +0100, Alexander Graf wrote:
> 
> > 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@suse.de>
> 
> 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.

Alexander Graf Feb. 3, 2018, 8:02 a.m. UTC | #3

On 03.02.18 02:47, Jonathan Gray wrote:
> On Sun, Jan 28, 2018 at 01:54:25PM -0500, Tom Rini wrote:
>> On Tue, Jan 23, 2018 at 06:05:21PM +0100, Alexander Graf wrote:
>>
>>> 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@suse.de>
>>
>> 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

Jonathan Gray Feb. 3, 2018, 11:38 a.m. UTC | #4

On Sat, Feb 03, 2018 at 09:02:25AM +0100, Alexander Graf wrote:
> 
> 
> On 03.02.18 02:47, Jonathan Gray wrote:
> > On Sun, Jan 28, 2018 at 01:54:25PM -0500, Tom Rini wrote:
> >> On Tue, Jan 23, 2018 at 06:05:21PM +0100, Alexander Graf wrote:
> >>
> >>> 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@suse.de>
> >>
> >> 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

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@7e202000: 0, sdhci@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@7e202000.blk...
Card did not respond to voltage select!
mmc_init: -95, time 25
Scanning disk sdhci@7e300000.blk...
>> 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 /
    50248   bootcode.bin
  2820196   start.elf
     6551   fixup.dat
    17794   bcm2710-rpi-3-b.dtb
    16380   bcm2710-rpi-cm3.dtb
   441248   u-boot.bin
            efi/
       76   config.txt
    16384   uboot.env

8 file(s), 1 dir(s)
U-Boot> bdinfo
arch_number = 0x00000000
boot_params = 0x00000100
DRAM bank   = 0x00000000
-> start    = 0x00000000
-> size     = 0x3B400000
baudrate    = 115200 bps
TLB addr    = 0x3B3F0000
relocaddr   = 0x3B349000
reloc off   = 0x3B2C9000
irq_sp      = 0x3AF44DE0
sp start    = 0x3AF44DE0
Early malloc usage: 5d0 / 2000
fdt_blob = 000000003b3a3960

U-Boot> dm tree
 Class	    Probed  Driver	Name
----------------------------------------
 root	    [ + ]   root_drive	root_driver
 simple_bus [ + ]   generic_si	|-- soc
 pinctrl    [ + ]   bcm283x_pi	|   |-- gpio@7e200000
 pinconfig  [	]   pinconfig	|   |	|-- dpi_gpio0
 pinconfig  [	]   pinconfig	|   |	|-- emmc_gpio22
 pinconfig  [ + ]   pinconfig	|   |	|-- emmc_gpio34
 pinconfig  [	]   pinconfig	|   |	|-- emmc_gpio48
 pinconfig  [	]   pinconfig	|   |	|-- gpclk0_gpio4
 pinconfig  [	]   pinconfig	|   |	|-- gpclk1_gpio5
 pinconfig  [	]   pinconfig	|   |	|-- gpclk1_gpio42
 pinconfig  [	]   pinconfig	|   |	|-- gpclk1_gpio44
 pinconfig  [	]   pinconfig	|   |	|-- gpclk2_gpio6
 pinconfig  [ + ]   pinconfig	|   |	|-- gpclk2_gpio43
 pinconfig  [	]   pinconfig	|   |	|-- i2c0_gpio0
 pinconfig  [	]   pinconfig	|   |	|-- i2c0_gpio28
 pinconfig  [	]   pinconfig	|   |	|-- i2c0_gpio44
 pinconfig  [	]   pinconfig	|   |	|-- i2c1_gpio2
 pinconfig  [	]   pinconfig	|   |	|-- i2c1_gpio44
 pinconfig  [	]   pinconfig	|   |	|-- i2c_slave_gpio18
 pinconfig  [	]   pinconfig	|   |	|-- jtag_gpio4
 pinconfig  [	]   pinconfig	|   |	|-- jtag_gpio22
 pinconfig  [	]   pinconfig	|   |	|-- pcm_gpio18
 pinconfig  [	]   pinconfig	|   |	|-- pcm_gpio28
 pinconfig  [	]   pinconfig	|   |	|-- pwm0_gpio12
 pinconfig  [	]   pinconfig	|   |	|-- pwm0_gpio18
 pinconfig  [	]   pinconfig	|   |	|-- pwm0_gpio40
 pinconfig  [	]   pinconfig	|   |	|-- pwm1_gpio13
 pinconfig  [	]   pinconfig	|   |	|-- pwm1_gpio19
 pinconfig  [	]   pinconfig	|   |	|-- pwm1_gpio41
 pinconfig  [	]   pinconfig	|   |	|-- pwm1_gpio45
 pinconfig  [ + ]   pinconfig	|   |	|-- sdhost_gpio48
 pinconfig  [	]   pinconfig	|   |	|-- spi0_gpio7
 pinconfig  [	]   pinconfig	|   |	|-- spi0_gpio35
 pinconfig  [	]   pinconfig	|   |	|-- spi1_gpio16
 pinconfig  [	]   pinconfig	|   |	|-- spi2_gpio40
 pinconfig  [	]   pinconfig	|   |	|-- uart0_gpio14
 pinconfig  [	]   pinconfig	|   |	|-- uart0_ctsrts_gpio16
 pinconfig  [	]   pinconfig	|   |	|-- uart0_ctsrts_gpio30
 pinconfig  [ + ]   pinconfig	|   |	|-- uart0_gpio32
 pinconfig  [	]   pinconfig	|   |	|-- uart0_gpio36
 pinconfig  [	]   pinconfig	|   |	|-- uart0_ctsrts_gpio38
 pinconfig  [ + ]   pinconfig	|   |	|-- uart1_gpio14
 pinconfig  [	]   pinconfig	|   |	|-- uart1_ctsrts_gpio16
 pinconfig  [	]   pinconfig	|   |	|-- uart1_gpio32
 pinconfig  [	]   pinconfig	|   |	|-- uart1_ctsrts_gpio30
 pinconfig  [	]   pinconfig	|   |	|-- uart1_gpio40
 pinconfig  [	]   pinconfig	|   |	|-- uart1_ctsrts_gpio42
 pinconfig  [	]   pinconfig	|   |	|-- gpioout
 pinconfig  [	]   pinconfig	|   |	|-- alt0
 gpio	    [	]   gpio_bcm28	|   |	`-- gpio_bcm2835
 serial	    [	]   bcm283x_pl	|   |-- serial@7e201000
 mmc	    [ + ]   bcm2835-sd	|   |-- mmc@7e202000
 blk	    [ + ]   mmc_blk	|   |	`-- mmc@7e202000.blk
 serial	    [ + ]   serial_bcm	|   |-- serial@7e215040
 mmc	    [ + ]   sdhci-bcm2	|   |-- sdhci@7e300000
 blk	    [	]   mmc_blk	|   |	`-- sdhci@7e300000.blk
 video	    [ + ]   bcm2835_vi	|   |-- hdmi@7e902000
 vidconsole [ + ]   vidconsole	|   |	`-- hdmi@7e902000.vidconsole0
 usb	    [ + ]   dwc2_usb	|   `-- usb@7e980000
 usb_hub    [ + ]   usb_hub	|	`-- usb_hub
 usb_hub    [ + ]   usb_hub	|	    `-- usb_hub
 eth	    [ + ]   smsc95xx_e	|		|-- smsc95xx_eth
 usb_mass_s [ + ]   usb_mass_s	|		`-- usb_mass_storage
 blk	    [ + ]   usb_storag	|		    `-- usb_mass_storage.lun0
 simple_bus [	]   generic_si	`-- clocks

Alexander Graf Feb. 5, 2018, 8:37 a.m. UTC | #5

On 03.02.18 12:38, Jonathan Gray wrote:
> On Sat, Feb 03, 2018 at 09:02:25AM +0100, Alexander Graf wrote:
>>
>>
>> On 03.02.18 02:47, Jonathan Gray wrote:
>>> On Sun, Jan 28, 2018 at 01:54:25PM -0500, Tom Rini wrote:
>>>> On Tue, Jan 23, 2018 at 06:05:21PM +0100, Alexander Graf wrote:
>>>>
>>>>> 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@suse.de>
>>>>
>>>> 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
> 
> 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:

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

> 
> U-Boot 2018.03-rc1-00058-g36d3bd9514 (Feb 03 2018 - 22:13:26 +1100)
> 
> DRAM:  948 MiB
> RPI 3 Model B (0xa02082)
> MMC:   mmc@7e202000: 0, sdhci@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@7e202000.blk...
> Card did not respond to voltage select!
> mmc_init: -95, time 25
> Scanning disk sdhci@7e300000.blk...
>>> 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?

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

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

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


Alex

Jonathan Gray Feb. 5, 2018, 10:06 a.m. UTC | #6

On Mon, Feb 05, 2018 at 09:37:15AM +0100, Alexander Graf wrote:
> 
> 
> On 03.02.18 12:38, Jonathan Gray wrote:
> > On Sat, Feb 03, 2018 at 09:02:25AM +0100, Alexander Graf wrote:
> >>
> >>
> >> On 03.02.18 02:47, Jonathan Gray wrote:
> >>> On Sun, Jan 28, 2018 at 01:54:25PM -0500, Tom Rini wrote:
> >>>> On Tue, Jan 23, 2018 at 06:05:21PM +0100, Alexander Graf wrote:
> >>>>
> >>>>> 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@suse.de>
> >>>>
> >>>> 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
> > 
> > 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:
> 
> Are you using the defconfig or do you set CONFIG_OF_BOARD to fetch the
> U-Boot DT from firmware?

defconfig with no changes

> 
> > 
> > U-Boot 2018.03-rc1-00058-g36d3bd9514 (Feb 03 2018 - 22:13:26 +1100)
> > 
> > DRAM:  948 MiB
> > RPI 3 Model B (0xa02082)
> > MMC:   mmc@7e202000: 0, sdhci@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@7e202000.blk...
> > Card did not respond to voltage select!
> > mmc_init: -95, time 25
> > Scanning disk sdhci@7e300000.blk...
> >>> 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?

I suspect it means the boot device path has an issue again.

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

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

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.

> 
> > 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 /
> 
> 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)

Mark Kettenis Feb. 5, 2018, 10:31 a.m. UTC | #7

> Date: Mon, 5 Feb 2018 21:06:59 +1100
> From: Jonathan Gray <jsg@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.

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

Right.  So what the bootloader calls sd0 above is really the usb disk.

> > > 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 /
> > 
> > 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@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>

Jonathan Gray Feb. 8, 2018, 5:49 a.m. UTC | #8

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@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:

$ qemu-system-arm -m 1024 -nographic -M vexpress-a15 -dtb /usr/local/share/dtb/arm/vexpress-v2p-ca15-tc1.dtb -kernel /usr/local/share/u-boot/vexpress_ca15_tc2/u-boot -sd /tmp/miniroot-am335x-62.fs
WARNING: Image format was not specified for '/tmp/miniroot-am335x-62.fs' and probing guessed raw.
	 Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
	 Specify the 'raw' format explicitly to remove the restrictions.


U-Boot 2018.01 (Feb 06 2018 - 23:26:43 -0700)

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
reading fdt.dtb
13384 bytes read in 2153 ms (5.9 KiB/s)
=> load mmc 0:1 ${loadaddr} efi/boot/bootarm.efi
reading efi/boot/bootarm.efi
76528 bytes read in 51 ms (1.4 MiB/s)
=> bootefi ${loadaddr} ${ramdisk_addr}
## Starting EFI application at a0008000 ...
Scanning disks on mmc...
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 3 disks
WARNING: Invalid device tree, expect boot to fail
>> OpenBSD/armv7 BOOTARM 1.0
boot>
cannot open sd0a:/etc/random.seed: No such file or directory
booting sd0a:/bsd: 2648671+8030940+445060 [168774+90+179792+153619]=0xb1812c

$ qemu-system-arm -m 1024 -nographic -M vexpress-a15 -dtb /usr/local/share/dtb/arm/vexpress-v2p-ca15-tc1.dtb -kernel vexpress_ca15_tc2/u-boot -sd /tmp/miniroot-am335x-62.fs
WARNING: Image format was not specified for '/tmp/miniroot-am335x-62.fs' and probing guessed raw.
	 Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
	 Specify the 'raw' format explicitly to remove the restrictions.


U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 08 2018 - 18:24:11 +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 22
unable to select a mode
mmc_init: -524, time 21
** 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
## Application terminated, r = 2147483646

U-Boot SPL 2018.01 (Feb 06 2018 - 23:13:29)
Trying to boot from MMC1


U-Boot 2018.01 (Feb 06 2018 - 23:13:29 -0700)

CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 54C
Reset cause: WDOG
Board: MX6 Cubox-i
DRAM:  2 GiB
MMC:   FSL_SDHC: 0
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...
reading /imx6q-cubox-i.dtb
37503 bytes read in 19 ms (1.9 MiB/s)
Found EFI removable media binary efi/boot/bootarm.efi
Scanning disks on usb...
Scanning disks on mmc...
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Scanning disks on sata...
Found 8 disks
reading efi/boot/bootarm.efi
76528 bytes read in 32 ms (2.3 MiB/s)
## Starting EFI application at 12000000 ...
>> OpenBSD/armv7 BOOTARM 1.0
boot>
booting sd0a:/bsd: 4531856+203028+560156\[277405+90+281904+244582]=0x5d6b88


U-Boot SPL 2018.03-rc1-00185-g1e19c70639 (Feb 08 2018 - 17:54:19 +1300)
Trying to boot from MMC1


U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 08 2018 - 17:54:19 +1300)

CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 53C
Reset cause: WDOG
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 30 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 ...

Alexander Graf Feb. 8, 2018, 8:11 a.m. UTC | #9

> Am 08.02.2018 um 06:49 schrieb Jonathan Gray <jsg@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@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?

Alex

Jonathan Gray Feb. 8, 2018, 9:10 a.m. UTC | #10

On Thu, Feb 08, 2018 at 09:11:20AM +0100, Alexander Graf wrote:
> 
> 
> > Am 08.02.2018 um 06:49 schrieb Jonathan Gray <jsg@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@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@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@gmx.de>
    Signed-off-by: Alexander Graf <agraf@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.

Jonathan Gray Feb. 8, 2018, 9:49 a.m. UTC | #11

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@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@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@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@gmx.de>
>     Signed-off-by: Alexander Graf <agraf@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.

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@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@7e300000.blk...
unhandled parent class: sdhci@7e300000.blk (13)
unhandled parent class: sdhci@7e300000.blk (13)
unhandled parent class: sdhci@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

Heinrich Schuchardt Feb. 8, 2018, 2:44 p.m. UTC | #12

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@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@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@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@gmx.de>
>>     Signed-off-by: Alexander Graf <agraf@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@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@7e300000.blk...
> unhandled parent class: sdhci@7e300000.blk (13)
> unhandled parent class: sdhci@7e300000.blk (13)
> unhandled parent class: sdhci@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
>

Jonathan Gray Feb. 8, 2018, 11:55 p.m. UTC | #13

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@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@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@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@gmx.de>
> >>     Signed-off-by: Alexander Graf <agraf@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@suse.de>
AuthorDate: Tue Jan 23 18:05:21 2018 +0100
Commit:     Tom Rini <trini@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@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@7e202000: 0, sdhci@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@7e202000.blk...
Card did not respond to voltage select!
mmc_init: -95, time 25
Scanning disk sdhci@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@ti.com>
AuthorDate: Thu Sep 21 16:29:57 2017 +0200
Commit:     Jaehoon Chung <jh80.chung@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@ti.com>
    Reviewed-by: Simon Glass <sjg@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@gmx.de>
AuthorDate: Fri Jan 19 20:24:47 2018 +0100
Commit:     Alexander Graf <agraf@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@gmx.de>
    Signed-off-by: Alexander Graf <agraf@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@9000000
Out:   pl011@9000000
Err:   pl011@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

Heinrich Schuchardt Feb. 9, 2018, 3:43 a.m. UTC | #14

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@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@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@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@gmx.de>
>>>>      Signed-off-by: Alexander Graf <agraf@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@suse.de>
> AuthorDate: Tue Jan 23 18:05:21 2018 +0100
> Commit:     Tom Rini <trini@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@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@7e202000: 0, sdhci@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@7e202000.blk...
> Card did not respond to voltage select!
> mmc_init: -95, time 25
> Scanning disk sdhci@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@ti.com>
> AuthorDate: Thu Sep 21 16:29:57 2017 +0200
> Commit:     Jaehoon Chung <jh80.chung@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@ti.com>
>      Reviewed-by: Simon Glass <sjg@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@gmx.de>
> AuthorDate: Fri Jan 19 20:24:47 2018 +0100
> Commit:     Alexander Graf <agraf@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@gmx.de>
>      Signed-off-by: Alexander Graf <agraf@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@9000000
> Out:   pl011@9000000
> Err:   pl011@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
>

Jonathan Gray Feb. 9, 2018, 4:12 a.m. UTC | #15

On Fri, Feb 09, 2018 at 04:43:09AM +0100, Heinrich Schuchardt wrote:
> 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@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@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@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@gmx.de>
> > > > >      Signed-off-by: Alexander Graf <agraf@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.

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

again e24bd1e79e223aa89854c0be95a53e2d538144a5

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

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

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

> 
> > commits where nothing shows up on serial again gives the same:
> > 
> > commit caf2233b281c03e3e359061a3dfa537d8a25c273
> > Author:     Alexander Graf <agraf@suse.de>
> > AuthorDate: Tue Jan 23 18:05:21 2018 +0100
> > Commit:     Tom Rini <trini@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@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@7e202000: 0, sdhci@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@7e202000.blk...
> > Card did not respond to voltage select!
> > mmc_init: -95, time 25
> > Scanning disk sdhci@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

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.

Heinrich Schuchardt Feb. 9, 2018, 4:41 a.m. UTC | #16

On 02/09/2018 05:12 AM, Jonathan Gray wrote:
> On Fri, Feb 09, 2018 at 04:43:09AM +0100, Heinrich Schuchardt wrote:
>> 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@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@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@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@gmx.de>
>>>>>>       Signed-off-by: Alexander Graf <agraf@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.
> 
> The commit was mentioned three times in the mail but you seem
> to have missed that.
> 
> again e24bd1e79e223aa89854c0be95a53e2d538144a5
> 
>>
>>>
>>> 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?
> 
> Please read the above.  A sopine_baseboard image was used on the pinebook
> and not by me.
> 
>>
>>>
>>> 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
> 
>>
>>> commits where nothing shows up on serial again gives the same:
>>>
>>> commit caf2233b281c03e3e359061a3dfa537d8a25c273
>>> Author:     Alexander Graf <agraf@suse.de>
>>> AuthorDate: Tue Jan 23 18:05:21 2018 +0100
>>> Commit:     Tom Rini <trini@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@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@7e202000: 0, sdhci@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@7e202000.blk...
>>> Card did not respond to voltage select!
>>> mmc_init: -95, time 25
>>> Scanning disk sdhci@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
> 
> 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/

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

Heinrich Schuchardt Feb. 9, 2018, 4:49 p.m. UTC | #17

On 02/09/2018 05:41 AM, Heinrich Schuchardt wrote:
> On 02/09/2018 05:12 AM, Jonathan Gray wrote:
>> On Fri, Feb 09, 2018 at 04:43:09AM +0100, Heinrich Schuchardt wrote:
>>> 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@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@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@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@gmx.de>
>>>>>>>       Signed-off-by: Alexander Graf <agraf@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.
>>
>> The commit was mentioned three times in the mail but you seem
>> to have missed that.
>>
>> again e24bd1e79e223aa89854c0be95a53e2d538144a5
>>
>>>
>>>>
>>>> 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?
>>
>> Please read the above.  A sopine_baseboard image was used on the pinebook
>> and not by me.
>>
>>>
>>>>
>>>> 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
>>
>>>
>>>> commits where nothing shows up on serial again gives the same:
>>>>
>>>> commit caf2233b281c03e3e359061a3dfa537d8a25c273
>>>> Author:     Alexander Graf <agraf@suse.de>
>>>> AuthorDate: Tue Jan 23 18:05:21 2018 +0100
>>>> Commit:     Tom Rini <trini@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@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@7e202000: 0, sdhci@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@7e202000.blk...
>>>> Card did not respond to voltage select!
>>>> mmc_init: -95, time 25
>>>> Scanning disk sdhci@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
>>
>> 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/
> 
>>
>> 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.
>>
> 
> 

Resolved with patch
efi_loader: correct efi_disk_register
https://lists.denx.de/pipermail/u-boot/2018-February/320035.html

Thanks for reporting the problem.
Could you, please, confirm the fix works for you.

Best regards

Heinrich

Jonathan Gray Feb. 9, 2018, 11:02 p.m. UTC | #18

On Sat, Feb 03, 2018 at 12:47:48PM +1100, Jonathan Gray wrote:
> On Sun, Jan 28, 2018 at 01:54:25PM -0500, Tom Rini wrote:
> > On Tue, Jan 23, 2018 at 06:05:21PM +0100, Alexander Graf wrote:
> > 
> > > 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@suse.de>
> > 
> > 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.

This turns out to have been efi loader changes, and is resolved
by 'efi_loader: correct efi_disk_register'
https://lists.denx.de/pipermail/u-boot/2018-February/320043.html

Still not clear on why git bisect kept pointing at these pinctrl changes
on rpi_3.

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

Commit Message

Comments

Patch