Latest u-boot release on BeagleBone Black for FreeBSD

U-Boot Xuebing Wang 4 participants 6 messages Apr 8, 2014 – May 7, 2014

lore

Share & tools

lore

Xuebing Wang

author

2014-04-08 08:52 UTC #0 lore raw

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

Signature · 2 lines

Thanks,
Xuebing Wang

Jeroen Hofstee

2014-05-04 11:33 UTC #1 lore raw

Hello Xuebing, (freebsd-arm added on cc),

Quoted 12 lines · 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?

Quoted 9 lines

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

Xuebing Wang

author

2014-05-07 02:09 UTC #2 lore raw

Quoted 34 lines · Jeroen Hofstee

Hello Xuebing, (freebsd-arm added on cc),
Quoted 12 lines · 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?
Quoted 9 lines
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.

Quoted 1 line

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.

Quoted 5 lines

Regards,
Jeroen

Signature · 2 lines

Thanks,
Xuebing Wang

Ian Lepore

2014-05-07 14:15 UTC #3 lore raw

Quoted 49 lines · Xuebing Wang

Quoted 34 lines · Jeroen Hofstee
Hello Xuebing, (freebsd-arm added on cc),
Quoted 12 lines · 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?
Quoted 9 lines
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.
Quoted 1 line
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.

Quoted 15 lines

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.
Quoted 5 lines
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

Tim Kientzle

2014-05-07 15:02 UTC #4 lore raw

In reply to Xuebing Wang

Quoted 1 line · Xuebing Wang

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.

------------------------------------------------------------------------

Tim Kientzle

2014-05-07 15:17 UTC #5 lore raw

Quoted 5 lines · Tim Kientzle

Quoted 1 line · Xuebing Wang
2) Would you please point to me which revision that reserves both r8 and r9?

Quoted 8 lines

------------------------------------------------------------------------
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.

------------------------------------------------------------------------