I am trying to get Linux working on a Coldfire V4e (no, they don't
exist yet in the outside world). This is kind of an m68k, but being a
Coldfire, it is a subset of the old m68k. This is a Coldfire, but
being new and spiffy, it has an MMU (32 instruction TLB entries, 32
data TLB entries).
Currently I am at the point where a lot of the memory stuff is
possibly working, the kernel thinks it has booted, and it is trying to
fire up init. And it is failing.
Does anyone have a pointer to something I can read to tell me a bit of
how programs load, what ld.so.1 does, etc? I am in the midst of elf
headers, I see ld.so.1 being opened, I see sections with various
addresses flying by, and I end up trying to execute an address that is
not executable, only read-write. It is possible that stuff really is
percolating correctly from vma's to page tables, it is possible stuff
really is percolating correctly from page tables to TLBs. It is
possible that ld.so.1 and init really are being built correctly and
even at sensible addresses, but I don't know. There are too many
variables here that I don't know about.
Any suggestions on where I could learn more on how init is supposed to
get up and running?
Thanks,
-kb, the Kent who happens to work for an obscure little corner of
Motorola.
On Tue Oct 08, 2002 at 03:54:15PM -0400, Kent Borg wrote:
> I am trying to get Linux working on a Coldfire V4e (no, they don't
> exist yet in the outside world). This is kind of an m68k, but being a
> Coldfire, it is a subset of the old m68k. This is a Coldfire, but
> being new and spiffy, it has an MMU (32 instruction TLB entries, 32
> data TLB entries).
cool. I didn't realize there were any mmu-full Coldfire chips
in progress. nice!
> Does anyone have a pointer to something I can read to tell me a bit of
> how programs load, what ld.so.1 does, etc? I am in the midst of elf
> headers, I see ld.so.1 being opened, I see sections with various
> addresses flying by, and I end up trying to execute an address that is
> not executable, only read-write. It is possible that stuff really is
I have some test stuff I use when bringing up new arches with
uClibc that can tell you if you are getting into user space
correctly. But before messing with shared libraries, I _highly_
recommend you start with a simple staticly linked "hello world"
app for /sbin/init. Only when that is working properly should
you begin messing with shared libs.
> percolating correctly from vma's to page tables, it is possible stuff
> really is percolating correctly from page tables to TLBs. It is
For with bugs, nothing is impossible...
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
On Wed, Oct 09, 2002 at 11:14:07AM -0400, Kent Borg wrote:
> In response to my question about how ld.so.1 is supposed to get an elf
> file up and running Ben Collins and Erik Andersen suggested I write a
> simple statically linked program. Thanks for your help. (My boss had
> suggested the same thing earlier but I didn't listen to him, the
> kernel list I listened to.)
>
> Alas, it doesn't simplify matters. I wrote a tivial program (all it
> does is a link instruction to make an empty stack frame, two moves, an
> unlink to remove the empty stack frame, and a return--only 5
> instructions long) but it is still an elf file. And, following
> through the code, the kernel still wants to load ld.so.1, it seems to
> interpret the elf (Linux can run different kinds of executables,
> remember). And in the process something gets messed up.
>
> So I am back to trying to figure out what is going wrong with loading
> init and ld.so.1. I am suspicious that do_mmap_pgoff() calls are not
> all happening right and will be comparing them with what mappings.
> But I wish I knew more about what ld.so.1 does...
If you compiled it static (e.g. pass -static to gcc), then the
dynamic-linker shouldn't be referenced in the executable. The kernel
doesn't assume that elf requires ld.so.1, that's something that is
placed into the executable itself as the INTERP. If you have an INTERP
section in your test executable, you didn't link it properly. There
should be no references to NEEDED and INTERP when you do:
# coldfirev4e-elf-objdump -x hello | less
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
In response to my question about how ld.so.1 is supposed to get an elf
file up and running Ben Collins and Erik Andersen suggested I write a
simple statically linked program. Thanks for your help. (My boss had
suggested the same thing earlier but I didn't listen to him, the
kernel list I listened to.)
Alas, it doesn't simplify matters. I wrote a tivial program (all it
does is a link instruction to make an empty stack frame, two moves, an
unlink to remove the empty stack frame, and a return--only 5
instructions long) but it is still an elf file. And, following
through the code, the kernel still wants to load ld.so.1, it seems to
interpret the elf (Linux can run different kinds of executables,
remember). And in the process something gets messed up.
So I am back to trying to figure out what is going wrong with loading
init and ld.so.1. I am suspicious that do_mmap_pgoff() calls are not
all happening right and will be comparing them with what mappings.
But I wish I knew more about what ld.so.1 does...
-kb, the Kent who is in new territory in about three ways.