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

Mon Feb 5 08:37:15 UTC 2018

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 at 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 at 7e202000: 0, sdhci at 7e300000: 1
> Loading Environment from FAT... OK
> In:    serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   No ethernet found.
> starting USB...
> USB0:	Core Release: 2.80a
> scanning bus 0 for devices... 4 USB Device(s) found
>        scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot:  0
> U-Boot> printenv
> arch=arm
> baudrate=115200
> board=rpi
> board_name=3 Model B
> board_rev=0x8
> board_rev_scheme=1
> board_revision=0xA02082
> boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
> boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
> boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf
> boot_net_usb_start=usb start
> boot_prefixes=/ /boot/
> boot_script_dhcp=boot.scr.uimg
> boot_scripts=boot.scr.uimg boot.scr
> boot_targets=usb0 mmc0 pxe dhcp
> bootcmd=run distro_bootcmd
> bootcmd_dhcp=run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00011:UNDI:003000;setenv bootp_arch 0xb;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci;
> bootcmd_mmc0=setenv devnum 0; run mmc_boot
> bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi
> bootcmd_usb0=setenv devnum 0; run usb_boot
> bootdelay=2
> bootfstype=fat
> cpu=armv8
> devnum=0
> devplist=1
> devtype=usb
> dhcpuboot=usb start; dhcp u-boot.uimg; bootm
> distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
> efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported={ro,boot}(blob)0000000000000000
> efi_dtb_prefixes=/ /dtb/ /dtb/current/
> efi_fdtfile=broadcom/bcm2837-rpi-3-b.dtb
> ethaddr=b8:27:eb:18:54:ea
> fdt_addr=100
> fdt_addr_r=0x00000100
> fdt_high=ffffffff
> fdtaddr=100
> fdtcontroladdr=3b3a3960
> fdtfile=broadcom/bcm2837-rpi-3-b.dtb
> fileaddr=1000000
> filesize=1346f
> initrd_high=ffffffff
> kernel_addr_r=0x01000000
> load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
> loadaddr=0x00200000
> mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi
> preboot=usb start
> pxefile_addr_r=0x00100000
> ramdisk_addr_r=0x02100000
> scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
> scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done
> scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootaa64.efi; then echo Found EFI removable media binary efi/boot/bootaa64.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile
> scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
> scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
> scriptaddr=0x02000000
> serial#=00000000eb1854ea
> soc=bcm283x
> stderr=serial,vidconsole
> stdin=serial,usbkbd
> stdout=serial,vidconsole
> usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run scan_dev_for_boot_part; fi
> usbethaddr=b8:27:eb:18:54:ea
> vendor=raspberrypi
> 
> Environment size: 4081/16380 bytes
> U-Boot> boot
> 
> Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra
> 	    Type: Removable Hard Disk
> 	    Capacity: 29327.3 MB = 28.6 GB (60062500 x 512)
> ... is now current device
> Scanning usb 0:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> 78335 bytes read in 79 ms (967.8 KiB/s)
> ## Starting EFI application at 01000000 ...
> Scanning disk mmc at 7e202000.blk...
> Card did not respond to voltage select!
> mmc_init: -95, time 25
> Scanning disk sdhci at 7e300000.blk...
>>> 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