I am looking for 8xxrom with ethernet(TFTP).

I am looking for 8xxrom with ethernet(TFTP).

[jinoung kim]

Hi,linuxers
I am total newbie to embedded linux systems.
I trying to connect the 8xxrom to my MPC860ADS board.
Can someone tell me how do I load the kernel onto the board.
I have 2M flash(29f040) and 4M dram(mcm51816) only.
I understood the 8xxrom need additional memory for linux kernel.Is that right ?
I saw MPC8XX_XIN is 4MHz in config.h(No ifdef) but my ADS860 B'd has 5MHz. I want to know this code was tested to ADS860 B'd.
Because this is first time to make a kind of bootrom, my question has something wrong maybe.
I will looking forward to your help.
Regards,
Jinoung


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

omitted kernel sections

[Kwansuk Kim]

Hi,

Nowadays, I'm trying load the kernel on my custom board. (which has MPC860)

when I was following the procedure : initialize console on SMC2, memory allocation for kernel and ramdisk...
there was a problem. The compressed kernel image wasn't loaded. So the procedure stopped on gunzip process.

I use AMC BDM port, and I speculate the messages.

It's the message when kernel is loaded.

---------------------------------------
> LOAD 'c:\860source\zvmlinux.initrd'
  Warning: symbols deleted - check use in macros etc.
 Loading section '.text' located at 0x00400000..0x004046E4
 Loading section '.rodata' located at 0x004046F0..0x00404B90
 Loading section '.data' located at 0x00405000..0x0040530C
 Loading section '.bss' located at 0x00406000..0x0040B1F0
  Warning:
  'main' function not found in file: c:\860source\zvmlinux.initrd
  Note: in startup routine. Enter STEP to go to High-level module.


This is the section map through the command 'objdump -h zvmlinux.initrd'

--------------------
zvmlinux.initrd:     file format elf32-big

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000046e4  00400000  00400000  00010000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       000004a0  004046f0  004046f0  000146f0  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         0000030c  00405000  00405000  00015000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          000051f0  00406000  00406000  00016000  2**2
                  ALLOC
  4 .image        00064605  00000000  00000000  00016000  2**0
                  CONTENTS, READONLY
  5 .initrd       00201d19  00000000  00000000  0007a605  2**0
                  CONTENTS, READONLY

Why weren't .image, .initrd section loaded? Because they aren't elf format file?

But I tried. I changed the zipped files into elf data file as

.byte 0x00 0x00 blah blah blah...

And there was the same message, only four sections were loaded.

What can I do? I haven't any idea.

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

Re: omitted kernel sections

[Wolfgang Denk]

In message <NEBBKFENMLEDKDHMEHPJKEMECAAA.kskim@neowave.co.kr> Kwansuk
Kim wrote:
>
> when I was following the procedure : initialize console on SMC2, memory allocation for kernel and ramdisk...
> there was a problem. The compressed kernel image wasn't loaded. So the procedure stopped on gunzip process.

Which version of Linux are you using?

> I use AMC BDM port, and I speculate the messages.
>
> It's the message when kernel is loaded.
>
> ---------------------------------------
> > LOAD 'c:\860source\zvmlinux.initrd'
>   Warning: symbols deleted - check use in macros etc.
>  Loading section '.text' located at 0x00400000..0x004046E4
>  Loading section '.rodata' located at 0x004046F0..0x00404B90
>  Loading section '.data' located at 0x00405000..0x0040530C
>  Loading section '.bss' located at 0x00406000..0x0040B1F0
>   Warning:
>   'main' function not found in file: c:\860source\zvmlinux.initrd
>   Note: in startup routine. Enter STEP to go to High-level module.

It seems your debugger loads only the boot loader code,  but  neither
the kernel nor the initrd.

> This is the section map through the command 'objdump -h zvmlinux.initrd'
>
> --------------------
> zvmlinux.initrd:     file format elf32-big
>
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         000046e4  00400000  00400000  00010000  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   1 .rodata       000004a0  004046f0  004046f0  000146f0  2**4
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   2 .data         0000030c  00405000  00405000  00015000  2**2
>                   CONTENTS, ALLOC, LOAD, DATA
>   3 .bss          000051f0  00406000  00406000  00016000  2**2
>                   ALLOC
>   4 .image        00064605  00000000  00000000  00016000  2**0
>                   CONTENTS, READONLY
>   5 .initrd       00201d19  00000000  00000000  0007a605  2**0
>                   CONTENTS, READONLY
>
> Why weren't .image, .initrd section loaded? Because they aren't elf format file?

Most probably because your debugger loads  only  such  sections  that
have the "LOAD" flag set.

> What can I do? I haven't any idea.

There are several solutions; for instance, use objcopy to set the
"LOAD" flag on the '.image' and '.initrd' sections, too.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
If programming was easy, they wouldn't need something as  complicated
as a human being to do it, now would they?
                       - L. Wall & R. L. Schwartz, _Programming Perl_

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

Re: omitted kernel sections

[Jerry Van Baren]

Jon Diekema and I tried Wolfgang's "load" flag hint with the EST JTAG
debugger and were unsuccessful.  We were unable to use objcopy to make
the extra sections loadable.  We are guessing that you have to set the
loadable flag, but you also have to label the section ".text" for the
tools that are giving problems (EST in our case).  Jon produced a patch
(based on work by Arto Vuori) which goes into the makefile and makes
valid loadable sections out of the gzimage (compressed kernel) and the
rdimage (initial ramdisk) sections.

Dan Malek has rejected the patch in the BitKeeper tree, although Jon
and I disagree with him.  I didn't find Dan's reply in the archives, it
apparently was a direct reply.  His arguments, as I recall (and my
apologies, Dan, if I get them wrong), are:

* It makes the image larger.
 > Not really, its just some more elf headers that get stripped on loading.

* 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
 > I disagree, we ran into the problem, developers before us ran into
the problem, and it is coming up again.

* It requires an extra relink step.
 > Not a big deal in my book given the benefits: a valid elf file that
is loadable by commonly used tools.

Dan said in a later message that he had put together a C program that
rewrote the elf headers to make the file a loadable elf file, but I
have not investigated his program.

I'm having problems finding the messages in the archives using the
search (it apparently is only searching June -- the indexing only
covers the latest month?).  For details, see the summary of the May
messages, which includes Jon's proposed patch:
http://lists.linuxppc.org/listarcs/linuxppc-embedded/linuxppc-embedded.200005

Search for the following header:
 From owner-linuxppc-embedded@lists.linuxppc.org  Tue May  9 12:52:58 2000
Message-Id: <m12pEA0-001SyZC@bucks>
From: diekema@bucks.si.com (diekema_jon)
Subject: Re: Getting the image section of the ELF file to load w/
VxWorks boot ROM
To: linuxppc-embedded@lists.linuxppc.org
Date: Tue, 9 May 2000 13:51:08 -0400 (EDT)
In-Reply-To: <391834D3.9E57B710@Zentropix.com> from "Daniel G.
Clemmensen" at May 09, 2000 11:54:59 AM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The approach that I settled upon was identified in my initial post,
however I didn't actually do all the steps.  I have attached the the
files that are needed to make it work.

Note: The Linux_2_3 BitKeeper repository at FMS Labs contains
       these changes.


At 10:08 AM 6/26/00 +0200, Wolfgang Denk wrote:

>In message <NEBBKFENMLEDKDHMEHPJKEMECAAA.kskim@neowave.co.kr> Kwansuk
>Kim wrote:
> >
> > when I was following the procedure : initialize console on SMC2,
> memory allocation for kernel and ramdisk...
> > there was a problem. The compressed kernel image wasn't loaded. So
> the procedure stopped on gunzip process.
>
>Which version of Linux are you using?
>
> > I use AMC BDM port, and I speculate the messages.
> >
> > It's the message when kernel is loaded.
> >
> > ---------------------------------------
> > > LOAD 'c:\860source\zvmlinux.initrd'
> >   Warning: symbols deleted - check use in macros etc.
> >  Loading section '.text' located at 0x00400000..0x004046E4
> >  Loading section '.rodata' located at 0x004046F0..0x00404B90
> >  Loading section '.data' located at 0x00405000..0x0040530C
> >  Loading section '.bss' located at 0x00406000..0x0040B1F0
> >   Warning:
> >   'main' function not found in file: c:\860source\zvmlinux.initrd
> >   Note: in startup routine. Enter STEP to go to High-level module.
>
>It seems your debugger loads only the boot loader code,  but  neither
>the kernel nor the initrd.
>
> > This is the section map through the command 'objdump -h
> zvmlinux.initrd'
> >
> > --------------------
> > zvmlinux.initrd:     file format elf32-big
> >
> > Sections:
> > Idx Name          Size      VMA       LMA       File off  Algn
> >   0 .text         000046e4  00400000  00400000  00010000  2**2
> >                   CONTENTS, ALLOC, LOAD, READONLY, CODE
> >   1 .rodata       000004a0  004046f0  004046f0  000146f0  2**4
> >                   CONTENTS, ALLOC, LOAD, READONLY, DATA
> >   2 .data         0000030c  00405000  00405000  00015000  2**2
> >                   CONTENTS, ALLOC, LOAD, DATA
> >   3 .bss          000051f0  00406000  00406000  00016000  2**2
> >                   ALLOC
> >   4 .image        00064605  00000000  00000000  00016000  2**0
> >                   CONTENTS, READONLY
> >   5 .initrd       00201d19  00000000  00000000  0007a605  2**0
> >                   CONTENTS, READONLY
> >
> > Why weren't .image, .initrd section loaded? Because they aren't elf
> format file?
>
>Most probably because your debugger loads  only  such  sections  that
>have the "LOAD" flag set.
>
> > What can I do? I haven't any idea.
>
>There are several solutions; for instance, use objcopy to set the
>"LOAD" flag on the '.image' and '.initrd' sections, too.
>
>Wolfgang Denk
>
>--
>Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
>Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
>If programming was easy, they wouldn't need something as  complicated
>as a human being to do it, now would they?
>                        - L. Wall & R. L. Schwartz, _Programming Perl_
>


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

Re: omitted kernel sections

[Murray Jensen]

On Mon, 26 Jun 2000 08:48:36 -0400, Jerry Van Baren <vanbaren_gerald@si.com> 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/

Re: omitted kernel sections

[Steven Tarr]

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/

Re: omitted kernel sections

[Jerry Van Baren]

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

>On Mon, 26 Jun 2000 08:48:36 -0400, Jerry Van Baren
><vanbaren_gerald@si.com> 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 ...

[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/

Re: omitted kernel sections

[Wolfgang Denk]

In message <4.3.2.20000626080626.00b482e0@falcon.si.com> you wrote:
>
> Jon Diekema and I tried Wolfgang's "load" flag hint with the EST JTAG
> debugger and were unsuccessful.  We were unable to use objcopy to make

Well, IMHO the tools should fit the work, no vice  versa.  Maybe  you
can talk with ETS and ask what's necessary to load a Linux image with
their tools.

I don't use EST right now, so I can't help here. I'm using  the  Aba-
tron  box,  and found that Abatron was *very* helpful many times, for
instance by providing a Linux version of their configuration  utility
within  a  few days after I mentioned that I need something like that
(in fact, when I asked for _some_ documentation for the protocol thay
use to access the box, they sent me the full  source  code  of  their
tool). If your tool vendor is no so helpful, you know the options :-)

> Dan Malek has rejected the patch in the BitKeeper tree, although Jon
> and I disagree with him.  I didn't find Dan's reply in the archives, it
> apparently was a direct reply.  His arguments, as I recall (and my
> apologies, Dan, if I get them wrong), are:
>
> * It makes the image larger.
>  > Not really, its just some more elf headers that get stripped on loading.

I'm probably with you here.

> * 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
>  > I disagree, we ran into the problem, developers before us ran into
> the problem, and it is coming up again.

Here Dan is right, I think. Normally I just strip the ELF header  and
use  the  file as "binary" image - all the tools I'm using can accept
that.

> * It requires an extra relink step.
>  > Not a big deal in my book given the benefits: a valid elf file that
> is loadable by commonly used tools.

Ummm... depends on your definition of "commonly used".

I never needed it myself...

You might also argument that you should be using a firmware which  is
capable of downloading a linux image :-)

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
panic: kernel trap (ignored)

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

Re: omitted kernel sections

[Jerry Van Baren]

Treading delicately on the brink of an all-out flamewar :-)...

At 06:04 PM 6/26/00 +0200, Wolfgang Denk wrote:
>In message <4.3.2.20000626080626.00b482e0@falcon.si.com> you wrote:
> >
> > Jon Diekema and I tried Wolfgang's "load" flag hint with the EST JTAG
> > debugger and were unsuccessful.  We were unable to use objcopy to make
>
>Well, IMHO the tools should fit the work, no vice  versa.  Maybe  you
>can talk with ETS and ask what's necessary to load a Linux image with
>their tools.

Yup.  Been there, done that, they haven't send me any updates.  Reading
between the lines, they said that it gets the job done as it stands, so
I am not holding my breath waiting for an update.

Their JTAG programming standard practice (_I_ would call it a
"workaround" :-) is to convert the elf file to an S-record file (which
converts _all_ the sections, oddly enough :-), and then program using
the S-record file.  Sigh.

For loading elf images via FTP/TFTP, their BootROM loads vxWorks just
fine and they don't understand why I would want to load anything else
:-).  For those who don't get the humor here, WindRiver of vxWorks fame
recently purchased EST.

>I don't use EST right now, so I can't help here. I'm using  the  Aba-
>tron  box,  and found that Abatron was *very* helpful many times, for
>instance by providing a Linux version of their configuration  utility
>within  a  few days after I mentioned that I need something like that
>(in fact, when I asked for _some_ documentation for the protocol thay
>use to access the box, they sent me the full  source  code  of  their
>tool). If your tool vendor is no so helpful, you know the options :-)
>
> > Dan Malek has rejected the patch in the BitKeeper tree, although Jon
> > and I disagree with him.  I didn't find Dan's reply in the archives, it
> > apparently was a direct reply.  His arguments, as I recall (and my
> > apologies, Dan, if I get them wrong), are:
> >
> > * It makes the image larger.
> >  > Not really, its just some more elf headers that get stripped on
> loading.
>
>I'm probably with you here.
>
> > * 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
> >  > I disagree, we ran into the problem, developers before us ran into
> > the problem, and it is coming up again.
>
>Here Dan is right, I think. Normally I just strip the ELF header  and
>use  the  file as "binary" image - all the tools I'm using can accept
>that.
>
> > * It requires an extra relink step.
> >  > Not a big deal in my book given the benefits: a valid elf file that
> > is loadable by commonly used tools.
>
>Ummm... depends on your definition of "commonly used".
>
>I never needed it myself...
>
>You might also argument that you should be using a firmware which  is
>capable of downloading a linux image :-)

That was actually our primary problem.  We are using EST 8260 boards
for our prototype/software development.  They came with an EST BootROM
that is capable of loading an elf image via FTP or TFTP, but they would
not load the gzimage or rdimage sections.  I was working on a TFTP
loader myself, but it was faster and easier to rewrite the elf headers
to change the gzimage section to .text and have the EST BootROM work
for us.

The other half of the problem is getting the firmware capable of
downloading a linux image _into_ the boot flash device, especially the
first time.  That is where the JTAG tools are essential.  It is also
extremely useful (an understatement :-) to be able to use a JTAG
debugger to step through your first cut BootROM or linux load to see
why it isn't working.

Neil Russell <caret@c-side.com> has made his limon (the Linux Monitor)
publicly available and it is an excellent BootROM.  Since the EST
BootROM is working for us at the moment, we are not actively using
limon.  It _is_ in our long term plans, however, and we are grateful
that he chose to release the source under the GPL license.  Hopefully
we will have the opportunity to add value to it.

Reference from Neil:
The source for LiMon can be downloaded from here:

         http://www.thinsys.com/limon.html



>Wolfgang Denk
>
>--
>Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
>Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
>panic: kernel trap (ignored)

gvb


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

Re: omitted kernel sections

[Dan Malek]

Jerry Van Baren wrote:

> Dan Malek has rejected the patch in the BitKeeper tree, although Jon
> and I disagree with him.

The purpose of the software contained in the boot directory and
the resulting zImage is to provide a minimal, generic environment
for all embedded systems.  The code in this directory it not
intended to replace a non-existant boot rom, but rather to collect
sufficient information about the board differences and provide that
to a kernel that should be generic for all 8xx processors.

The zImage in this directory is supposed to be the smallest compressed
image that will boot from a variety of production boot devices, such
as Flash rom, Compact/Flash cards, disks, or networks.

The ELF header on this image is an artifact of the tools used to
build this image.  All of the bits following this header comprise
a self-contained image.  Execute from the first location of this
image and it will relocate and uncompress the kernel, along with
any initial ram disk.  There are no symbols or any information
useful to a debugger in this image, so I fail to see why people
keep trying to use debuggers on this image.  If you want to use
a debugger, there is a fully-dressed ELF image called 'vmlinux'
in the top directory designed for this purpose.


> * It makes the image larger.
>  > Not really, its just some more elf headers that get stripped on loading.

Yes, really, because all of the BSS sections are expanded as
loadable sections using this technique.  People that have special
tools (and count flash rom bytes for all uses), couldn't load this
zImage when absolutely nothing else changed in the code.  It simply
grew in size and added no value to them.

>  > I disagree, we ran into the problem, developers before us ran into
> the problem, and it is coming up again.

Everybody wants something different in this directory and wants
different images to be produced.  If you want something different,
make this happen locally.  The purpose of using your changes in
the common source code is to generically benefit others, and
this doesn't do that.  It helps you and the few doing exactly what
you want, and breaks what people before you have been using for years.

In less time than you have spent complaining on this list, you could
have done as many before you.  Understand the format of this file
and write a conversion program to format this for your tools.  The
EST tools discussed right now have a binary loader option.  You can
use that without writing _anything_.  Should you write tools unique
to your environment, you will know that the file format here isn't
going to change, and your tools will remain useful for a very long
time.

>  > Not a big deal in my book given the benefits: a valid elf file that
> is loadable by commonly used tools.

As I said, a valid ELF file is produced, and it is in the upper
level directory.  Stop trying to use a special production purpose
bag of bits and use the other files more suitable for debugging.

> Dan said in a later message that he had put together a C program that
> rewrote the elf headers to make the file a loadable elf file, but I
> have not investigated his program.

I wrote a program that will hack the headers such that the stupid
VxWorks TFTP loader would load the zImage (like other properly
written loaders will do without any hacks).  I don't know if this
will help anyone else.  You can find it on
	ftp://ftp.embeddededge.com/pub/vxhack.c


	-- Dan

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

Re: omitted kernel sections

[Frank Przybylski]

Hi,

Jerry Van Baren wrote:
>
> Jon Diekema and I tried Wolfgang's "load" flag hint with the EST JTAG
> debugger and were unsuccessful.  We were unable to use objcopy to make
> the extra sections loadable.  We are guessing that you have to set the
> loadable flag, but you also have to label the section ".text" for the
> tools that are giving problems (EST in our case).  Jon produced a patch
> (based on work by Arto Vuori) which goes into the makefile and makes
> valid loadable sections out of the gzimage (compressed kernel) and the
> rdimage (initial ramdisk) sections.
>

I'd guess it's more important to adjust the VMA than the section's name to tell
the loader where to put the sections content.

If you examine the section's listing you'll notice address zero for .image and
.initrd, so only setting the load flag won't do the job.

I only prepare the kernel image (right now, I don't use .initrd) for loading
with the following objcopy call:

'powerpc-linux-objcopy \
 --set-section-flags=image=contents,alloc,load,readonly,data \
 --adjust-section-vma=image=$(powerpc-linux-objdump -h $kernel/zvmlinux | \
 grep .bss | awk '{print "0x"$4}') \
 $kernel/zvmlinux \
 $kernel/zvmlinux2'

To be on the secure side one should correct the vma's of .image to fit behind
.bss and of .initrd behind .image.

I thought someone patched the makefile to do this? (I guess, I'm not working on
the actual sources, but I don't like the idea behind bitkeeper very much
either...)

hth
	Frank

--
===============================================================================
Frank Przybylski,VAS GmbH,Gotenstr.6,20097 Hamburg,GERMANY,TEL:+49-40-238568-14
   mailto:Frank.Przybylski@vas-gmbh.de , visit us at http://www.vas-gmbh.de
===============================================================================

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

Re: omitted kernel sections

[Matt Porter]

On Mon, Jun 26, 2000 at 03:43:35PM +0900, Kwansuk Kim wrote:

<snip>

>   Warning:
>   'main' function not found in file: c:\860source\zvmlinux.initrd
>   Note: in startup routine. Enter STEP to go to High-level module.
                   CONTENTS, READONLY
>
> Why weren't .image, .initrd section loaded? Because they aren't elf format file?

Correct. An ELF loader isn't going to load non-ELF sections.

> What can I do? I haven't any idea.

Doesn't your BDM/JTAG probe have an option to load binary data into
memory?  I don't know its capabilities but you can load the zvmlinux
as above and let it strip the non-ELF sections off, then load the
vmlinux.gz and ramdisk.image.gz files into memory using using raw
binary transfer.  Depending on your probe's host software, you should
be able to script all this stuff.

An alternative is to get the Abatron BDI2000 BDM/JTAG probe
(http://www.abatron.ch) which understands the Linux image format.

--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com

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