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