David Bauer writes:
> I have a patch for that prepared in my staging tree, I will re-test it on
> my unit. My proposed "append DTB to kernel" worked, so we have a fallback
> in case the DTB load-addr does not solve the issue.
Tried it now. Looks fine.
With
pr_info("fdt is at %px
Hi Bjorn,
On 11/7/22 13:57, Bjørn Mork wrote:
Jonas Gorski writes:
On Sun, 6 Nov 2022 at 12:50, Bjørn Mork wrote:
Jonas Gorski writes:
An option is also to set a load address for the dtb in the FIT image,
then U-Boot will relocate it before passing it to the kernel.
Yes, that is worth
Jonas Gorski writes:
> On Sun, 6 Nov 2022 at 12:50, Bjørn Mork wrote:
>> Jonas Gorski writes:
>>
>> > An option is also to set a load address for the dtb in the FIT image,
>> > then U-Boot will relocate it before passing it to the kernel.
>>
>> Yes, that is worth trying. I thought this would
On Sun, 6 Nov 2022 at 12:50, Bjørn Mork wrote:
>
> Jonas Gorski writes:
>
> > An option is also to set a load address for the dtb in the FIT image,
> > then U-Boot will relocate it before passing it to the kernel.
>
> Yes, that is worth trying. I thought this would be part of the fdt
>
Jonas Gorski writes:
> An option is also to set a load address for the dtb in the FIT image,
> then U-Boot will relocate it before passing it to the kernel.
Yes, that is worth trying. I thought this would be part of the fdt
relocation step, but I see that the "load" property is used before the
On Sat, 5 Nov 2022 at 09:46, Bjørn Mork wrote:
>
> David Bauer writes:
> > On 11/4/22 09:29, Bjørn Mork wrote:
> >> You are right that the bootloader must be fixed. But the vendor isn't
> >> likely to do that as long as they run older kernels. I believe the
> >> OpenWrt policy in such cases is
Bjørn Mork writes:
> Robert Marko writes:
>
>> What should be done is to expand mkimage with an option to align to an
>> 8-byte boundary.
>
> Definitely.
>
> However, this implies that mkimage must mangle the output of libfdt to
> align one specific property. AFAICS, there are no such
David Bauer writes:
> On 11/4/22 09:29, Bjørn Mork wrote:
>> You are right that the bootloader must be fixed. But the vendor isn't
>> likely to do that as long as they run older kernels. I believe the
>> OpenWrt policy in such cases is to try to work around the issue.
>> Replacing the vendor
Hi Bjorn,
On 11/4/22 09:29, Bjørn Mork wrote:
You are right that the bootloader must be fixed. But the vendor isn't
likely to do that as long as they run older kernels. I believe the
OpenWrt policy in such cases is to try to work around the issue.
Replacing the vendor bootloader is a last
Robert Marko writes:
> This is a broken vendor bootloader doing its thing, so we shouldn't
> revert upstream commits
> that is just enforcing the boot specification.
> This was introduced in 5.12 anyway, so most of the broken devices
> should have already surfaced.
Forgot to ack this, but I
Robert Marko writes:
> What should be done is to expand mkimage with an option to align to an
> 8-byte boundary.
Definitely.
However, this implies that mkimage must mangle the output of libfdt to
align one specific property. AFAICS, there are no such possibilities in
device tree. So the
On Thu, 3 Nov 2022 at 19:11, Christian Marangi wrote:
>
> On Thu, Nov 03, 2022 at 06:54:47PM +0100, Bjørn Mork wrote:
> > The Unifi 6 Lite U-Boot does not relocate the Device Tree Blobs
> > found in the FIT image. It behaves as if fdt_high is set to
> > 0x whether or not this variable is
On Thu, Nov 03, 2022 at 06:54:47PM +0100, Bjørn Mork wrote:
> The Unifi 6 Lite U-Boot does not relocate the Device Tree Blobs
> found in the FIT image. It behaves as if fdt_high is set to
> 0x whether or not this variable is defined.
>
> Kernel commit 79edff12060f ("scripts/dtc: Update
13 matches
Mail list logo
