[U-Boot] mpc83xx U-boot questions

[U-Boot] mpc83xx U-boot questions

[Yuke Tian]

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

[U-Boot] mpc83xx U-boot questions

[David Hawkins]

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] mpc83xx U-boot questions

[Yuke Tian]

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

[U-Boot] mpc83xx U-boot questions

[David Hawkins]

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

[U-Boot] mpc83xx U-boot questions

[Jerry Van Baren]

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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] mpc83xx U-boot questions

[Yuke Tian]

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.
>
> 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 at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>
>

[U-Boot] mpc83xx U-boot questions

[David Hawkins]

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

[U-Boot] mpc83xx U-boot questions

[Jerry Van Baren]

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

[U-Boot] mpc83xx U-boot questions

[Yuke Tian]

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
>

[U-Boot] mpc83xx U-boot questions

[David Hawkins]

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

[U-Boot] mpc83xx U-boot questions

[Jerry Van Baren]

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

[U-Boot] mpc83xx U-boot questions

[Yuke Tian]

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
>

[U-Boot] mpc83xx U-boot questions

[David Hawkins]

Hi Yuke,

> 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 :-)          

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

[U-Boot] mpc83xx U-boot questions

[Yuke Tian]

David Hawkins wrote:
> Hi Yuke,
>
>> 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 :-)          
>
> 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
>
>

[U-Boot] mpc83xx U-boot questions

[David Hawkins]

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

[U-Boot] mpc83xx U-boot questions

[Yuke Tian]

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
>

[U-Boot] mpc83xx U-boot questions

[David Hawkins]

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

[U-Boot] mpc83xx U-boot questions

[Jerry Van Baren]

Yuke Tian wrote:
> 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.

OK.

> 2) 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!

> 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).

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

[U-Boot] U-boot Saveenv question

[Suresh Bhaskaran]

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

[U-Boot] U-boot Saveenv question

[Andrejs Cainikovs]

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:
>
> 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
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>   

[U-Boot] U-boot Saveenv question

[Suresh Bhaskaran]

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 at globalautomationsystems.com] 
Sent: Sunday, October 05, 2008 8:55 AM
To: Suresh Bhaskaran
Cc: u-boot at 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:
>
> 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
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>   

[U-Boot] U-boot Saveenv question

[Jerry Van Baren]

Suresh Bhaskaran wrote:
> 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

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 at globalautomationsystems.com] 
> Sent: Sunday, October 05, 2008 8:55 AM
> To: Suresh Bhaskaran
> Cc: u-boot at 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:
>>
>> 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
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>>   
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] U-boot Saveenv question

[Suresh Bhaskaran]

-----Original Message-----
From: Jerry Van Baren [mailto:gerald.vanbaren at ge.com] 
Sent: Monday, October 06, 2008 10:07 AM
To: Suresh Bhaskaran
Cc: Andrejs Cainikovs; u-boot at lists.denx.de
Subject: Re: [U-Boot] U-boot Saveenv question

Suresh Bhaskaran wrote:
> 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

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

[U-Boot] U-boot Saveenv question --> final tested solution

[Suresh Bhaskaran]

-----Original Message-----
From: Jerry Van Baren [mailto:gerald.vanbaren at ge.com] 
Sent: Monday, October 06, 2008 10:07 AM
To: Suresh Bhaskaran
Cc: Andrejs Cainikovs; u-boot at lists.denx.de
Subject: Re: [U-Boot] U-boot Saveenv question

Suresh Bhaskaran wrote:
> 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

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

[U-Boot] U-boot Saveenv question --> final tested solution

[Jerry Van Baren]

Suresh Bhaskaran wrote:
> 
> -----Original Message-----
> From: Jerry Van Baren [mailto:gerald.vanbaren at ge.com] 
> Sent: Monday, October 06, 2008 10:07 AM
> To: Suresh Bhaskaran
> Cc: Andrejs Cainikovs; u-boot at lists.denx.de
> Subject: Re: [U-Boot] U-boot Saveenv question
> 
> Suresh Bhaskaran wrote:
>> 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
> 
> 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.

> 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]

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.

> 2.  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