[U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver
Heinrich Schuchardt
xypron.glpk at gmx.de
Fri Feb 9 03:43:09 UTC 2018
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 at 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 at 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 at 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 at gmx.de>
>>>> Signed-off-by: Alexander Graf <agraf at 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 at suse.de>
> AuthorDate: Tue Jan 23 18:05:21 2018 +0100
> Commit: Tom Rini <trini at 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 at 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 at 7e202000: 0, sdhci at 7e300000: 1
> Loading Environment from FAT... OK
> In: serial
> Out: vidconsole
> Err: vidconsole
> Net: No ethernet found.
> starting USB...
> USB0: Core Release: 2.80a
> scanning bus 0 for devices... 4 USB Device(s) found
> scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot: 0
>
> Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra
> Type: Removable Hard Disk
> Capacity: 29327.3 MB = 28.6 GB (60062500 x 512)
> ... is now current device
> Scanning usb 0:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> 82748 bytes read in 89 ms (907.2 KiB/s)
> ## Starting EFI application at 01000000 ...
> Scanning disk mmc at 7e202000.blk...
> Card did not respond to voltage select!
> mmc_init: -95, time 25
> Scanning disk sdhci at 7e300000.blk...
>>> 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 at ti.com>
> AuthorDate: Thu Sep 21 16:29:57 2017 +0200
> Commit: Jaehoon Chung <jh80.chung at 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 at ti.com>
> Reviewed-by: Simon Glass <sjg at 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 at gmx.de>
> AuthorDate: Fri Jan 19 20:24:47 2018 +0100
> Commit: Alexander Graf <agraf at 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 at gmx.de>
> Signed-off-by: Alexander Graf <agraf at 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 at 9000000
> Out: pl011 at 9000000
> Err: pl011 at 9000000
> Net: No ethernet found.
> Hit any key to stop autoboot: 0
> scanning bus for devices...
> Target spinup took 0 ms.
> SATA link 1 timeout.
> SATA link 2 timeout.
> SATA link 3 timeout.
> SATA link 4 timeout.
> SATA link 5 timeout.
> AHCI 0001.0000 32 slots 6 ports 1.5 Gbps 0x3f impl SATA mode
> flags: 64bit ncq only
> Device 0: (0:0) Vendor: ATA Prod.: QEMU HARDDISK Rev: 2.5+
> Type: Hard Disk
> Capacity: 4096.0 MB = 4.0 GB (8388608 x 512)
>
> Device 0: (0:0) Vendor: ATA Prod.: QEMU HARDDISK Rev: 2.5+
> Type: Hard Disk
> Capacity: 4096.0 MB = 4.0 GB (8388608 x 512)
> ... is now current device
> Scanning scsi 0:1...
> load - load binary file from a filesystem
>
> Usage:
> load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]]
> - Load binary file 'filename' from partition 'part' on device
> type 'interface' instance 'dev' to address 'addr' in memory.
> 'bytes' gives the size to load in bytes.
> If 'bytes' is 0 or omitted, the file is read until the end.
> 'pos' gives the file byte position to start reading from.
> If 'pos' is 0 or omitted, the file is read from the start.
> Found EFI removable media binary efi/boot/bootaa64.efi
> Scanning disk ahci_scsi.id0lun0...
> Found 3 disks
> 82748 bytes read in 11 ms (7.2 MiB/s)
> ## Starting EFI application at 40400000 ...
>>> OpenBSD/arm64 BOOTAA64 0.11
> boot>
> booting sd0a:/bsd: 3913300+580492+583920+806432/[279463+96+459168+244083]=0x843970
>
More information about the U-Boot
mailing list