[U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver
Heinrich Schuchardt
xypron.glpk at gmx.de
Fri Feb 9 16:49:56 UTC 2018
On 02/09/2018 05:41 AM, Heinrich Schuchardt wrote:
> 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.
>>
>
>
Resolved with patch
efi_loader: correct efi_disk_register
https://lists.denx.de/pipermail/u-boot/2018-February/320035.html
Thanks for reporting the problem.
Could you, please, confirm the fix works for you.
Best regards
Heinrich
More information about the U-Boot
mailing list