Thank you so much.
I used zsrec utility to build S-Record image. Wonderful. It works!
screen shot is as follows,
================================================================
loaded at: 00200000 0020B1F4RAM : <8DDF522D> : 8DDF52DC*
relocated to: 00100000 0010B1F4firmware chksum O On-board I/
board data at: 001001C4 001001E0): OK
relocated to: 00200100 0020011C Program FLASH : <vmlinux.srec
zimage at: 00206000 0022DF78
Linux/PPC load:
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.2.13 (root@enisei.postech.ac.kr) (gcc version 2.95.2 19991024 (r
elease)) #1 Thu May 25 15:56:27 KST 2000
Boot arguments: root=/dev/nfs rw
time_init: decrementer frequency = 180000000/60
Calibrating delay loop... 47.82 BogoMIPS
remove_mem_piece: bad overlap [7a000,a6000) with [7b000, 1000000)
Memory: 15720k available (304k kernel code, 344k data, 16k init) [c0000000,c1000
000]
DENTRY hash table entries: 262144 (order: 9, 2097152 bytes)
Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
Starting kswapd v 1.5
CPM UART driver version 0.03
ttyS00 at 0x0280 is a SMC
ttyS01 at 0x0380 is a SMC
VFS: Cannot open root device 00:00
Kernel panic: VFS: Unable to mount root fs on 00:00
Rebooting in 180 seconds..
====================================================================
Could you telll me what's difference between powerpc-linux-objcopy and zsrec?
Can we burn this S-record file into flash memory insead of loading into memory?
Some changes needed, doesn't it?
what is next step?
I read LDP(Linux Documentation Project). There are many choices to mount root file system. NFS, initrd, ..? I really want to know how to mount root file system.
Thank you for your help.
----- Original Message -----
From: "Rodney Davies" <redacted>
To: "'???'" <redacted>
Sent: Thursday, May 25, 2000 3:32 PM
Subject: RE: How to load kernel on RPX Lite Board ?
quoted
I want to load my kernel image into this board. To download
kernel image, The flash utility given by company needs
S-Record format. Actually, I do know about S-Record Format,
But I don't know how to make it. I used Montavista-2.2.13
kernel and patched it. To build the kernel, I typed "make
zImage" and I got two files named "./vmlinux" and
"./arch/ppc/mbxboot/zImage" in the kernel directory.
After that,
#>powerpc-linux-objcopy -O srec vmlinux vmlinux.srec
vmlinux.srec is created, "S-Record format"
you can use that, or use the /opt/hardhat/devkit/ppc/8xx/bin/zsrec program:
'./zsrec vmlinux > vmlinux.srec'
quoted
To download via ethernet, I installed tftpserver on my PC,
and working good.
RPX Load menu: press 123456789T key : <?> : 7
Load using tftp via Ethernet
Enter server IP address <8DDF52DC> :
So, the IP address of your tftp server is 141.223.82.220? Because that is
the IP address you've specified above in HEX. You can change this through
the "C Configure EEPROM" option. This IP must be your tftp server's IP
address (in HEX).
To convert an IP to hex: eg:
192.168.0.89 converted is -
192 = C0
168 = A8
0 = 00
89 = 59
Hence, C0A80059 == 192.168.0.89
(See below on my output example from my RPXLite board...)
quoted
Enter server filename <vmlinux.srec> :
Enter address offset : <00000000 hex> :
----
C0000390 [does not exist]
C00003A0 [does not exist]
C00003B0 [does not exist]
C00003C0 [does not exist]
C00003D0 [does not exist]
load_tftp(): ** E_RPX_DST_NOT_EXIST
3072 data bytes, 62 S-records, 6 tftp blocks, 0 repeated blocks
Could you tell me about how to download the kernel and root
file system onto my board. Maybe, Something wrong in my procedure.
I already read the instruction at
ftp://ftp.ppc.kernel.org/pub/linuxppc/embedded/getting_started.rpx
But I couldn't.
I really thank you, in advance.
Here's a snapshot of my MPC850/RPXLite board when downloading via tftp -
(You should see something similar):
RPX Load menu: press 123456789T key : <?> : 7
Load using tftp via Ethernet
Enter server IP address <C0A80059> :
Enter server filename <myzag> : myzah
Enter address offset : <00000000 hex> :
Starting tftp download:
inetARP(): OK
.1.2.4.8.16.32.64.128.256.512.1024.2048.4096
load_tftp(): OK
388970 data bytes, 4924 S-records, 760 tftp blocks, 0 repeated blocks
Once you have successfully loaded your kernel into RAM, ensure that the
start address is set to 0x0200000 (from Load Menu L, use '8 200000').
Then to start the execution, type '9 YES' <-- uppercase YES.
Hope this helps.... let me know how you go.. :-)
Cheers,
Rod
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Could you telll me what's difference between powerpc-linux-objcopy and zsrec?
I believe (but not sure) that zsrec discards the ELF header and uses it's
own image location assumptions. It's magic....and just works. ;-)
The zsrec source isn't too tough to look at if you really need to know.
Can we burn this S-record file into flash memory insead of loading into
memory? Some changes needed, doesn't it?
The quickest way to do this for the first time is to use the RPX utility
(RPXU) to:
1) Copy your kernel image to RAM using RPXU tftp
2) Use the RPXU flash program command to copy from RAM to flash
3) Use the RPXU to jump to your flash load address
The system/decompress/kernel initialization code is smart enough to figure
out where the image is located and then do the right thing. I'm not sure
who's responsible for that little piece of magic (Cort? Dan?), but it's
really pretty slick.
what is next step?
I read LDP(Linux Documentation Project). There are many choices to mount
root file system. NFS, initrd, ..? I really want to know how to mount
root file system.
You can mount the rootfs via network using a couple of methods:
1) use bootp/dhcp to let the kernel determine its network address and
nfsroot location
2) specify these parameters at the bootprompt.
Ramdisk rootfs isn't too tough either. Create your rootfs image (see
HOWTO), copy it to the arch/ppc/mbxboot directory as the file
ramdisk.image.gz and then do 'make zImage.initrd' at the kernel top level
directory. Now zsrec the resulting image, load it into the rpx, run it
and specify 'root=/dev/ram' on the boot prompt (or modify misc.c to use
the appropriate default). You'll need to make sure your rootfs isn't
larger than 4MB. If it is you'll need to add the 'ramdisk_size' parameter
to your bootstring.
One caveat: Once you add a ramdisk, your srec image will probably be too
large to successfully tftp due to a limitation of the RPXU. Use the
'split -C' command to make it into several smaller files and load each one
separately.
-Mark
Mark S. Mathews
AbsoluteValue Systems Web: http://www.absoval.com
P.O. Box 941149 e-mail: mark@absoval.com
Maitland, FL 32794-1149 Phone: 407.644.8582
USA Fax: 407.539.1294
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
"Mark S. Mathews" wrote:
I believe (but not sure) that zsrec discards the ELF header and uses it's
own image location assumptions. It's magic....and just works. ;-)
The zsrec source isn't too tough to look at if you really need to know.
It's not magic, I was just too lazy to find all of the objcopy
parameters that would do the same thing :-). The "magic" (which has
been recently broken for some targets in 2.3.99) is in the zImage.
The zImage is a 64K ELF header (which should be discarded) followed by
a simple relocate/uncompress set of functions with a compressed kernel
and optional compressed ram disk packed against these functions. There
are some assumptions built into these functions, and externally you should
not try to map any structure to this file. Strip the 64K header and
you just have a linear array of bits that can be safely loaded anywhere
at or above a 2 Mbyte address (5 Mbyte for 8260). Jump to the first
location and it will go. Other processor architectures follow this
model as well.
A very important note.....Because of the initrd logic in the Linux
kernel, you can't uncompress a ram disk from Flash rom, it must be
in RAM (pages are discarded when this is done). The "magic" functions
assume if loaded above 16 Mbytes, and a ram disk is attached, the
ram disk portion of the image must be copied to ram. If loading in
ram above 16 Mbytes this will result in an unnecessary copying of
the ram disk image, so it is probably best to load the image somewhere
below 16 Mbytes if in memory. There are lots of other assumptions
and "special" memory locations used within these functions to support
a variety of loading options on various boards and products. It is
best you realize this is a bunch of bits for production use and don't
try to modify it for something else. Lots of people depend on this
image as it is.
All zsrec does is skip the ELF header, then convert the remaining
bits to S-records with a base address you can specify. The default
base is 2M bytes because it was written for small memory 8xx systems.
Specifiy a different address with the -s start option, followed by
a hex base address. This is required for the 8260 zImage. Or better,
write your own program that can download/flash the binary without an
S-record conversion.
There are other programs (which I don't have but know other people do :-)
that will convert this zImage into binary formats supported by BDM/JTAG
download tools. Basically, just strip the ELF header and tack a
simple binary header to the top. Everyone (until recently) seemed
to like this approach because it was quick and easy, and there aren't
any symbols or other debug information that make this a useful ELF
image. It is also the most compact Flash ROM image that reduces the
requirements on that resource.
1) Copy your kernel image to RAM using RPXU tftp
2) Use the RPXU flash program command to copy from RAM to flash
3) Use the RPXU to jump to your flash load address
The file arch/ppc/mbxboot/misc.c contains an "RPX Signature" for
autoboot. There is an address you can modify that reflects the
actual load location in Flash rom. I chose to use FF840000 as that
is the first of the 256K sectors on a 8M Flash board. The smaller
sectors preceeding this location are used for the new RPX bootloader
or by existing products for non-volatile storage.
I believe all of this information (and more) is provided from Embedded
Planet and MontaVista as part of the Linux Planet development kit.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/