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 <ag...@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 m...@7e202000.blk...
> Card did not respond to voltage select!
> mmc_init: -95, time 25
> Scanning disk sd...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
