Re: [U-Boot] Latest u-boot release on BeagleBone Black for FreeBSD

2014-05-07 Thread Ian Lepore 
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


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Latest u-boot release on BeagleBone Black for FreeBSD

2014-05-07 Thread Tim Kientzle 

On May 6, 2014, at 7:09 PM, Xuebing Wang xbi...@gmail.com wrote:

 2) Would you please point to me which revision that reserves both r8 and r9?


r258527 | andrew | 2013-11-24 12:33:38 -0800 (Sun, 24 Nov 2013) | 3 lines

Recent versions of U-Boot require us to also backup and restore r9 for API
calls to work.



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Latest u-boot release on BeagleBone Black for FreeBSD

2014-05-07 Thread Tim Kientzle 

On May 7, 2014, at 8:02 AM, Tim Kientzle t...@kientzle.com wrote:

 
 On May 6, 2014, at 7:09 PM, Xuebing Wang xbi...@gmail.com wrote:
 
 2) Would you please point to me which revision that reserves both r8 and r9?
 
 
 r258527 | andrew | 2013-11-24 12:33:38 -0800 (Sun, 24 Nov 2013) | 3 lines
 
 Recent versions of U-Boot require us to also backup and restore r9 for API
 calls to work.
 
 
 

And MFCed to Stable-10:


r265064 | ian | 2014-04-28 16:46:04 -0700 (Mon, 28 Apr 2014) | 2 lines

MFC r257210, r258527: No hardfloat in ubldr, save/restore r9 for api calls.



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Latest u-boot release on BeagleBone Black for FreeBSD

2014-05-06 Thread Xuebing Wang 


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





--
Thanks,
Xuebing Wang

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Latest u-boot release on BeagleBone Black for FreeBSD

2014-05-04 Thread Jeroen Hofstee 
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?

Regards,
Jeroen


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Latest u-boot release on BeagleBone Black for FreeBSD

2014-04-08 Thread Xuebing Wang 

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];
}

--
Thanks,
Xuebing Wang

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Latest u-boot release on BeagleBone Black for FreeBSD

2014-04-08 Thread Ian Lepore 
On Mon, 2014-04-07 at 15:16 +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. Example is:
 -- fdt header
 
 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];
 }
 

Are you using a fairly recent ubldr on the freebsd side?  I made some
changes around March 1st on how ubldr finds / loads fdt data...

It first looks for env vars named fdtaddr then fdt_addr in the u-boot
environment.  If the variable exists it tries to validate the data at
that address as a valid dtb header and if it is, that's the data that is
passed to the kernel.  Otherwise it next it looks for env vars named
fdtfile then fdt_file.  If one of those exists it tries to load that
filename from the freebsd filesystem in the usual places where kernel
and modules are located (/boot/kernel, /boot/modules).

It seems strange to me that things work only if you comment out the
dynamic environment in u-boot.  You said in order to get the correct
fdt data and I wonder what you mean by that.  Do you mean that the
u-boot script stuff is loading fdt data, but it's not the freebsd data
but rather the linux data?

Unfortunately, freebsd isn't able to use linux or vendor-supplied dtb
files yet.  We're working towards using only documented bindings but
right now we still need freebsd-specific extra properties in the dtb.

I added the support for fdtfile/fdt_file specifically to handle this
situation until we're able to handle the vendor dtb files.  If you
manipulate your u-boot environment so that fdtaddr and fdt_addr are
unset and fdtfile is the name of the appropriate freebsd dtb file (which
you must install on your freebsd image along with the kernel), then
everything should work out properly.

Of course an alternative is to install the freebsd dtb files onto the
msdos partition along with u-boot and let u-boot load them and set
fdtaddr.  If this is what you're doing and it still isn't working, I
suspect the problem is in ubldr, not u-boot itself.  We'll have to turn
on some debugging in sys/boot/fdt/fdt_loader_cmd.c to track that down.

-- Ian


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Latest u-boot release on BeagleBone Black for FreeBSD

2014-04-07 Thread Xuebing Wang 

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. Example is:

-- fdt header

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];
}

--
Thanks,
Xuebing Wang

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot