boottime kernel relocation, what I missed?
Good day all,
For the first time I begin working on PPC, and on low level, and right start from boot sequence, one issue puzzled me.
After bootstrap code (zImage) uncompressed the kernel vmLinux to physical memory (say from addr 0),
it jumps to the kernel entry point, _start, using physically address.
At this time, the MMU is not yet setup to map the kernel virtual address
(which is statically linked against base address KERNELBASE) to the physically address.
$ nm vmlinux |grep early_init c038b8e0 T early_init
_start calls early_init before mmu is on to map the KERNEL_BASE to physically address
The question is how "bl early_init" can branch to the early_init entry point, properly, as early_init is still a virtual address?
Thanks
Jim
Signature · 2 lines
View this message in context: http://www.nabble.com/boottime-kernel-relocation%2C-what-I-missed--tf4072673.html#a11574529 Sent from the linuxppc-embedded mailing list archive at Nabble.com.
Figure that out, the bootstrap actually mapped the first 16M from C000000 to the physicall address,
so calling a c routine, as long as it is in the first 16M, is OK
Quoted 28 lines · meerkat
Good day all,
For the first time I begin working on PPC, and on low level, and right start from boot sequence, one issue puzzled me.
After bootstrap code (zImage) uncompressed the kernel vmLinux to physical memory (say from addr 0),
it jumps to the kernel entry point,_start, using physically address.At this time, the MMU is not yet setup to map the kernel virtual address
(which is statically linked against base address KERNELBASE) to the physically address.$ nm vmlinux |grep early_init c038b8e0 T early_init
_startcallsearly_initbefore mmu is on to map theKERNEL_BASEto physically addressThe question is how "bl
early_init" can branch to theearly_initentry point, properly, asearly_initis still a virtual address?Thanks
Jim
Signature · 2 lines
View this message in context: http://www.nabble.com/boottime-kernel-relocation%2C-what-I-missed--tf4072673.html#a11588451 Sent from the linuxppc-embedded mailing list archive at Nabble.com.
Quoted 5 lines · meerkat
Figure that out, the bootstrap actually mapped the first 16M from C000000 to the physicall address,
so calling a c routine, as long as it is in the first 16M, is OK
I think you're still not understanding the fact that "bl" is a *relative* branch - the branch target in the instruction encoding is just an offset from the current address, not an effective address. The bl should work correctly whether the code is actually running at the link address reported by nm (0xcxxxxxxx in this case), or if it has been loaded and executed elsewhere.
Refer to the 32-bit Programming Environments Manual for PowerPC, or in the EREF (if you're using a BookE part - e500/e200) for more details. If you're just learning PowerPC assembler, you should really give this book a good thourough read.
Quoted 11 lines
Quoted 9 lines · meerkat
Good day all,
For the first time I begin working on PPC, and on low level, and right start from boot sequence, one issue puzzled me.
After bootstrap code (zImage) uncompressed the kernel vmLinux to physical memory (say from addr 0),
it jumps to the kernel entry point,_start, using physically address.
If you read the book specified above, you will see that branch instructions always specify an effective address, not a physical address. You can disable translation or map the address so EA=PA, but that's a different issue.
-Becky
Becky:
Thanks for the reply. Agree I should read bookE, which given the short
schedule, it is still on my TODO list yet.
So are you saying linker does all the relative reference, that the bl foo is always relative even though the foo is defined in a different module? (In my case, bl call is made in head.S, early_init() is defined in another file setup.c).
Regards,
Jim
Quoted 49 lines · Becky Bruce
Quoted 6 lines · meerkat
Figure that out, the bootstrap actually mapped the first 16M from C000000 to
the physicall address,
so calling a c routine, as long as it is in the first 16M, is OKI think you're still not understanding the fact that "bl" is a *relative* branch - the branch target in the instruction encoding is just an offset from the current address, not an effective address. The bl should work correctly whether the code is actually running at the link address reported by nm (0xcxxxxxxx in this case), or if it has been loaded and executed elsewhere.
Refer to the 32-bit Programming Environments Manual for PowerPC, or in the EREF (if you're using a BookE part - e500/e200) for more details. If you're just learning PowerPC assembler, you should really give this book a good thourough read.
Quoted 5 lines
Quoted 3 lines · meerkat
Good day all,
Quoted 8 lines
Quoted 8 lines
For the first time I begin working on PPC, and on low level, and right
start from boot sequence, one issue puzzled me.After bootstrap code (zImage) uncompressed the kernel vmLinux to physical
memory (say from addr 0),
it jumps to the kernel entry point,_start, using physically address.If you read the book specified above, you will see that branch instructions always specify an effective address, not a physical address. You can disable translation or map the address so EA=PA, but that's a different issue.
-Becky
_______________________________________________
Linuxppc-embedded mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Signature · 2 lines
View this message in context: http://www.nabble.com/boottime-kernel-relocation%2C-what-I-missed--tf4072673.html#a11629480 Sent from the linuxppc-embedded mailing list archive at Nabble.com.
Quoted 4 lines · meerkat
So are you saying linker does all the relative reference, that the bl foo is always relative even though the foo is defined in a different module? (In my case, bl call is made in
head.S,early_init()is defined in another filesetup.c).
If you see "bl foo", it's relative. It has to be, because that's how the instruction works. Also, it's not really in a different module, it's just a different file, but it's all linked into a single executable image.
Cheers,
-Becky
Quoted 67 lines
Regards,
Jim
Quoted 49 lines · Becky Bruce
Quoted 6 lines · meerkat
Figure that out, the bootstrap actually mapped the first 16M from C000000 to
the physicall address,
so calling a c routine, as long as it is in the first 16M, is OKI think you're still not understanding the fact that "bl" is a *relative* branch - the branch target in the instruction encoding is just an offset from the current address, not an effective address. The bl should work correctly whether the code is actually running at the link address reported by nm (0xcxxxxxxx in this case), or if it has been loaded and executed elsewhere.
Refer to the 32-bit Programming Environments Manual for PowerPC, or in the EREF (if you're using a BookE part - e500/e200) for more details. If you're just learning PowerPC assembler, you should really give this book a good thourough read.
Quoted 5 lines
Quoted 3 lines · meerkat
Good day all,
Quoted 8 lines
Quoted 8 lines
For the first time I begin working on PPC, and on low level, and right
start from boot sequence, one issue puzzled me.After bootstrap code (zImage) uncompressed the kernel vmLinux to physical
memory (say from addr 0),
it jumps to the kernel entry point,_start, using physically address.If you read the book specified above, you will see that branch instructions always specify an effective address, not a physical address. You can disable translation or map the address so EA=PA, but that's a different issue.
-Becky
_______________________________________________
Linuxppc-embedded mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-embeddedSignature · 7 lines
View this message in context: http://www.nabble.com/boottime-kernel-relocation%2C-what-I-missed--tf4072673.html#a11629480 Sent from the linuxppc-embedded mailing list archive at Nabble.com. _______________________________________________ Linuxppc-embedded mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-embedded