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

Fri Feb 9 04:41:46 UTC 2018

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