How to use vxworks bootloader to load monta vista linux kernel image?
Frank
I am now trying to use vxworks bootloader to load the
monta vista kernel. I used to use this bootloader to
load the vxworks image file and worked well. Now I
want to use the exact same bootloader and don't want
to change it even a little because I don't have a tool
to write the modified bootloader back into the flash
rom. If necessary, I can work on the monta vista
kernel. But before that, I have a couple of questions:
1. I got two files, one is called "vmlinux.gz" and the
other is called "vmlinux" after I compiled the kernel.
vmlinux is under directory $(Home)/linux-2.4.18_mvl30/
and vmlinux.gz is under directory
(Home)/linux-2.4.18_mvl30/arch/ppc/boot/images. I
found
that the vmlinux.gz is not the compressed version of
vmlinux. The size of the file I got by decompressing
vmlinux.gz is smaller the one of vmlinux. So what's
the difference between these two files? Are they all
mvista linux kernel image file? I tried to load both
of them
by vxworks bootloader, which I used to load vxworks
image, but neither of them has been successful. The
message I got from minicom is as below:
If I use file vmlinux
---------------------------
boot device : emac
unit number : 0
processor number : 0
host name : t40-xp
file name : vmlinux
inet on ethernet (e) : 137.31.3.200
host inet (h) : 137.31.3.40
user (u) : anonymous
ftp password (pw) :
flags (f) : 0x80
Attached TCP/IP interface to emac0.
Warning: no netmask specified.
Attaching network interface lo0... done.
Loading... 1561496
machine check
Exception next instruction address: 0x00c0ef8c
Machine Status Register: 0x00029200
Condition Register: 0x20482044
Bus Error Address Register: 0xc00001fc
Bus Error Syndrome Register: 0x08000000
Task: 0xf6e5a0 "tBoot"
r0 = 0 sp = f6d980 r2 = 0 r3 = f63df4
r4 = c00001fc r5 = 80 r6 = 0 r7 = 0
r8 = 0 r9 = 0 r10 = 0 r11 = 0
r12 = 0 r13 = 0 r14 = 0 r15 = 1
r16 = 1 r17 = f6da30 r18 = 0 r19 = 15031c
r20 = 0 r21 = c89f7c r22 = 0 r23 = 0
r24 = 0 r25 = 0 r26 = 0 r27 = f63bfc
r28 = 200 r29 = f6da00 r30 = f6da20 r31 = 200
msr = 29200 lr = c515d0 ctr = 7f pc = c0ef8c
cr = 20482044 xer = 0
..
--------------------------------------------
If I use file vmlinux.gz
--------------------------------------------
boot device : emac
unit number : 0
processor number : 0
host name : t40-xp
file name : vmlinux
inet on ethernet (e) : 137.31.3.200
host inet (h) : 137.31.3.40
user (u) : anonymous
ftp password (pw) :
flags (f) : 0x80
Attached TCP/IP interface to emac0.
Warning: no netmask specified.
Attaching network interface lo0... done.
Loading... Erroneous header read
Error loading file: errno = 0xffffffff.
Can't load boot file!!
.
-----------------------------------------
2. I check the bootrom source file of vxworks. In
bootConfig.c, function autoboot() calls bootload(),
bootload() calls netload() and netload() calls
bootLoadModule() in order to get a FUNCPTR. The
FUNCPTR is a function pointer to the entry of the
image. Since bootLoadModule() is implemented as one of
the lib function, I couldn't see its source code. I
don't know how bootLoadModule() gets the entry pointer
to the image. To load mvista linux image by this
bootloader, I think the bootLoadModule() needs to
return the entry point of mvista linux image. But what
should I do to link the bootLoadModule() and the entry
point of the mvista linux image?
3. Vxworks use ELF as a file format. How can I change
*.gz or uncompressed file to ELF file?
I would appreciate any of your advice. Thanks a lot!
Best regards,
Frank
Michael Schnell
that their tools are helpful when porting VxWorks Projects to Linux.
-Michael
John
> 1. I got two files, one is called "vmlinux.gz" and the
> other is called "vmlinux" after I compiled the kernel.
> vmlinux is under directory $(Home)/linux-2.4.18_mvl30/
> and vmlinux.gz is under directory
> (Home)/linux-2.4.18_mvl30/arch/ppc/boot/images. I
> found
> that the vmlinux.gz is not the compressed version of
> vmlinux. The size of the file I got by decompressing
> vmlinux.gz is smaller the one of vmlinux. So what's
> the difference between these two files? Are they all
> mvista linux kernel image file? I tried to load both
> of them
> by vxworks bootloader, which I used to load vxworks
> image, but neither of them has been successful. The
> message I got from minicom is as below:
They are both kernel files, but they are different formats (one is
ELF, one is raw binary, compressed). The vmlinux.gz file you are
looking at is most probably an intermediate file (the payload for the
decompressor). The vmlinux file you are looking at is the uncompressed
kernel.
You probably want a third file, most likely in the arch/ppc/boot
directory, that is the result of the combination of the vmlinux.gz and
a small decompressor. I don't know PPC Linux well enough to tell for
sure what it is called, but in my XScale Linux tree is called
arch/arm/boot/compressed/vmlinux.
> If I use file vmlinux
> ---------------------------
> boot device : emac
> unit number : 0
> processor number : 0
> host name : t40-xp
> file name : vmlinux
> inet on ethernet (e) : 137.31.3.200
> host inet (h) : 137.31.3.40
> user (u) : anonymous
> ftp password (pw) :
> flags (f) : 0x80
>
>
>
> Attached TCP/IP interface to emac0.
> Warning: no netmask specified.
> Attaching network interface lo0... done.
> Loading... 1561496
> machine check
> Exception next instruction address: 0x00c0ef8c
> Machine Status Register: 0x00029200
> Condition Register: 0x20482044
> Bus Error Address Register: 0xc00001fc
> Bus Error Syndrome Register: 0x08000000
> Task: 0xf6e5a0 "tBoot"
OK, in this case you simply overwrote the boot loader with the image.
You need to get the locations in sync (much like you do when booting
VxWorks). I would suggest using readelf to get the link address of the
VxWorks kernel ELF file, then making sure that the compressed Linux
kernel is linked at that same address. The addresses for the
compressed image are normally specified in the Makefile in the 'boot'
directory (so they are in arch/arm/boot/Makefile for my XScale board).
> 2. I check the bootrom source file of vxworks. In
> bootConfig.c, function autoboot() calls bootload(),
> bootload() calls netload() and netload() calls
> bootLoadModule() in order to get a FUNCPTR. The
> FUNCPTR is a function pointer to the entry of the
> image. Since bootLoadModule() is implemented as one of
> the lib function, I couldn't see its source code. I
> don't know how bootLoadModule() gets the entry pointer
> to the image. To load mvista linux image by this
> bootloader, I think the bootLoadModule() needs to
> return the entry point of mvista linux image. But what
> should I do to link the bootLoadModule() and the entry
> point of the mvista linux image?
The address is extracted from the ELF header - it is the address you
linked the kernel at during the build process. See the output of
readelf for information about what is in this header.
> 3. Vxworks use ELF as a file format. How can I change
> *.gz or uncompressed file to ELF file?
While you can do it, it is probably not what you want. See comments
above for the correct way to get the compressed ELF version of the
kernel.
HTH,
John...
=====
Contribute to the VxWorks Cookbook at: http://books.bluedonkey.org/
Chuck Gales
Frank,
The unmodified VxWorks bootloader will not be able to load linux kernel
images. This is due to several reasons which you are finding out.
- vmlinux is indeed an ELF image, which is targeted to load at address
0xC0000000 (if you analyze the ELF header, you will see this). However,
due to the MMU and other initializations done by the kernel, it is
physically loaded at memory address 0x00000000. When the kernel is
started by passing control to 0x00000000, it initializes the MMU and
'relocates' itself automatically to 0xC0000000.
- Additionally, the vmlinux image requires certain registers set to
receive the specified kernel parameters (any other kernel options set at
boot time.
- Any other image you find (vmlinux.gz) is usually a compressed image
used by various other bootloaders. Since the standalone ELF image is not
very space efficient, the kernel build procedure will typically compress
them and add other information necessary for loading. Typically, the
kernel for PPC will support PPCBoot/U-Boot as the default bootloader.
Read the BSP documentation from MontaVista and they will tell you which
bootloader is normally targeted.
Your only options is to compile U-Boot or another similar Linux bootloader
and load it on the board, or modify the VxWorks bootloader to read the
compressed kernel image, parse the required image and load it
appropriately.
Hope this helps.
Chuck
John
> The unmodified VxWorks bootloader will not be able to load linux kernel
> images. This is due to several reasons which you are finding out.
>
> - vmlinux is indeed an ELF image, which is targeted to load at address
> 0xC0000000 (if you analyze the ELF header, you will see this).
Hmmm... the address actually depends on the CPU and even in some cases
the board. You cannot assume that it will always be that address. For
most of the non-x86 compressed kernels, that is not the address it
will load at (even if it is the virtual address that the final kernel
image will run at).
> However,
> due to the MMU and other initializations done by the kernel, it is
> physically loaded at memory address 0x00000000. When the kernel is
> started by passing control to 0x00000000, it initializes the MMU and
> 'relocates' itself automatically to 0xC0000000.
Again, those addresses are arch and board specific (actually, they
look like x86 numbers to me).
> - Additionally, the vmlinux image requires certain registers set to
> receive the specified kernel parameters (any other kernel options set at
> boot time.
Also not true on many non-x86 kernels that are designed to be booted
with all kinds of boot loaders. Some do indeed require these
parameters, others do not. In almost all cases it is possible to
bypass the parameter passing in the head.S file for the architecture
and set the default command line at build time. I do this every day on
XScale and MIPS systems (the latter booting without any boot loader!).
> - Any other image you find (vmlinux.gz) is usually a compressed image
> used by various other bootloaders. Since the standalone ELF image is not
> very space efficient, the kernel build procedure will typically compress
> them and add other information necessary for loading. Typically, the
> kernel for PPC will support PPCBoot/U-Boot as the default bootloader.
> Read the BSP documentation from MontaVista and they will tell you which
> bootloader is normally targeted.
Porting a boot loader is probably not a bad idea since shipping with
the VxWorks one installed would technically require you to pay them a
VxWorks runtime license - the bootrom is a VxWorks kernel image.
> Your only options is to compile U-Boot or another similar Linux bootloader
> and load it on the board, or modify the VxWorks bootloader to read the
> compressed kernel image, parse the required image and load it
> appropriately.
I can tell you that you can boot Linux using a VxWorks boot loader. It
has been done on several architectures (and I have done it in the past
on a PPC860, though I cannot remember the exact details of what needed
to be changed, it was not much - the load address of the compressed
image and that was it I think).
Chuck Gales
> Hello,
>
>> The unmodified VxWorks bootloader will not be able to load linux kernel
>> images. This is due to several reasons which you are finding out.
>>
>> - vmlinux is indeed an ELF image, which is targeted to load at address
>> 0xC0000000 (if you analyze the ELF header, you will see this).
>
> Hmmm... the address actually depends on the CPU and even in some cases the
> board. You cannot assume that it will always be that address. For most of
> the non-x86 compressed kernels, that is not the address it will load at
> (even if it is the virtual address that the final kernel image will run
> at).
>
Most load addresses are CPU/Architecture specific. While it is possible
that a user might change this, since it is typically dependant on the MMU
mappings, it is not commonly done.
>> However,
>> due to the MMU and other initializations done by the kernel, it is
>> physically loaded at memory address 0x00000000. When the kernel is
>> started by passing control to 0x00000000, it initializes the MMU and
>> 'relocates' itself automatically to 0xC0000000.
>
> Again, those addresses are arch and board specific (actually, they look
> like x86 numbers to me).
>
Per the /arch/ppc/Makefile, KERNELLOAD =0xc0000000, which is used in the
final link stage: -Ttext $(KERNELLOAD)
>> - Additionally, the vmlinux image requires certain registers set to
>> receive the specified kernel parameters (any other kernel options set at
>> boot time.
>
> Also not true on many non-x86 kernels that are designed to be booted with
> all kinds of boot loaders. Some do indeed require these parameters, others
> do not. In almost all cases it is possible to bypass the parameter passing
> in the head.S file for the architecture and set the default command line
> at build time. I do this every day on XScale and MIPS systems (the latter
> booting without any boot loader!).
>
True. However, having a bootloader does allow flexibility if desired.
>> - Any other image you find (vmlinux.gz) is usually a compressed image
>> used by various other bootloaders. Since the standalone ELF image is
>> not very space efficient, the kernel build procedure will typically
>> compress them and add other information necessary for loading.
>> Typically, the kernel for PPC will support PPCBoot/U-Boot as the default
>> bootloader. Read the BSP documentation from MontaVista and they will
>> tell you which bootloader is normally targeted.
>
> Porting a boot loader is probably not a bad idea since shipping with the
> VxWorks one installed would technically require you to pay them a VxWorks
> runtime license - the bootrom is a VxWorks kernel image.
>
>> Your only options is to compile U-Boot or another similar Linux
>> bootloader and load it on the board, or modify the VxWorks bootloader to
>> read the compressed kernel image, parse the required image and load it
>> appropriately.
>
> I can tell you that you can boot Linux using a VxWorks boot loader. It has
> been done on several architectures (and I have done it in the past on a
> PPC860, though I cannot remember the exact details of what needed to be
> changed, it was not much - the load address of the compressed image and
> that was it I think).
>
Talking with a friend, we determined that it is possible to write some
"loader" code with which to wrap the flat binary image. If you combine
the loader code with the compressed kernel image, you can use the loader
code to uncompress the kernel to the correct location and then pass
control to the kernel. You just need to make sure that you understand
where in memory you are moving code to and that you are not overwriting
anything important.
> HTH,
> John...
>
> =====
> Contribute to the VxWorks Cookbook at: http://books.bluedonkey.org/
Good luck,
Chuck
karthik bala guru
karthik bala guru
John <john_...@yahoo.com> wrote:
Hello,
HTH,
John...
_______________________________________________
VxWorks Users Group mailing list
VxWe...@lbl.gov
http://www-csg.lbl.gov/vxworks/
---------------------------------
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
Steven Rostedt
> Frank,
>
> Your only options is to compile U-Boot or another similar Linux bootloader
> and load it on the board, or modify the VxWorks bootloader to read the
> compressed kernel image, parse the required image and load it
> appropriately.
>
> Hope this helps.
>
I have successfully loaded linux kernels using an unmodified vxWorks
boot loader for both mips and PPC. The trick is to make a zImage.bin, a
compressed image in binary format that knows how to relocate and
decompress the kernel. It's not to hard to make one (with the help of
objcopy). I don't remember the mips version to well, but I do remember
the PPC. It does a relative linked branched, then uses the link register
to find where it is, then moves itself to where it needs to be if it
isn't there already. Then uncompresses the kernel and then happily jumps
to there. So I wouldn't recommend modifying the boot loader, although I
might recommend replacing it with U-Boot, since that is a much better
loader anyway.
-- Steve
Frank
It is great to know that you have successfully loaded linux image by
vxworks boot loader. I am using PPC too so your information is
extremely useful to me. Could you give me some more detailed
instructions? Such as how to make a zImage.bin? What format is used to
compress the binary? How to include a decompressor in the image file?
I checked the vxwork kernel, the entry address is 0x10000 and it
works. While linux uses 0xc0000000 as entry address. Does that mean I
should simply change the entry address from 0xc0000000 to 0x10000? I
used command
"objcopy --start-address 0x10000 vmlinux zImage.bin" but it does look
like right cause when the boot loader tried to load zImage.bin created
by objcopy, it shows error as below:
===========================
Attached TCP/IP interface to emac0.
Warning: no netmask specified.
Attaching network interface lo0... done.
Loading... Erroneous header read
Error loading file: errno = 0xffffffff.
Can't load boot file!!
.
===========================
I guess the format of zImage.bin is not right so the bootload couldn't
recognize it. So what is the right way to create a zImage.bin?
Thanks a lot for your help!
Frank
Steven Rostedt <ros...@SPAMgoodmis.org> wrote in message news:<c40o37$heu$1...@news.mch.sbs.de>...
John W. Linville
> recognize it. So what is the right way to create a zImage.bin?
Frank,
Please review the last e-mail response I sent to you.
John
--
John W. Linville
linv...@tuxdriver.com
Steven Rostedt
> "objcopy --start-address 0x10000 vmlinux zImage.bin" but it does look
> like right cause when the boot loader tried to load zImage.bin created
> by objcopy, it shows error as below:
Hi Frank,
No, no, no, you don't want to do that (But you already know that :-)
If you want to see how it's done, goto www.timesys.com, select
"Free Downloads" then select "PowerPC", then take your pick. You may
have to fill out some forms though, but you don't have to pay
anything. I believe they all should hold code to create a zImage.bin.
The file will end up in arch/ppc/boot/images directory. Their kernel
may not be what you want, but you will be able to learn how to make
a zImage.bin from it.
Hint, start with the target zImage.bin in arch/ppc/boot/Makefile. You
will also need to know about the mkimage utility that is in
arch/ppc/boot/utils. This should give you everything you need to
know to get a image running with the vxWorks boot loader.
Another hint, take a look at arch/ppc/boot/simple/head.S and friends.
Hope this helps,
-- Steve
Steven Rostedt
objcopy -O binary vmlinux zImage.bin
You don't want to change the addresses that vmlinux uses,
you only want to make it into a binary since vxWorks doesn't
handle elf.
But this will be a large file and the zImage.bin uses a compressed
image that is much smaller and quicker to load.
Just to let you know what is happening.
The zImage.bin is a binary file created from an exec that
is not the kernel. This program has its own head.S and has
the compressed kernel linked into it as a data object. The
zImage program is made to run with out the MMU on, so it runs
in a flat memory space just like vxWorks. Now vxWorks boot
loader will copy it somewhere and then jump to it. The first
thing that zImage does is to find out where it is (bl then
mflr r3), and with that it relocates itself somewhere, (I
think at the 8 meg part) out of the way from where it will
place the kernel, but in some location that it can start
running C code that needs to know where it is. Then
it uncompresses the kernel down into physical address 0x00000000.
And finally it jumps to the kernel, and the kernel takes over.
And yes, PPC expects the kernel virtual address to be at
0xC0000000, but when the code jumps to the kernel, the kernel
will know that the MMU is off, or it will turn it off, and
the kernel will map itself where it should be. There's even
code in the kernel to map itself to the right physical place
too, and that is why the objcopy above should also work,
but with a long transfer time.
Now this may not be the case for all PPC architectures. For
instance, the 440 IIRC or one of the other IBM chips, has
the MMU always on and you can't turn it off. What a pain in
the ass that was!
-- Steve
Frank
Should it be a ELF format? As I remembered, the vxworks kernel image
is stored as an ELF format...
I followed your instruction and get a zImage.bin by objcopy. But the
file size is even smaller than the vmlinux. Vmlinux is about 1.7M
while zImage.bin is about 1.3M. When I tried to load the zImage.bin
with vxworks boot loader, I got same error message:
==================
Attached TCP/IP interface to emac0.
Warning: no netmask specified.
Attaching network interface lo0... done.
Loading... Erroneous header read
Error loading file: errno = 0x610001.
Can't load boot file!!
.
==================
When I tried to make the kernel, I notice the last few commands are as
below:
=====================================
ppc_405-objcopy -O elf32-powerpc \
--add-section=.image=../images/vmlinux.gz \
--set-section-flags=.image=contents,alloc,load,readonly,data \
../common/dummy.o image.o
ppc_405-ld -T ../ld.script -Ttext 0x00400000 -Bstatic -o zvmlinux
head.o ../common/relocate.o misc-embedded.o ../common/misc-common.o
../common/string.o ../common/util.o embed_config.o ../common/ns16550.o
image.o ../lib/zlib.a
ppc_405-objcopy -O elf32-powerpc zvmlinux zvmlinux -R .comment -R
.stab -R .stabstr \
-R .ramdisk -R .sysmap
../utils/mktree zvmlinux ../images/zImage.treeboot
rm -f zvmlinux
make[2]: Leaving directory
`/home/yang/work/linux-2.4.18_mvl30/arch/ppc/boot/simple'
make[1]: Leaving directory
`/home/yang/work/linux-2.4.18_mvl30/arch/ppc/boot'
=========================================
What does "-Ttext 0x00400000" means? Is 0x00400000 an entry address?
But if I use readelf to read vmlinux, the entry address is still
0xc0000000. What happened here?
BTW, I am using PPC405. Is the the chip that always turns MMU on?
Thanks!
Frank
Steven Rostedt <ros...@SPAMgoodmis.org> wrote in message news:<c4c304$j80$1...@news.mch.sbs.de>...
Steven Rostedt
> I am a little puzzled... Can vxworks boot loader load binary kernel?
> Should it be a ELF format? As I remembered, the vxworks kernel image
> is stored as an ELF format...
>
OK, That may be the case, since it's been a while since I used the
vxWorks boot loader. I've used several and some needed an elf and some
needed a binary file. So if vxworks boot loader needs an elf then you
have to get a zImage file (not zImage.bin). This file will do
evreything that I mentioned before (decompress kernel, etc), but it will
be loaded as an elf file. This zImage needs to be linked to someplace
that the vxworks loader can link it to. You can't use the kernel
directly in this case since the kernel must be linked in 0xc0000000,
With a two step case (zImage to kernel), the zImage is linked
separately. It is possible to do, I've done it, but you need to know how
the zImage part works, and that is in the arch/ppc/boot directory.
Good luck,
-- Steve
Frank
head. I linked it with the compressed vmlinux image and then put it in
an ELF format. The entry address I set is 0x10000. When I tried to
start, I got this screen output:
"Attached TCP/IP interface to emac0.
Warning: no netmask specified.
Attaching network interface lo0... done.
Starting at 0x10000..."
Then nothing happened after that. The linux didn't come up. I think
the entry of the file has been correctly located but somehow it
couldn't decompress the linux file and put it in a correct address.
What could happen here and how should I debug it? Can I get some print
out information on the screen to monitor what is going on?
Thanks!
Frank
youn...@yahoo.com (Frank) wrote in message news:<620b1276.04033...@posting.google.com>...
Steven Rostedt
And congratulations on your success, and welcome to the world of porting
Linux. There's not much I can help you with now, its all about
knowing the board. What I would do next is, if a UART is available
(which I would assume is, since you're working with vxWorks boot
loader), write a small program that outputs to the UART, and put that
at the beginning of the zImage head.S. Output an 'x' and see if it
shows up when you load your program, if it does, keep moving it down and
that's when you have the fun of finding out what to do next. Once you
get it to jump to C code, it becomes a lot easier.
Good luck and have fun.
-- Steve
Frank
it. Could you give several line of codes to show as an example?
When you booted the linux kernel successfully, did you change the
source code and rebuild it to make it work?
Thanks a lot!
Frank
Steven Rostedt <ros...@SPAMgoodmis.org> wrote in message news:<6u3bc.618$Zu4...@twister.nyroc.rr.com>...
karthik bala guru
First find the address of the UART.
Then select ur uart using that address.
Then calculate the internal uart registers w.r.t the uart address.
Set the bit length after setting the bit in LCR
Set the baud rate in DLL,DLM after setting the corresponding bit in LCR
Set the IER
Then check the THR for the reception and transmission of data accordingly.
Thus ur uart can now receive and tranmit data @ ur desired baudrate.
Refer Ur UART datasheet.Cheeers !!
regards,
karthik bala guru
Frank <youn...@yahoo.com> wrote:
Yes, my board has UART available. But I am not sure how to program on
it. Could you give several line of codes to show as an example?
When you booted the linux kernel successfully, did you change the
source code and rebuild it to make it work?
Thanks a lot!
Frank
Steven Rostedt wrote in message news:<6u3bc.618$Zu4...@twister.nyroc.rr.com>...
> Hi Frank,
>
> And congratulations on your success, and welcome to the world of porting
> Linux. There's not much I can help you with now, its all about
> knowing the board. What I would do next is, if a UART is available
> (which I would assume is, since you're working with vxWorks boot
> loader), write a small program that outputs to the UART, and put that
> at the beginning of the zImage head.S. Output an 'x' and see if it
> shows up when you load your program, if it does, keep moving it down and
> that's when you have the fun of finding out what to do next. Once you
> get it to jump to C code, it becomes a lot easier.
>
> Good luck and have fun.
>
> -- Steve
_______________________________________________
VxWorks Users Group mailing list
VxWe...@lbl.gov
http://www-csg.lbl.gov/vxworks/
---------------------------------
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway - Enter today
Steven Rostedt
> Yes, my board has UART available. But I am not sure how to program on
> it. Could you give several line of codes to show as an example?
>
I'll give you an example of an idea, but anything else is boardering on
contracting, and I do charge :-)
The uart is very specific to boards, and you really should know how to
program one. It's been a while since I needed to, and since I don't have
a PPC board available with me, I don't assume this code will work
(untested). But it will give you an idea.
#define UART_BASE 0xf40003f8 // This must match where the UART register
is (physical address). Don't use this number, it's from another board I
once worked on.
#define UART_REGSHIFT 0 // This may be 0 - 3 depending on how far the
UART registers are from each other (byte aligned to 64 bit alligned
#define UART_LSR 5
#define UART_TX 0
#define TX (UART_TX << UART_REGSHIFT)
#define LSR (UART_LSR << UART_REGSHIFT)
#define UART_LSR_TEMT 0x40
#define UART_LSR_THRE 0x20
#define BOTH_EMPTY (UART_LSR_TEMT | UART_LSR_THRE)
lis r17, UART_BASE@h
ori r17,r17, UART_BASE@l
1: lbz r18,LSR(r17)
andi. r18,r18,BOTH_EMPTY
bne 1b
li r18, 'x'
stb r18, TX(r17)
This also depends a lot on the board and what vxWorks boot monitor does
to the uart before it calls the code. Hopefully it doesn't reset it. And
this is assuming that you have a standard 16550 uart.
Note, that the above code also assumes that the MMU is off, since it
uses physical addresses, as well as cache, since that may make this loop
forever.
> When you booted the linux kernel successfully, did you change the
> source code and rebuild it to make it work?
>
I use to port kernels to different boards, so that means that I did a
lot to the kernel to get it running. Not just some tweaks here and
there. Sometimes, that's all it took, others I had to rewrite the PCI
layer. It all depends on how standard the board is to what is already
out there.
-- Steve
Steven Rostedt
untested.
Steven Rostedt wrote:
>
> lis r17, UART_BASE@h
> ori r17,r17, UART_BASE@l
> 1: lbz r18,LSR(r17)
> andi. r18,r18,BOTH_EMPTY
cmpi 0,r18,BOTH_EMPTY
Frank
Frank
Steven Rostedt <ros...@SPAMgoodmis.org> wrote in message news:<Y7gcc.1250$aE2...@twister.nyroc.rr.com>...