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 <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 > > 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot