[U-Boot] mpc83xx U-boot questions
Dear all,
I am new to U-boot. I have a mpc8313erdb board that already has U-boot burned in flash. When the board reset, I get into U-boot (with U-boot prompt =>). My questions is: my gcc compiler produce a .exe file, can I just tftp this file to an address and run it (go) ? Or I need to convert it to some format (use mkimage) to run it ?
Does the load address and entry address matters ? Does anyone happen to know what is the correct load address for this board ? One more question, where do I get the mkimage for this board ?
Thank you in advance for your response.
Yuke Tian Brookhaven National Lab Upton, NY 11790 Tel:631-344-2872
Hi Yuke,
I am new to U-boot. I have a mpc8313erdb board that already has U-boot burned in flash. When the board reset, I get into U-boot (with U-boot prompt =>). My questions is: my gcc compiler produce a .exe file, can I just tftp this file to an address and run it (go) ? Or I need to convert it to some format (use mkimage) to run it ?
Does the load address and entry address matters ? Does anyone happen to know what is the correct load address for this board ? One more question, where do I get the mkimage for this board ?
New to U-Boot and embedded systems, eh?
If your gcc compiler is producing a .exe file, then you sound like you are working on a Windows machine, with say Cygwin. That particular version of gcc is for the *Windows OS* and the *Intel architecture*.
The gcc compiler can be built for a specific processor type and OS. The Denx ELDK has a prebuilt version of gcc for the PowerPC on the MPC8313 that can be used to build both U-boot, stand-alone, and Linux applications. You would typically install the ELDK on a Linux machine (eg. an Intel-based laptop/desktop).
You'll probably want to get yourself a copy of
"Building Embedded Linux Systems", K. Yagmour, O'Reilly.
and read it to learn some of the basics of embedded programming, and cross-platform development.
If you want to run an executable from U-Boot, then you'll want to read the 'stand-alone applications' section of the DULG.
http://www.denx.de/wiki/DULG/WebHome
But if what you really want is a Linux application, then U-Boot will be used to boot Linux, and then your application will run under Linux.
If you let us know exactly what you want your program to do, we can suggest the path of least-resistance for you.
Cheers, Dave
Hi David,
Thank you for your kind response. What I am doing is to try to load the RTEMS (a kind of open source real time operating system) image to the board. It has a BSP for this board. All the tools I used are targeting powerpc and tailed for this board. But the final executable format is .exe. I am not sure if this format is good to download and run on the board using U-boot. I just happen to know there is a mkimage utility from U-boot.
Thank you,
Yuke
David Hawkins wrote:
Hi Yuke,
I am new to U-boot. I have a mpc8313erdb board that already has U-boot burned in flash. When the board reset, I get into U-boot (with U-boot prompt =>). My questions is: my gcc compiler produce a .exe file, can I just tftp this file to an address and run it (go) ? Or I need to convert it to some format (use mkimage) to run it ?
Does the load address and entry address matters ? Does anyone happen to know what is the correct load address for this board ? One more question, where do I get the mkimage for this board ?
New to U-Boot and embedded systems, eh?
If your gcc compiler is producing a .exe file, then you sound like you are working on a Windows machine, with say Cygwin. That particular version of gcc is for the *Windows OS* and the *Intel architecture*.
The gcc compiler can be built for a specific processor type and OS. The Denx ELDK has a prebuilt version of gcc for the PowerPC on the MPC8313 that can be used to build both U-boot, stand-alone, and Linux applications. You would typically install the ELDK on a Linux machine (eg. an Intel-based laptop/desktop).
You'll probably want to get yourself a copy of
"Building Embedded Linux Systems", K. Yagmour, O'Reilly.
and read it to learn some of the basics of embedded programming, and cross-platform development.
If you want to run an executable from U-Boot, then you'll want to read the 'stand-alone applications' section of the DULG.
http://www.denx.de/wiki/DULG/WebHome
But if what you really want is a Linux application, then U-Boot will be used to boot Linux, and then your application will run under Linux.
If you let us know exactly what you want your program to do, we can suggest the path of least-resistance for you.
Cheers, Dave
Hi Yuke,
What I am doing is to try to load RTEMS
Ok, that info helps.
It has a BSP for this board.
Thats good.
All the tools I used are targeting powerpc and tailed for this board.
and those tools came from where?
But the final executable format is .exe. I am not sure if this format is good to download and run on the board using U-boot. I just happen to know there is a mkimage utility from U-boot.
Given a file test.exe, type
file test.exe
and it'll tell you if its a PowerPC .elf format.
Before trying to get RTEMs running on the board, see if your tools can build U-Boot, and build the standard stand-alone application that exists in the examples folder.
Here's some notes I wrote a while back for the 8349, which is in the same family as the 8313;
http://www.ovro.caltech.edu/~dwh/carma_board/powerpc_mpc8349e.pdf
Cheers, Dave
Yuke Tian wrote:
Hi David,
Thank you for your kind response. What I am doing is to try to load the RTEMS (a kind of open source real time operating system) image to the board. It has a BSP for this board. All the tools I used are targeting powerpc and tailed for this board. But the final executable format is .exe. I am not sure if this format is good to download and run on the board using U-boot. I just happen to know there is a mkimage utility from U-boot.
1) You need to do a lot of reading: books - see below - and on-line documentation such as http://www.denx.de/wiki/U-Boot/Documentation. Also the RTEMS documentation http://www.rtems.com/wiki/index.php/Quick_Start http://www.rtems.com/onlinedocs.html You have to have some fundamental knowledge before you can ask questions that we can answer.
Note that you aren't the first to ask the question you started out with, see the README file: http://git.denx.de/?p=u-boot.git;a=blob;f=README;h=ccd839ca25828c2be9d2ac576259b443d0704792;hb=HEAD#l3859
2) Some (idiot) tools create non-Windows binary executables as .exe files. This is nonstandard in terms of Windows executables and is nonstandard in terms non-Windows executables. As a result, we cannot say *anything* about your question WRT your gcc compiler producing a .exe file.
If you list/dump/edit the .exe file, are the first three bytes the characters "ELF"? If so, it isn't a Windows executable, but we still don't know much about what it *is.* If it doesn't say "ELF", it may be a Windows executable and is useless for your purposes, or it may be a raw binary file, but we still don't know much about what it *is.*
3) Your description of your toolset totally inadequate. Who made it? Where did it come from? How do you know it is a cross-PPC compiler? What version of gcc is it? What is your host? Windows? Windows+cygwin? Linux? BSD? OSX? Solaris?
It sounds like you need to be asking questions of your toolset provider (company if commercial), subscribe to the toolset's email list, and RTEMS email lists. http://www.rtems.com/wiki/index.php/RTEMSMailingLists
Good luck, gvb
Thank you,
Yuke
David Hawkins wrote:
Hi Yuke,
I am new to U-boot. I have a mpc8313erdb board that already has U-boot burned in flash. When the board reset, I get into U-boot (with U-boot prompt =>). My questions is: my gcc compiler produce a .exe file, can I just tftp this file to an address and run it (go) ? Or I need to convert it to some format (use mkimage) to run it ?
Does the load address and entry address matters ? Does anyone happen to know what is the correct load address for this board ? One more question, where do I get the mkimage for this board ?
New to U-Boot and embedded systems, eh?
If your gcc compiler is producing a .exe file, then you sound like you are working on a Windows machine, with say Cygwin. That particular version of gcc is for the *Windows OS* and the *Intel architecture*.
The gcc compiler can be built for a specific processor type and OS. The Denx ELDK has a prebuilt version of gcc for the PowerPC on the MPC8313 that can be used to build both U-boot, stand-alone, and Linux applications. You would typically install the ELDK on a Linux machine (eg. an Intel-based laptop/desktop).
You'll probably want to get yourself a copy of
"Building Embedded Linux Systems", K. Yagmour, O'Reilly.
and read it to learn some of the basics of embedded programming, and cross-platform development.
If you want to run an executable from U-Boot, then you'll want to read the 'stand-alone applications' section of the DULG.
http://www.denx.de/wiki/DULG/WebHome
But if what you really want is a Linux application, then U-Boot will be used to boot Linux, and then your application will run under Linux.
If you let us know exactly what you want your program to do, we can suggest the path of least-resistance for you.
Cheers, Dave
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Hi,
Sorry to ask the stupid question. I did study the RTEMS for a while and am sure the tool set are correct (from ftp://www.rtems.com), otherwise they will not build RTEMS. All the tools and development are done in linux (RHLE5). I just got this board using U-boot and not sure about it. David's manual help a lot. Thanks.
Yuke
Jerry Van Baren wrote:
Yuke Tian wrote:
Hi David,
Thank you for your kind response. What I am doing is to try to load the RTEMS (a kind of open source real time operating system) image to the board. It has a BSP for this board. All the tools I used are targeting powerpc and tailed for this board. But the final executable format is .exe. I am not sure if this format is good to download and run on the board using U-boot. I just happen to know there is a mkimage utility from U-boot.
- You need to do a lot of reading: books - see below - and on-line
documentation such as http://www.denx.de/wiki/U-Boot/Documentation. Also the RTEMS documentation http://www.rtems.com/wiki/index.php/Quick_Start http://www.rtems.com/onlinedocs.html You have to have some fundamental knowledge before you can ask questions that we can answer.
Note that you aren't the first to ask the question you started out with, see the README file: http://git.denx.de/?p=u-boot.git;a=blob;f=README;h=ccd839ca25828c2be9d2ac576259b443d0704792;hb=HEAD#l3859
- Some (idiot) tools create non-Windows binary executables as .exe
files. This is nonstandard in terms of Windows executables and is nonstandard in terms non-Windows executables. As a result, we cannot say *anything* about your question WRT your gcc compiler producing a .exe file.
If you list/dump/edit the .exe file, are the first three bytes the characters "ELF"? If so, it isn't a Windows executable, but we still don't know much about what it *is.* If it doesn't say "ELF", it may be a Windows executable and is useless for your purposes, or it may be a raw binary file, but we still don't know much about what it *is.*
- Your description of your toolset totally inadequate. Who made it?
Where did it come from? How do you know it is a cross-PPC compiler? What version of gcc is it? What is your host? Windows? Windows+cygwin? Linux? BSD? OSX? Solaris?
It sounds like you need to be asking questions of your toolset provider (company if commercial), subscribe to the toolset's email list, and RTEMS email lists. http://www.rtems.com/wiki/index.php/RTEMSMailingLists
Good luck, gvb
Thank you,
Yuke
David Hawkins wrote:
Hi Yuke,
I am new to U-boot. I have a mpc8313erdb board that already has U-boot burned in flash. When the board reset, I get into U-boot (with U-boot prompt =>). My questions is: my gcc compiler produce a .exe file, can I just tftp this file to an address and run it (go) ? Or I need to convert it to some format (use mkimage) to run it ?
Does the load address and entry address matters ? Does anyone happen to know what is the correct load address for this board ? One more question, where do I get the mkimage for this board ?
New to U-Boot and embedded systems, eh?
If your gcc compiler is producing a .exe file, then you sound like you are working on a Windows machine, with say Cygwin. That particular version of gcc is for the *Windows OS* and the *Intel architecture*.
The gcc compiler can be built for a specific processor type and OS. The Denx ELDK has a prebuilt version of gcc for the PowerPC on the MPC8313 that can be used to build both U-boot, stand-alone, and Linux applications. You would typically install the ELDK on a Linux machine (eg. an Intel-based laptop/desktop).
You'll probably want to get yourself a copy of
"Building Embedded Linux Systems", K. Yagmour, O'Reilly.
and read it to learn some of the basics of embedded programming, and cross-platform development.
If you want to run an executable from U-Boot, then you'll want to read the 'stand-alone applications' section of the DULG.
http://www.denx.de/wiki/DULG/WebHome
But if what you really want is a Linux application, then U-Boot will be used to boot Linux, and then your application will run under Linux.
If you let us know exactly what you want your program to do, we can suggest the path of least-resistance for you.
Cheers, Dave
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Hi Yuke,
Sorry to ask the stupid question. I did study the RTEMS for a while and am sure the tool set are correct (from ftp://www.rtems.com), otherwise they will not build RTEMS. All the tools and development are done in linux (RHLE5). I just got this board using U-boot and not sure about it. David's manual help a lot. Thanks.
Its not that the questions are stupid, its that they lack information sufficient to help you. For example, the toolset ... readers of the list are busy, so expecting us to follow links and try to interpret which toolset you have installed is not going to happen. Its better to say, "I got the tool from this link ...' and it provided powerpc-linux-gcc version XXX, etc., and then what you've managed to succeed to do with the tools.
You say that the development is done with RHLE5, but then that a .exe is created. That seems to be a conflicting statement. Perhaps you could explain ... are you running the RTEMs tools under Wine??
Anyway, a good suggestion is to install ELDK and rebuild U-Boot and update it, even get Linux booted. It may not be your main goal, but consider it educational :)
Cheers, Dave
David Hawkins wrote:
Hi Yuke,
[snip]
You say that the development is done with RHLE5, but then that a .exe is created. That seems to be a conflicting statement. Perhaps you could explain ... are you running the RTEMs tools under Wine??
The RTEMS "quickstart" example uses an .exe extension, so it looks like Yuke's toolset is braindamaged. http://www.rtems.com/wiki/index.php/Quick_Start Example: bash-3.1$ sparc-rtems4.9-gdb `find . -name ticker.exe` (bleah!)
The RTEMS example is running on a simulator via gdb, which is a far cry from running on real hardware, booting either on bare metal (very big ouch) or using u-boot to start it (much less ouch - I would start by running your RTEMS build as a u-boot "application" - that gets you things like fairly painless serial support).
Note to Yuke: this will be a learning experience for you - please keep us informed so we can learn vicariously with you. I'm not aware of anybody using u-boot to boot RTEMS, so you may have some useful stuff when you get to the end of your journey. We will help as much as we can...
Anyway, a good suggestion is to install ELDK and rebuild U-Boot and update it, even get Linux booted. It may not be your main goal, but consider it educational :)
Note to Yuke: you should also have a JTAG debugger to recover from failed u-boot reprogramming if you rebuild and reflash u-boot. You may want to use a JTAG debugger even if you *don't* reflash u-boot.
Note that the Abatron BDI3000 supports "gdb remote target". http://www.abatron.ch/products/bdi-family/bdi3000.html http://www.abatron.ch/products/debugger-support/gnu-support.html I think most of the competitors do too now, but I don't know. Definitely ask about their linux (as the host) and gdb (remote target over ethernet) support before you buy.
USB-attached JTAG debuggers tend to be Windows-only. Bleah! On a positive note, I have a whole collection of single-board computers (curiously labeled "USB TAP" ;-) with a MPC866, usb, and JTAG interface. If only I had the time to port u-boot to them and make them useful... :-D
Cheers, Dave
Best regards, gvb
Jerry Van Baren wrote:
David Hawkins wrote:
Hi Yuke,
[snip]
You say that the development is done with RHLE5, but then that a .exe is created. That seems to be a conflicting statement. Perhaps you could explain ... are you running the RTEMs tools under Wine??
The RTEMS "quickstart" example uses an .exe extension, so it looks like Yuke's toolset is braindamaged. http://www.rtems.com/wiki/index.php/Quick_Start Example: bash-3.1$ sparc-rtems4.9-gdb `find . -name ticker.exe` (bleah!)
The RTEMS example is running on a simulator via gdb, which is a far cry from running on real hardware, booting either on bare metal (very big ouch) or using u-boot to start it (much less ouch - I would start by running your RTEMS build as a u-boot "application" - that gets you things like fairly painless serial support).
Note to Yuke: this will be a learning experience for you - please keep us informed so we can learn vicariously with you. I'm not aware of anybody using u-boot to boot RTEMS, so you may have some useful stuff when you get to the end of your journey. We will help as much as we can...
Thanks. It is true that RTEMS provide .exe for gdb simulation. But we do have BSP package and to build application for real board, like this mpc8313 board. I might need to figure out how to make better use of U-boot. But right now, I just want to use it to load image and get it run. The vendor already installed U-boot. I thought U-boot is just a bootloader. Never think about build RTEMS as u-boot application. It seems I misunderstood a lot. :-(
Anyway, a good suggestion is to install ELDK and rebuild U-Boot and update it, even get Linux booted. It may not be your main goal, but consider it educational :)
Note to Yuke: you should also have a JTAG debugger to recover from failed u-boot reprogramming if you rebuild and reflash u-boot. You may want to use a JTAG debugger even if you *don't* reflash u-boot.
Note that the Abatron BDI3000 supports "gdb remote target". http://www.abatron.ch/products/bdi-family/bdi3000.html http://www.abatron.ch/products/debugger-support/gnu-support.html I think most of the competitors do too now, but I don't know. Definitely ask about their linux (as the host) and gdb (remote target over ethernet) support before you buy.
USB-attached JTAG debuggers tend to be Windows-only. Bleah! On a positive note, I have a whole collection of single-board computers (curiously labeled "USB TAP" ;-) with a MPC866, usb, and JTAG interface. If only I had the time to port u-boot to them and make them useful... :-D
Cheers, Dave
Best regards, gvb
On a positive note, I have a whole collection of single-board computers (curiously labeled "USB TAP" ;-) with a MPC866, usb, and JTAG interface. If only I had the time to port u-boot to them and make them useful... :-D
I have a collection of three of those 'CodeWarrior' USB-TAP devices, and I'd been thinking the same thing ... but thats a thread for another day ...
Cheers, Dave
Yuke Tian wrote:
Hi,
Sorry to ask the stupid question. I did study the RTEMS for a while and am sure the tool set are correct (from ftp://www.rtems.com), otherwise they will not build RTEMS. All the tools and development are done in linux (RHLE5). I just got this board using U-boot and not sure about it. David's manual help a lot. Thanks.
Yuke
I didn't call your question stupid, just clueless. ;-)
It sounds like you are coming up to speed rapidly, including providing useful background information and asking smart questions. You might add the following to your reading list: http://www.catb.org/esr/faqs/smart-questions.html
Best regards, gvb
Thanks.
To be specific, I followed the steps to build RTEMS: 1) Download a set of toolsets (gcc-4.2.3, binutils-2.18, newlib-1.16 and RTEMS specific patches) and build them or use the pre-built rpm toolset for RHLE5. 2) Download the RTEMS (4.9.0 for the latest version) and use the toolset to build RTEMS. 3) Compile a RTEMS application, tailed for specific BSP. That is where I get .exe (it is ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, not stripped). I just want to use the vendor provided U-Boot to download the .exe and get it run. I didn't expect to rebuilt U-Boot, but that might be educational :-)
Yuke
Jerry Van Baren wrote:
Yuke Tian wrote:
Hi,
Sorry to ask the stupid question. I did study the RTEMS for a while and am sure the tool set are correct (from ftp://www.rtems.com), otherwise they will not build RTEMS. All the tools and development are done in linux (RHLE5). I just got this board using U-boot and not sure about it. David's manual help a lot. Thanks.
Yuke
I didn't call your question stupid, just clueless. ;-)
It sounds like you are coming up to speed rapidly, including providing useful background information and asking smart questions. You might add the following to your reading list: http://www.catb.org/esr/faqs/smart-questions.html
Best regards, gvb
Hi Yuke,
To be specific, I followed the steps to build RTEMS:
- Download a set of toolsets (gcc-4.2.3, binutils-2.18, newlib-1.16 and
RTEMS specific patches) and build them or use the pre-built rpm toolset for RHLE5. 2) Download the RTEMS (4.9.0 for the latest version) and use the toolset to build RTEMS. 3) Compile a RTEMS application, tailed for specific BSP. That is where I get .exe (it is ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, not stripped). I just want to use the vendor provided U-Boot to download the .exe and get it run. I didn't expect to rebuilt U-Boot, but that might be educational :-)
Great, that is useful background information in which to pose your questions.
It sounds like the Makefile puts a .exe extension on the ELF file, and that can safely be ignored.
Does the RTEMs BSP for the MPC8313 board have a README that tells you how to boot RTEMs? The ELF file is not what will be executed by U-Boot. powerpc-linux-objcopy would most likely be used to convert the ELF into a binary image. mkimage might be run on that image to add a header. However, I've only used U-Boot with standalone apps and Linux, so someone else would have to comment. (VxWorks/RTEMs users - any help here?)
It does however sound like you have a reasonable tools setup, and the step you are looking for is
'what is necessary to convert the ELF file to a U-Boot compatible format, and then what U-Boot command is needed to execute it?'
Hopefully someone can help answer that. Please go and re-review the U-Boot README file too, there's a chance that there are some useful comments in there - now that you know what you are looking for.
If someone on the RTEMs list answers your question, please post the results back to this list so that the solution is available in the archive.
Cheers, Dave
David Hawkins wrote:
Hi Yuke,
To be specific, I followed the steps to build RTEMS:
- Download a set of toolsets (gcc-4.2.3, binutils-2.18, newlib-1.16 and
RTEMS specific patches) and build them or use the pre-built rpm toolset for RHLE5. 2) Download the RTEMS (4.9.0 for the latest version) and use the toolset to build RTEMS. 3) Compile a RTEMS application, tailed for specific BSP. That is where I get .exe (it is ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, not stripped). I just want to use the vendor provided U-Boot to download the .exe and get it run. I didn't expect to rebuilt U-Boot, but that might be educational :-)
Great, that is useful background information in which to pose your questions.
It sounds like the Makefile puts a .exe extension on the ELF file, and that can safely be ignored.
Does the RTEMs BSP for the MPC8313 board have a README that tells you how to boot RTEMs? The ELF file is not what will be executed by U-Boot. powerpc-linux-objcopy would most likely be used to convert the ELF into a binary image. mkimage might be run on that image to add a header. However, I've only used U-Boot with standalone apps and Linux, so someone else would have to comment. (VxWorks/RTEMs users - any help here?)
It does however sound like you have a reasonable tools setup, and the step you are looking for is
'what is necessary to convert the ELF file to a U-Boot compatible format, and then what U-Boot command is needed to execute it?'
That is exactly what I want now (I need to pick up U-boot later :-) ). I will try powerpc-linux-objcopy and let you know.
Thank you and sorry again for the unclear statement.
Hopefully someone can help answer that. Please go and re-review the U-Boot README file too, there's a chance that there are some useful comments in there - now that you know what you are looking for.
If someone on the RTEMs list answers your question, please post the results back to this list so that the solution is available in the archive.
Cheers, Dave
Hi Yuke,
That is exactly what I want now (I need to pick up U-boot later :-) ). I will try powerpc-linux-objcopy and let you know.
Well, powerpc-linux-object copy will give you a binary blob, but thats useless to you unless you know how to use/load the blob.
I'm a little confused as to why you say you have a BSP, and none of this is explained in the BSP.
Where did this BSP come from? Got a link?
Cheers, Dave
Hi David,
After email some people in RTEMS community, I got the solutions:
--- To prepare the U-boot image for RTEMS application (with os built in for RTMES) in host pc (RHEL5) powerpc-rtems4.9-objcopy -O binary test.ext test.bin (the powerpc-rtems4.9-objcopy is provided from rtems toolset) gzip -9 test.bin mkimage -A ppc -O rtems -T kernel -C gzip -a 100 -e 10000 -n "RTEMS Test" -d test.bin test.img (I am still looking for mkimage software)
--To load through U-boot (pre-installed by board vendor) setenv ethact TSEC1 (this board has 6 ethernet port, choose one) setenv ipaddr 123.345.123.1 (board ip) setenv serverip 123.345.123.2 (tftp server ip) tftp 1000000 test.img (load image to this RAM address) bootm (then run)
This is the recommended step to boot the board into RTEMS through U-boot.
I guess to get mkimage for this board, I need to rebuilt U-boot anyway. Or this mkimage is a standard utility from U-boot ?
Thanks for the discussion.
Yuke
David Hawkins wrote:
Hi Yuke,
That is exactly what I want now (I need to pick up U-boot later :-) ). I will try powerpc-linux-objcopy and let you know.
Well, powerpc-linux-object copy will give you a binary blob, but thats useless to you unless you know how to use/load the blob.
I'm a little confused as to why you say you have a BSP, and none of this is explained in the BSP.
Where did this BSP come from? Got a link?
Cheers, Dave
Hi Yuke,
After email some people in RTEMS community, I got the solutions:
--- To prepare the U-boot image for RTEMS application (with os built in for RTMES) in host pc (RHEL5) powerpc-rtems4.9-objcopy -O binary test.ext test.bin (the powerpc-rtems4.9-objcopy is provided from rtems toolset) gzip -9 test.bin mkimage -A ppc -O rtems -T kernel -C gzip -a 100 -e 10000 -n "RTEMS Test" -d test.bin test.img (I am still looking for mkimage software)
Install the ELDK tools as per my document, and it'll get installed for you. You'll want to install whatever the latest version is ... ELDK-4.2 I think.
--To load through U-boot (pre-installed by board vendor) setenv ethact TSEC1 (this board has 6 ethernet port, choose one) setenv ipaddr 123.345.123.1 (board ip) setenv serverip 123.345.123.2 (tftp server ip) tftp 1000000 test.img (load image to this RAM address) bootm (then run)
This is the recommended step to boot the board into RTEMS through U-boot.
Great!
I guess to get mkimage for this board, I need to rebuilt U-boot anyway. Or this mkimage is a standard utility from U-boot ?
Its a binary for the development host (RHEL5), so it will get installed with the ELDK.
As a bonus, once you boot a version of RTEMs built using their toolset, you should be able to set the compiler tools to those provided with the ELDK and build RTEMs with that toolset too.
Cheers, Dave
Yuke Tian wrote:
Thanks.
To be specific, I followed the steps to build RTEMS:
- Download a set of toolsets (gcc-4.2.3, binutils-2.18, newlib-1.16 and
RTEMS specific patches) and build them or use the pre-built rpm toolset for RHLE5.
OK.
- Download the RTEMS (4.9.0 for the latest version) and use the toolset
to build RTEMS.
OK for RTEMS, it may be some work getting it to compile u-boot or linux. Or maybe not. Around here, ELDK dominates because it is easy to build u-boot and linux with it (thanks, Wolfgang!). If you get serious about rebuilding u-boot or linux, I would strongly urge you to use ELDK to build the first one before trying to get RTEMS' toolset to work. Rule #1 of engineering: change only ONE variable at a time!
- Compile a RTEMS application, tailed for specific BSP. That is where
I get .exe (it is ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, not stripped).
That's good.
I just want to use the vendor provided U-Boot to download the .exe and get it run.
I don't know anything about RTEMS and its BSP. It may want to be burned into flash, replacing u-boot. In that case, open your wallet and buy a JTAG debugger (e.g. BDI-3000).
----
If you want to use u-boot to load & go, you need to figure out where the .exe is loaded in memory and make sure it is in RAM, not by the start of RAM (interrupt vectors) or end of RAM (u-boot). You probably will need to change the load location (Makefile or linker script *.lds).
You will need to figure out where RTEMS wants to live. It may want to live at the start of RAM so it can take over the interrupt vectors. You will need to figure out how to get it where it needs to be, if you cannot load it directly there. You may be able to learn from how u-boot boots a vxWorks image? That is the closest match that I can think of to how RTEMS will work.
You will also have to figure out how to make RTEMS support your board's I/O (serial first, ethernet second).
All of the above should be addressed more or less successfully by the BSP. Whether your RTEMS+BSP plays well (or at all) with u-boot, I don't have a clue. Since we (I) don't know much about RTEMS and the BSP you have, we (I) cannot say much specific.
I didn't expect to rebuilt U-Boot, but that might be educational :-)
It could be expensive too, if you don't have a JTAG debugger to recover from oopses. :-/
Yuke
BTW, please bottom/inline post. http://en.wikipedia.org/wiki/Posting_style#Bottom-posting
Best regards, gvb
Jerry Van Baren wrote:
Yuke Tian wrote:
Hi,
Sorry to ask the stupid question. I did study the RTEMS for a while and am sure the tool set are correct (from ftp://www.rtems.com), otherwise they will not build RTEMS. All the tools and development are done in linux (RHLE5). I just got this board using U-boot and not sure about it. David's manual help a lot. Thanks.
Yuke
I didn't call your question stupid, just clueless. ;-)
It sounds like you are coming up to speed rapidly, including providing useful background information and asking smart questions. You might add the following to your reading list: http://www.catb.org/esr/faqs/smart-questions.html
Best regards, gvb
Hello,
I have a question relating to doing saveenv from the u-boot command line (after hitting key to stop autoboot), and having u-boot come up during the next reboot with the saved environment.
First of all, I apologize in advance if this question is out of place in this mailing list.
This mailing list seems to be for u-boot patch upgrades, rather than for general questions?
Anyway, it's the best list on u-boot I was able to find:
1. I upgraded from u-boot 1.1.3 (2005) to u-boot 1.3.4 (2008) 2. I've put in the board/target-specific files incorporated, and have it working.
3. However, when I do a saveenv (e.g. after "set serverip 10.0.0.1"), and I do a reboot, the new environment variable doesn't show up. a. (I've verified that it actually gets written to flash...)
4. Is there something I else I need to do to "turn on" re-booting from saved environment?
Thanks in advance.
Suresh Bhaskaran
How did you verified that your environment get saved? What is the result of running the 'flinfo'? Is CONFIG_ENV_OVERWRITE defined in your board file?
Kind regards, Andrejs Cainikovs.
Suresh Bhaskaran wrote:
Hello,
I have a question relating to doing saveenv from the u-boot command line (after hitting key to stop autoboot), and having u-boot come up during the next reboot with the saved environment.
First of all, I apologize in advance if this question is out of place in this mailing list.
This mailing list seems to be for u-boot patch upgrades, rather than for general questions?
Anyway, it's the best list on u-boot I was able to find:
- I upgraded from u-boot 1.1.3 (2005) to u-boot 1.3.4 (2008)
- I've put in the board/target-specific files incorporated, and have
it working.
- However, when I do a saveenv (e.g. after "set serverip 10.0.0.1"),
and I do a reboot, the new environment variable doesn't show up. a. (I've verified that it actually gets written to flash...)
- Is there something I else I need to do to "turn on" re-booting from
saved environment?
Thanks in advance.
Suresh Bhaskaran _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
1. I verified flash contents using the md.w command in u-boot 2. I've already verified correct flash r/w operation using the cp.w command 3. Yes, the CONFIG_ENV_OVERWRITE flag is defined in my boardfile 4. Flinfo shows the correct flash configuration (sectors, etc) of the flash
I can see the new env variable (e.g. set serverip 10.0.0.1) at the end of the saveenv area in flash (after I do a saveenv). (the original entry is removed from the list in flash, and the new updated entry is added to the end of the list in flash).
Still, when I reboot u-boot, I don't get the new environment variable updated from flash.
What am I missing?
Thanks.
Suresh
-----Original Message----- From: Andrejs Cainikovs [mailto:andrejsc@globalautomationsystems.com] Sent: Sunday, October 05, 2008 8:55 AM To: Suresh Bhaskaran Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] U-boot Saveenv question
How did you verified that your environment get saved? What is the result of running the 'flinfo'? Is CONFIG_ENV_OVERWRITE defined in your board file?
Kind regards, Andrejs Cainikovs.
Suresh Bhaskaran wrote:
Hello,
I have a question relating to doing saveenv from the u-boot command
line
(after hitting key to stop autoboot), and having u-boot come up during the next reboot with the saved environment.
First of all, I apologize in advance if this question is out of place
in
this mailing list.
This mailing list seems to be for u-boot patch upgrades, rather than
for
general questions?
Anyway, it's the best list on u-boot I was able to find:
- I upgraded from u-boot 1.1.3 (2005) to u-boot 1.3.4 (2008)
- I've put in the board/target-specific files incorporated, and have
it working.
- However, when I do a saveenv (e.g. after "set serverip 10.0.0.1"),
and I do a reboot, the new environment variable doesn't show up. a. (I've verified that it actually gets written to flash...)
- Is there something I else I need to do to "turn on" re-booting
from
saved environment?
Thanks in advance.
Suresh Bhaskaran _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Suresh Bhaskaran wrote:
- I verified flash contents using the md.w command in u-boot
- I've already verified correct flash r/w operation using the cp.w
command 3. Yes, the CONFIG_ENV_OVERWRITE flag is defined in my boardfile 4. Flinfo shows the correct flash configuration (sectors, etc) of the flash
I can see the new env variable (e.g. set serverip 10.0.0.1) at the end of the saveenv area in flash (after I do a saveenv). (the original entry is removed from the list in flash, and the new updated entry is added to the end of the list in flash).
Still, when I reboot u-boot, I don't get the new environment variable updated from flash.
What am I missing?
Thanks. Suresh
Please don't top post.
Are you using DHCP (BOOTP)? If you are, serverip is probably being sent by your DHCP server and overriding the value you have set in your env.
I'm assuming you are *not* getting env CRC failure warnings on boot.
If neither of the above guesses solve the problem, please copy what is printed to the console on start up. Without more information, we're just guessing.
Best regards, gvb
-----Original Message----- From: Andrejs Cainikovs [mailto:andrejsc@globalautomationsystems.com] Sent: Sunday, October 05, 2008 8:55 AM To: Suresh Bhaskaran Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] U-boot Saveenv question
How did you verified that your environment get saved? What is the result of running the 'flinfo'? Is CONFIG_ENV_OVERWRITE defined in your board file?
Kind regards, Andrejs Cainikovs.
Suresh Bhaskaran wrote:
Hello,
I have a question relating to doing saveenv from the u-boot command
line
(after hitting key to stop autoboot), and having u-boot come up during the next reboot with the saved environment.
First of all, I apologize in advance if this question is out of place
in
this mailing list.
This mailing list seems to be for u-boot patch upgrades, rather than
for
general questions?
Anyway, it's the best list on u-boot I was able to find:
- I upgraded from u-boot 1.1.3 (2005) to u-boot 1.3.4 (2008)
- I've put in the board/target-specific files incorporated, and have
it working.
- However, when I do a saveenv (e.g. after "set serverip 10.0.0.1"),
and I do a reboot, the new environment variable doesn't show up. a. (I've verified that it actually gets written to flash...)
- Is there something I else I need to do to "turn on" re-booting
from
saved environment?
Thanks in advance.
Suresh Bhaskaran _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
-----Original Message----- From: Jerry Van Baren [mailto:gerald.vanbaren@ge.com] Sent: Monday, October 06, 2008 10:07 AM To: Suresh Bhaskaran Cc: Andrejs Cainikovs; u-boot@lists.denx.de Subject: Re: [U-Boot] U-boot Saveenv question
Suresh Bhaskaran wrote:
- I verified flash contents using the md.w command in u-boot
- I've already verified correct flash r/w operation using the cp.w
command 3. Yes, the CONFIG_ENV_OVERWRITE flag is defined in my boardfile 4. Flinfo shows the correct flash configuration (sectors, etc) of the flash
I can see the new env variable (e.g. set serverip 10.0.0.1) at the end of the saveenv area in flash (after I do a saveenv). (the original entry is removed from the list in flash, and the new updated entry is added to the end of the list in flash).
Still, when I reboot u-boot, I don't get the new environment variable updated from flash.
What am I missing?
Thanks. Suresh
Please don't top post.
Are you using DHCP (BOOTP)? If you are, serverip is probably being sent
by your DHCP server and overriding the value you have set in your env.
I'm assuming you are *not* getting env CRC failure warnings on boot.
If neither of the above guesses solve the problem, please copy what is printed to the console on start up. Without more information, we're just guessing.
Best regards, gvb
------------------------------
Thanks, Jerry.
Sorry for the previous top post.
Your guess is right!
Upon looking more carefully at my log, I see
"bad CRC, using default environment"
In my boot-up log.
I am looking thru the code to see why I might have a bad crc.
Meanwhile, any guesses as to why I have bad crc?
Could I have ported code from u1.1.3 to u1.3.4 incorrectly?
Or could I have accidentally ignored some "change" from u1.1.3 to u1.3.4?
Thanks.
Suresh
-----Original Message----- From: Jerry Van Baren [mailto:gerald.vanbaren@ge.com] Sent: Monday, October 06, 2008 10:07 AM To: Suresh Bhaskaran Cc: Andrejs Cainikovs; u-boot@lists.denx.de Subject: Re: [U-Boot] U-boot Saveenv question
Suresh Bhaskaran wrote:
- I verified flash contents using the md.w command in u-boot
- I've already verified correct flash r/w operation using the cp.w
command 3. Yes, the CONFIG_ENV_OVERWRITE flag is defined in my boardfile 4. Flinfo shows the correct flash configuration (sectors, etc) of the flash
I can see the new env variable (e.g. set serverip 10.0.0.1) at the end of the saveenv area in flash (after I do a saveenv). (the original entry is removed from the list in flash, and the new updated entry is added to the end of the list in flash).
Still, when I reboot u-boot, I don't get the new environment variable updated from flash.
What am I missing?
Thanks. Suresh
Please don't top post.
Are you using DHCP (BOOTP)? If you are, serverip is probably being sent
by your DHCP server and overriding the value you have set in your env.
I'm assuming you are *not* getting env CRC failure warnings on boot.
If neither of the above guesses solve the problem, please copy what is printed to the console on start up. Without more information, we're just guessing.
Best regards, gvb
-------------------------------------------------------------
Thanks for help:
I've got it working:
Final answer:
1. If *only* CONFIG_ENV_OVERWRITE is turned on in board file, then crc is not written to flash [don't know if it's bug, or if I am setting incorrect flags]
2. But if CFG_ENV_ADDR_REDUND is also set, then it sets CRC to flash, and it works correctly.
In any case, setup 2. works for me.
Thanks for all the help.
Suresh
Suresh Bhaskaran wrote:
-----Original Message----- From: Jerry Van Baren [mailto:gerald.vanbaren@ge.com] Sent: Monday, October 06, 2008 10:07 AM To: Suresh Bhaskaran Cc: Andrejs Cainikovs; u-boot@lists.denx.de Subject: Re: [U-Boot] U-boot Saveenv question
Suresh Bhaskaran wrote:
- I verified flash contents using the md.w command in u-boot
- I've already verified correct flash r/w operation using the cp.w
command 3. Yes, the CONFIG_ENV_OVERWRITE flag is defined in my boardfile 4. Flinfo shows the correct flash configuration (sectors, etc) of the flash
I can see the new env variable (e.g. set serverip 10.0.0.1) at the end of the saveenv area in flash (after I do a saveenv). (the original entry is removed from the list in flash, and the new updated entry is added to the end of the list in flash).
Still, when I reboot u-boot, I don't get the new environment variable updated from flash.
What am I missing?
Thanks. Suresh
Please don't top post.
Are you using DHCP (BOOTP)? If you are, serverip is probably being sent
by your DHCP server and overriding the value you have set in your env.
I'm assuming you are *not* getting env CRC failure warnings on boot.
If neither of the above guesses solve the problem, please copy what is printed to the console on start up. Without more information, we're just guessing.
Best regards, gvb
Thanks for help:
I've got it working:
Final answer:
Sorry, workaround for you, this isn't the final answer.
- If *only* CONFIG_ENV_OVERWRITE is turned on in board file, then crc
is not written to flash [don't know if it's bug, or if I am setting incorrect flags]
This may work for you, but there is something else wrong for you. From the README file: If CONFIG_ENV_OVERWRITE is #defined in your config file, the write protection for vendor parameters is completely disabled. Anybody can change or delete these parameters. so CONFIG_ENV_OVERWRITE controls some logic WRT what can be changed in the env, but it doesn't directly affect flash writing.
- But if CFG_ENV_ADDR_REDUND is also set, then it sets CRC to flash,
and it works correctly.
s/CFG/CONFIG/ What version is your u-boot? They have been renamed CONFIG_* for several months now.
Again from the README: - CONFIG_ENV_ADDR_REDUND CONFIG_ENV_SIZE_REDUND
These settings describe a second storage area used to hold a redundant copy of the environment data, so that there is a valid backup copy in case there is a power failure during a "saveenv" operation. ...so this *does* directly affect flash writing. In particular, it causes "extra" flash writing.
My first suspicion is that you have a buffering/caching problem so that a non-redundant flash write doesn't actually go to completion (doesn't actually make it into the flash or the writes get reordered by the processor's bus interface unit). By setting the redundancy config option, your program does another flash write operation which forces the "hung" write out to flash.
I would check if your data cache is disabled or handled properly if enabled and I would check if you have the right "sync" magic to flush the flash write operations out the bus interface unit properly.
In any case, setup 2. works for me.
Thanks for all the help.
Suresh
Best regards, gvb
participants (6)
-
Andrejs Cainikovs -
David Hawkins -
Jerry Van Baren -
Jerry Van Baren -
Suresh Bhaskaran -
Yuke Tian