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