From: Wolfgang Denk <hidden> Date: 2000-06-26 08:08:59
In message [off-list ref] 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.
---------------------------------------
quoted
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/
From: Jerry Van Baren <hidden> Date: 2000-06-26 12:48:36
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: [off-list ref] 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 [off-list ref] Kwansuk
Kim wrote:
quoted
when I was following the procedure : initialize console on SMC2,
memory allocation for kernel and ramdisk...
quoted
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?
quoted
I use AMC BDM port, and I speculate the messages.
It's the message when kernel is loaded.
---------------------------------------
quoted
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.
quoted
This is the section map through the command 'objdump -h
format file?
Most probably because your debugger loads only such sections that
have the "LOAD" flag set.
quoted
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_
From: Dan Malek <hidden> Date: 2000-06-26 21:57:32
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/
From: Frank Przybylski <hidden> Date: 2000-06-27 13:42:22
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/