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@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@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@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@gmx.de> Signed-off-by: Alexander Graf <agraf@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@suse.de AuthorDate: Tue Jan 23 18:05:21 2018 +0100 Commit: Tom Rini trini@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@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@7e202000: 0, sdhci@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@7e202000.blk... Card did not respond to voltage select! mmc_init: -95, time 25 Scanning disk sdhci@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.