Date: Thu, 28 Feb 2013 18:10:13 -0700 From: Ian Lepore <ian@FreeBSD.org> To: Tim Kientzle <kientzle@FreeBSD.org> Cc: freebsd-arm@FreeBSD.org Subject: Re: PHYSADDR Message-ID: <1362100213.1195.88.camel@revolution.hippie.lan> In-Reply-To: <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> References: <E886046B-1612-425B-902B-72D4B0E93618@freebsd.org> <1362068453.1195.40.camel@revolution.hippie.lan> <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2013-02-28 at 08:58 -0800, Tim Kientzle wrote:
> On Feb 28, 2013, at 8:20 AM, Ian Lepore wrote:
>=20
> > On Wed, 2013-02-27 at 22:27 -0800, Tim Kientzle wrote:
> >> Starting to look at what is needed for a Generic ARM kernel.
> >> There's a lot here; I sincerely hope I'm not the only one=85 ;-)
> >>=20
> >> First up: Can we get rid of PHYSADDR?
> >>=20
> >=20
> > If you mean, can we get rid of it within the runtime kernel, I'd say
> > yes, because we can use a global variable instead which is easily
> > settable in the entry code.
>=20
> It doesn't seem to be used in the runtime kernel. As far as
> I can see, it's purely a bootstrap concept.
>=20
> > On the other hand, I've been working
> > towards getting that value set correctly in the kernel elf headers at
> > link time.
>=20
> My question really boils down to whether PIC techniques
> are sufficient for the early bootstrap stage to determine
> where the kernel is currently executing and use that to
> drive the initial MMU bring up. I've just started, but
> the PHYSADDR uses I've examined can be replaced
> with PIC techniques. But this part of the code is
> pretty involved and riddled with conditional compilations,
> so it will be slow going.
>=20
> I was impressed to find that ubldr seems to be PIC.
> I've run the same binary at different load addresses
> and so far it "just works." (I didn't think it would work,
> so I was surprised by this. I haven't dug through to
> figure out why it works yet.)
>=20
I was suprised by this paragraph, and I've just done some testing and I
wonder if it's really running at different addresses, because I can't
make it do so without relinking it at that address. To test, I saved
the entry PC in uboot/start.S and printed it in main (patch below). No
matter where I tell u-boot to load ubldr, it seems to ignore the command
line and honor the elf headers:
TFTP from server 172.22.42.240; our IP address is 172.22.42.233
Filename '/rpi/boot/ubldr'.
Load address: 0x200000
Loading: ##############
done
Bytes transferred =3D 199412 (30af4 hex)
U-Boot> bootelf
## Starting application at 0x01000054 ...
Consoles: U-Boot console =20
Compatible API signature found @17b662a8; entry_phys 1000064
=20
TFTP from server 172.22.42.240; our IP address is 172.22.42.233
Filename '/rpi/boot/ubldr'.
Load address: 0x900900
Loading: ##############
done
Bytes transferred =3D 199412 (30af4 hex)
U-Boot> bootelf
## Starting application at 0x01000054 ...
Consoles: U-Boot console =20
Compatible API signature found @17b662a8; entry_phys 1000064
<aside> The following is like the 8th version of this paragraph, maybe I
should have finished the experiments before starting the mail. </aside>
So I just learned that the load address printed by dhcp / tftp loading
is in fact where the bits get copied to initially. The bootelf command
must read the elf headers and copy the bits to the location in the
headers. We know the entry point is at offset 0x54. If I load to
200000 and do "go 200054" it fails to run, because it's not linked to
run at that address. If I first do "cp 200000 1000000 30af4" then "go
1000054" ubldr launches and runs. It also works to load directly to
1000000 and then "go 1000054'.
-- Ian
Index: arm/uboot/start.S
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- arm/uboot/start.S (revision 247421)
+++ arm/uboot/start.S (working copy)
@@ -37,6 +37,7 @@ _start:
/* Hint where to look for the API signature */
ldr ip, =3Duboot_address
str sp, [ip]
+ str pc, [ip, #4]
=20
/* Save U-Boot's r8 */
ldr ip, =3Dsaved_regs
@@ -80,6 +81,9 @@ syscall_ptr:
uboot_address:
.long 0
=20
+ .globl entry_phys
+entry_phys:
+ .long 0
saved_regs:
.long 0 /* U-Boot's r8 */
.long 0 /* Loader's r8 */
Index: uboot/common/main.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- uboot/common/main.c (revision 247421)
+++ uboot/common/main.c (working copy)
@@ -116,6 +116,7 @@ meminfo(void)
}
}
=20
+extern uint32_t entry_phys;
int
main(void)
{
@@ -142,7 +143,8 @@ main(void)
*/
cons_probe();
=20
- printf("Compatible API signature found @%x\n", (uint32_t)sig);
+ printf("Compatible API signature found @%x; entry_phys %x\n",=20
+ (uint32_t)sig, entry_phys);
=20
dump_sig(sig);
dump_addr_info();
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1362100213.1195.88.camel>