Hi Matthias.
Thanks for this.
I can confirm that this fixes the reported problem. You have my Tested-By.
FWIW, the changes look fine to me too.
Cheers,
Robin
On Thu, 2020-01-09 at 15:57 +0100, Matthias Brugger wrote:
[...]
> The property expects size-cells to be two, but U-Boot will use one
> cell if no
> size-cells are defined in the device node (which is not the case) and
> therefor
> will see
>
> Bank1: Flashbase 0x0 0x0 Flashsize 0x40
Hi Matthias.
On Thu, 2020-01-09 at 12:12 +0100, Matthias Brugger wrote:
[...]
> Can you pinpoint me to where I can find the DTS used by U-boot.
As per my understanding the DTB for this virtual platform is generated
by qemu and handed to u-boot.
I dumped the DTB to the host filesystem using GDB
Hi folks.
[CC'ing some hopefully relevant folks].
As of:
commit 0ba41ce1b7816c229cc19e0621148b98f990cb68
libfdt: return correct value if #size-cells property is not present
.. accesses to the second flash bank on the qemu_arm64 virtual board
appear broken.
To demonstrate, consider that the phy
Hi Alex.
On Wed 14 Sep 08:34:47 2016, Alexander Graf wrote:
[...]
> Very nice catch!
Thanks!
[...]
> Can you please double-check that this is the only place the type
> mismatch happened?
So I skimmed through the boot and run-time service API implementations
and couldn't spot another ins
t cast to
ensure the correct outcome, irrespective of the system's native word
size.
This was observed when bootefi'ing the EFI instance of FreeBSD's first
stage bootstrap (boot1.efi) on a 32-bit ARM platform (Qemu VExpress +
Cortex-a9).
Signed-off-by: Robin Randhawa
---
lib/efi_lo
Greetings.
On Thu10 Dec 2009, at 20:29, Wierd O wrote:
> I am not sure why the kernel stops short of loading. The other thing that
> confuses me is that i couldnt know whther the proble is from the image or
> uboot.
You are assuming that the kernel 'stops short of loading'. It is quite likely
7 matches
Mail list logo