Re: omitted kernel sections

On Mon, 26 Jun 2000 08:48:36 -0400, Jerry Van Baren [off-list ref] writes:

* It isn't how everybody uses the load: everybody just strips the elf
header (pastes on a proprietary(?) header) and uses it as as a raw
binary image

Here's one example of how people use the load ...

I use the "libbfd" library (generated when you build the binutils usually)
to read the ELF headers of the image file ("zImage.initrd" in my case) and
determine the entry point of the image, then I wrap the whole thing in my
own (open, non-proprietary :-) header which contains various stuff (e.g.
checksums), and the entry point.

My boot loader then can simply use the entry point in the header to begin
execution of the image, either directly where it is stored (e.g. in flash)
or after storing/relocating it. The assumption is that the image (whatever
it is) is either location independent or will relocate the appropriate bits
as required. Fortunately, the mbxboot stuff does the latter.

This scheme has the advantage that the entry point could be set different
to the real entry point in the ELF file - for what that's worth, I can't think
of any use for that at the moment (you might have two text sections and
have to choose one? I dont know), but my goal was to try to be object format
independent in the boot loader (and so I had to create yet another object
format :-) - learning the entry point is dependent on the object format,
and is best done on the host.

So, I don't strip the ELF header, but I do paste on my own header and use
the image as a raw binary image - except that I know the entry point (as an
offset from the start of the image). But I don't do any of this as part of
the kernel build, I have a simple tool that does it when I want to "download"
the image to the target.

For the record, I support Dan's view - the way it is now, is very simple,
and has worked fine for a long time. To me, it looks like the tools you
are using are broken (or at least lacking certain features, namely the
ability to load arbitrary sections from the ELF image into memory - which
doesn't surprise me, because the JTAG stuff you mention sounds proprietary
commercial stuff, and you always run into bugs/lack of features that you
can't fix when you use software you haven't go the source for - sorry for
the soapbox - you probably don't need me to tell you :-). The "loading" of
the image (and stuff to support that) should be done outside of the kernel
build area.

In fact, it could be argued that the *boot directories don't belong in the
kernel build area either, because there is no connection between the code
in the *boot directories and the kernel code - they are separate things.
They don't share any code (at least in the mbxboot case) - the boot stuff
treats the kernel image (and ramdisk image, if it exists) as blobs of bytes,
it really should be in a separate development tree (I suppose one connection
is the way arguments/bootinfo/etc are passed to the kernel, however I would
argue that this is only an interface).

But historically (and not just with linux), the boot stuff has always been
in there for convenience so thats not going to change, just because I get
pedantic. But at least we can keep it as simple as possible. I'll shut-up
now (I wonder if anyone has actually read this far - I hope it wasn't a waste
of time for you - it was good for me *pant* *pant* :-) Cheers!
								Murray...
--
Murray Jensen, CSIRO Manufacturing Sci & Tech,         Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen@cmst.csiro.au  (old address was mjj@mlb.dmt.csiro.au)

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

I offer our solution to the problem as an additional data point. I added a command

to the boot rom code that downloads a file to any supplied address via tftp then

jumps to that address plus 0x1000. The offset of 0x1000 is to get over the

ELF header. In this case, I leave the the LINUX build environment alone

and still get a quick boot turnaround.

The commercial BDM/JTAG debuggers are almost worthless after the MMU

is enabled. Only in a "after the fact" case are they of any use. We, collectively,

need to continue to bellyache to the vendors about the short coming.......

cheers --

tarr

--
Steve Tarr
tarr@lucent.com
303-538-4056


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

At 12:40 AM 6/27/00 +1000, Murray Jensen wrote:

On Mon, 26 Jun 2000 08:48:36 -0400, Jerry Van Baren
[off-list ref] writes:

quoted

* It isn't how everybody uses the load: everybody just strips the elf
header (pastes on a proprietary(?) header) and uses it as as a raw
binary image

Here's one example of how people use the load ...

[snip]

For the record, I support Dan's view - the way it is now, is very simple,
and has worked fine for a long time. To me, it looks like the tools you
are using are broken (or at least lacking certain features, namely the
ability to load arbitrary sections from the ELF image into memory - which
doesn't surprise me, because the JTAG stuff you mention sounds proprietary
commercial stuff, and you always run into bugs/lack of features that you
can't fix when you use software you haven't go the source for - sorry for
the soapbox - you probably don't need me to tell you :-). The "loading" of
the image (and stuff to support that) should be done outside of the kernel
build area.

My argument is that the Makefile change simply _rewrites_ the existing
elf header to rename it from gzimage to .text.  To your tool, and
others like it, this should be a totally transparent change.  Since the
cost is nearly zero, why not help out the people with brain-dead
commercial tools?

Incidentally, I have not found an open source JTAG debugger.  There may
be ones available for other CPUs, I haven't searched yet, but they
don't exist yet for the 8260.  Part of the problem is that Motorola
requires a non-disclosure agreement (NDA) before it will tell you how
to access the CPU's innards via JTAG.  This effectively prohibits open
source short of reverse engineering it.  The CPU is too new and I
personally haven't had enough time (and likely won't in the near
future) to do this.  Macraigor supplies DLLs under windows that allow
things like gdb to drive it, but I don't believe they are open source
themselves.

On a similar note, I also have not been successful finding a 8260
flavor JTAG flash memory in circuit programmer.  The JTAG I/O chain for
the 8260 _is_ publicly documented and it would be possible to write a
JTAG based flash memory programmer that used the 8260 to wiggle the
flash pins sufficiently to program memory.  I have not needed it badly
enough yet to do that and the Macraigor folks told me they were working
on a linux version of their software which would either do it or help
me do it.  While the information for this is public, it still is a
staggering task to do "right" given all the potential combinations of
memories, even ignoring the

[snip]

                                                                Murray...
--
Murray Jensen, CSIRO Manufacturing Sci & Tech,         Phone: +61 3
9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3
9662 7853
Internet: Murray.Jensen@cmst.csiro.au  (old address was
mjj@mlb.dmt.csiro.au)

gvb


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/