From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Lepore <ian@FreeBSD.org>
Date: Wed, 07 May 2014 08:15:20 -0600
Subject: [U-Boot] Latest u-boot release on BeagleBone Black for FreeBSD
In-Reply-To: <536995CF.4060404@gmail.com>
References: <5343B8B9.6040607@gmail.com> <1399203211.1994.25.camel@yellow>
	<536995CF.4060404@gmail.com>
Message-ID: <1399472120.22079.292.camel@revolution.hippie.lan>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Wed, 2014-05-07 at 10:09 +0800, Xuebing Wang wrote:
> On 05/04/2014 07:33 PM, Jeroen Hofstee wrote:
> > Hello Xuebing, (freebsd-arm added on cc),
> >
> > On di, 2014-04-08 at 16:52 +0800, Xuebing Wang wrote:
> >> Hi u-boot community,
> >>
> >> I am trying to port u-boot (release u-boot-2014.04-rc3.tar.bz2) to
> >> FreeBSD on BeagleBone Black.
> >>
> >> In FreeBSD, there is a u-boot loader (named ubldr), which can call
> >> u-boot API to get fdt (Flat Device Tree) data.
> >>
> >> I have to comment out below 3 lines, in order to get correct fdt data in
> >> FreeBSD ubldr from u-boot. Would you please advice what is the best way
> >> to fix this?
> >>
> >> In file common/env_common.c:
> >> const uchar *env_get_addr(int index)
> >> {
> >> //      if (gd->env_valid)
> >> //              return (uchar *)(gd->env_addr + index);
> >> //      else
> >>                   return &default_environment[index];
> >> }
> >>
> > Assuming that you checked that your environment is valid you might be
> > facing the fact that the gd pointer is corrupted. gd is a pointer to the
> > "global data" and used for storing globals which are available before
> > and after relocation. On (32bit) ARM this value used to be stored in
> > register r8 but moved to r9 (llvm cannot reserve an arbitrary register,
> > but can reserve r9 for platform specific usage). If ubldr uses r9 you
> > end up with a invalid gd pointer when calling back into u-boot. ubldr
> > now reserves r8 and r9 so a recent version should work fine on an older
> > U-boot as well as current master.
> >
> > Can you check the latest ubldr?
> 
> Hi Jeroen,
> 
> Thanks for your response.
> 
> 1) Today, I tested ubldr in the snapshot build 
> FreeBSD-11.0-CURRENT-arm-armv6-BEAGLEBONE-20140428-r265054.img.bz2
> without commenting out those 3 lines, I still can not get "fdt ls" in 
> ubldr command line.
> 
> After commenting out those 3 lines and rebuild u-boot, I can get "fdt 
> ls" in ubldr command line.
> 
> Note: All my previous test was based on 
> FreeBSD-11.0-CURRENT-arm-armv6-BEAGLEBONE-20140323-r263665.img.bz2
> 
> 2) Would you please point to me which revision that reserves both r8 and r9?
> 
> 
> Thanks.
> 
> 
> > Regards,
> > Jeroen
> >
> >
> >
> 

I think you should be debugging this from the ubldr side.  If 'fdt ls'
fails to load the dtb when the u-boot global env is present, then what
we need to know is what result is being returned when ubldr looks up the
fdtaddr and/or fdt_addr variables.  Does it get an address for the dtb
at all?  Is the address invalid?  Is it valid but it points to something
that doesn't look like a valid dtb header?

-- Ian