[yocto] [meta-raspberrypi][PATCH v3] u-boot: Simplify boot script

[Paul Barker]

On Thu, 10 Nov 2016 12:57:02 +1100
Jonathan Liu <net147 at gmail.com> wrote:

> Hi Paul,
> 
> On 6 November 2016 at 22:57, Paul Barker <paul at paulbarker.me.uk> wrote:
> > On Sat,  5 Nov 2016 12:50:07 +1100
> > Jonathan Liu <net147 at gmail.com> wrote:
> >
> >> A patch is added to check if the firmware loaded a device tree blob
> >> into memory and set the fdt_addr_r variable if it is found. The U-Boot
> >> script will then read the command line arguments generated by the
> >> firmware from the device tree and boot the kernel with the command
> >> line arguments and the loaded device tree.
> >>
> >> This allows things like MAC address, board revision and serial number
> >> to be correctly configured and options in config.txt to be used.
> >>
> >> Signed-off-by: Jonathan Liu <net147 at gmail.com>
> >> ---
> >> Changes in v3:
> >>  - Removed incorrect check if fdt_addr_r is already set. The check
> >>    condition was inverted and fdt_addr_r variable is always set to
> >>    0x100 by default.
> >> Changes in v2:
> >>  - Instead of setting device_tree_address to 0x100 in config.txt, patch
> >>    U-Boot to detect the device tree blob address if it was loaded.
> >>
> >
> > I'm still getting the same "Could not find a valid device tree" failure
> > on the model B+.
> >
> > I've tried running vcdbg but got the following error from the kernel
> >
> >     vc_mem_mmap: length 4096 is too big
> >
> > vcdbg itself then said:
> >
> >     debug_sym: AccessVideoCoreMemory: mmap failed: Invalid argument(22)
> >     debug_sym: OpenVideoCoreMemoryFileWithOffset: ReadVideoCoreMemory @VC_SYMBOL_BASE_OFFSET (0x00002800) failed
> >
> >     Unable to open videocore memory access: -5
> >
> > This was after adding "dtdebug=on" to config.txt
> >
> > Not sure where to go next with this. I might need to go off on a Yak
> > shaving mission and find out why the mmap is failing.
> 
> A patch is being worked on upstream - https://patchwork.ozlabs.org/patch/692412/
> I think we will wait until it is accepted upstream and then backport it.
> 

Ok that makes sense. I'm happy to test that out once it's ready for
backport.

Thanks,
Paul