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 <j...@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 <j...@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.g...@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.g...@gmx.de> > > > > > Signed-off-by: Alexander Graf <ag...@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 <ag...@suse.de> > > AuthorDate: Tue Jan 23 18:05:21 2018 +0100 > > Commit: Tom Rini <tr...@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 <ag...@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 m...@7e202000.blk... > > Card did not respond to voltage select! > > mmc_init: -95, time 25 > > Scanning disk sd...@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot