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

Fri Feb 9 04:12:50 UTC 2018

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

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.