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.
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?
While qemu_arm64 works.
Bisecting rpi_3 again, removing obj dir between runs and skipping
What do you mean by obj dir?
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
Best regards
Heinrich
boot>
booting tftp0a:/bsd: open tftp0a:/bsd: Operation not permitted
failed(1). will try /bsd
with vexpress_ca15_tc2, bisects to
commit d0c221fe7336fc7d9ada57d96f4a8911a3aac041
Author: Jean-Jacques Hiblot <jjhib...@ti.com>
AuthorDate: Thu Sep 21 16:29:57 2017 +0200
Commit: Jaehoon Chung <jh80.ch...@samsung.com>
CommitDate: Fri Jan 12 18:11:04 2018 +0900
mmc: refactor SD startup to make it easier to support new modes
The SDcard startup process currently handles only 2 modes. To make it
easier to add support for more modes, let's make the process more generic
and use a list of the modes to try.
The major functional change is that when a mode fails we try the next one.
Not all modes are tried, only those supported by the card and the host.
Signed-off-by: Jean-Jacques Hiblot <jjhib...@ti.com>
Reviewed-by: Simon Glass <s...@chromium.org>
with master as of e24bd1e79e223aa89854c0be95a53e2d538144a5
U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 09 2018 - 11:31:54 +1300)
DRAM: 1 GiB
WARNING: Caches not enabled
Flash: 128 MiB
MMC: MMC: 0
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
Net: smc911x-0
Hit any key to stop autoboot: 0
=> load mmc 0:1 ${ramdisk_addr} fdt.dtb
unable to select a mode
mmc_init: -524, time 23
unable to select a mode
mmc_init: -524, time 22
** Bad device mmc 0 **
=> load mmc 0:1 ${loadaddr} efi/boot/bootarm.efi
unable to select a mode
mmc_init: -524, time 21
unable to select a mode
mmc_init: -524, time 21
** Bad device mmc 0 **
=> bootefi ${loadaddr} ${ramdisk_addr}
## Starting EFI application at a0008000 ...
WARNING: using memory device/image path, this may confuse some payloads!
Scanning disks on mmc...
unable to select a mode
mmc_init: -524, time 21
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 0 disks
WARNING: Invalid device tree, expect boot to fail
efi_load_pe: Invalid DOS Signature
with mx6cuboxi, bisects to
commit 64e4db0f119151a1345e1da19d152eda550394e7
Author: Heinrich Schuchardt <xypron.g...@gmx.de>
AuthorDate: Fri Jan 19 20:24:47 2018 +0100
Commit: Alexander Graf <ag...@suse.de>
CommitDate: Mon Jan 22 23:09:14 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>
with master as of e24bd1e79e223aa89854c0be95a53e2d538144a5
U-Boot SPL 2018.03-rc1-00185-g1e19c70639 (Feb 09 2018 - 11:43:18 +1300)
Trying to boot from MMC1
U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 09 2018 - 11:43:18 +1300)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU: Extended Commercial temperature grade (-20C to 105C) at 24C
Reset cause: POR
Board: MX6 Cubox-i
DRAM: 2 GiB
MMC: FSL_SDHC: 0
Loading Environment from MMC... OK
No panel detected: default to HDMI
Display: HDMI (1024x768)
In: serial
Out: serial
Err: serial
Net: FEC
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
37503 bytes read in 17 ms (2.1 MiB/s)
Found EFI removable media binary efi/boot/bootarm.efi
Scanning disks on usb...
76528 bytes read in 31 ms (2.4 MiB/s)
## Starting EFI application at 12000000 ...
BS->LocateHandle() returns -2147483634
undefined instruction
pc : [<8e560348>] lr : [<8e56444c>]
reloc pc : [<15de4348>] lr : [<15de844c>]
sp : 8f57af10 ip : 8ffc2474 fp : 8f57af1c
r10: 0000b000 r9 : 8f57bee0 r8 : 0000000b
r7 : 8ffa1a9d r6 : 8ffa16ad r5 : 8e56f0d0 r4 : 8e56e88a
r3 : 8e56dac8 r2 : 00000001 r1 : 00000000 r0 : 00000000
Flags: nZCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
resetting ...
(undefined instruction is used to reset as efi reset was not
present in earlier U-Boot versions)
qemu_arm64 with master as of e24bd1e79e223aa89854c0be95a53e2d538144a5
U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 09 2018 - 12:21:06 +1300)
DRAM: 2 GiB
In: pl011@9000000
Out: pl011@9000000
Err: pl011@9000000
Net: No ethernet found.
Hit any key to stop autoboot: 0
scanning bus for devices...
Target spinup took 0 ms.
SATA link 1 timeout.
SATA link 2 timeout.
SATA link 3 timeout.
SATA link 4 timeout.
SATA link 5 timeout.
AHCI 0001.0000 32 slots 6 ports 1.5 Gbps 0x3f impl SATA mode
flags: 64bit ncq only
Device 0: (0:0) Vendor: ATA Prod.: QEMU HARDDISK Rev: 2.5+
Type: Hard Disk
Capacity: 4096.0 MB = 4.0 GB (8388608 x 512)
Device 0: (0:0) Vendor: ATA Prod.: QEMU HARDDISK Rev: 2.5+
Type: Hard Disk
Capacity: 4096.0 MB = 4.0 GB (8388608 x 512)
... is now current device
Scanning scsi 0:1...
load - load binary file from a filesystem
Usage:
load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]]
- Load binary file 'filename' from partition 'part' on device
type 'interface' instance 'dev' to address 'addr' in memory.
'bytes' gives the size to load in bytes.
If 'bytes' is 0 or omitted, the file is read until the end.
'pos' gives the file byte position to start reading from.
If 'pos' is 0 or omitted, the file is read from the start.
Found EFI removable media binary efi/boot/bootaa64.efi
Scanning disk ahci_scsi.id0lun0...
Found 3 disks
82748 bytes read in 11 ms (7.2 MiB/s)
## Starting EFI application at 40400000 ...
OpenBSD/arm64 BOOTAA64 0.11
boot>
booting sd0a:/bsd:
3913300+580492+583920+806432/[279463+96+459168+244083]=0x843970
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
