Bootloaders

> Has anyone successfully used either U-Boot or Redboot on a NON-Linux based system?

Yes, I use u-boot in a variety of configurations.

> More specifically, on a MicroC/OS-II-based system?

You can use u-boot to boot MicroC/OS-II -- although there isn't currently any

__direct__ support for MicroC/OS-II. So if you need u-boot to pass parameters

to your kernel, you'll have to add this support (which BTW isn't a big deal).

If you don't need to pass parameters to the kernel, you can do one of two

things without any custom code in u-boot:

1. Load the kernel, then simply execute a "go" command.

2. Create a "linux" u-boot image file for your MicroC/OS-II kernel.

Option 1: easiest -- you can try this without any os-specific mods to u-boot.

Option 2: u-boot doesn't do anything special for linux -- it simply disables

interrupts and calls the image entry point. So you can "lie" to u-boot and tell

it that your MicroC/OS-II kernel is a linux kernel. With this option you can also

take advantage of u-boot's gzip decompression features. i.e. -- you can compress

your MicroC/OS-II image and u-boot will decompress/load it to the proper ram

address before calling it. You'll need the u-boot mkimage utility for this.

If you have anything special you need to do prior to calling your kernel or you don't

want to lie ;-), (e.g. setting up parameters, relocating special code segments, etc.),

you may want to add support for this in u-boot. To do this you can follow examples

for other supported os types (such as NetBSD, LynxOS, RTEMS, VxWorks, QNX, etc.).

u-boot does provide several features you may find handy:

--kernel image decompression

--epcs read, write, erase

--dhcp, bootp, tftp, nfs download

--serial download srec text or kermit binary

--support for jffs2, cramfs, fat filesystems (read-only)

--flash program/erase

--scripting

Regards,

--Scott

Scott,

Thanks for your answer. Now that I know it can be done, I have a few questions.

My system will boot out of the EPCS device. So, my plan is to place the secondary bootloader (u-boot or redboot) in the EPCS. For the first round, I will only download my kernel. How do I need to set up my memory for this to work. When the system boots, the EPCS bootloader will load u-boot into RAM. This places the exceptions at a fixed location. This exception address corresponds to u-boot. When I download my kernel, what do I have to do to get the exceptions working correctly? Also, how do I prevent u-boot from stepping all over my kernel in RAM and vice-versa? Is there a way to force my kernel to only use a specific portion of my available RAM. Thanks again.

-Dave

Hi Dave,

> How do I need to set up my memory for this to work. When the system boots,

> the EPCS bootloader will load u-boot into RAM.

Just strip the u-boot elf file and load it to the config device the same as you

would any generic elf.

> This places the exceptions at a fixed location. This exception address corresponds

> to u-boot.

You can set u-boot's run-time address any where you want in the ram. This is set

via the TEXT_BASE macro in the board-specific config file. For example, look at

board/psyent/pk1c20/config.mk.

When u-boot starts execution, it will copy the exception trampoline to the

address defined by CFG_EXCEPTION_ADDR. See include/configs/PK1C20.h.

Please note that the u-boot build is completely command-line with no knowledge

of your Quartus/SOPC Builder files -- it's not very sophisticated ;-) -- so the

board config file must match you hardware configuration -- and it's up to the

programmer to ensure this.

> When I download my kernel, what do I have to do to get the exceptions

> working correctly?

This is up to your kernel. If it needs to be loaded at a specific address, just

tell u-boot where you want it loaded. If you're image is copied over the

exception address, you'll need to use the 'bootm' command as this will

disable interrupts before copying the kernel image.

u-boot itself doesn't care where the exception address is relative to itself.

It will copy its exception trampoline as required.

> Also, how do I prevent u-boot from stepping all over my kernel in RAM and

> vice-versa?

This is up to your kernel. Normally, once the kernel starts running the sram

image of the bootloader goes bye-bye. When the system resets, the bootloader

will be loaded from epcs and everything starts over.

> Is there a way to force my kernel to only used a specific portion of my available RAM.

I'm not a MicroC/OS-II user (yet). So you'll have to check the appropriate docs.

When I use linux, I pass the mem= parameter in the command line to reserve

high memory for things like shared PCI memory. The mem= parameter BTW

wasn't supported in the stock kernel code for the version I'm using.

If you need any board-specific help, you can just shoot me an email -- I'll

be glad to help you get u-boot running on your board -- as time permits ;-)

Regards,

--Scott

Scott,

Thanks for your help again. This sure is a lot to take in. I'll download u-boot and see how far I can get with it. By the way, can I build u-boot with teh Altera-supplied gnu tools or will I need a full Cygwin install?

-dave

The out-of-the-box Nios-II software development tools will work just fine.

You can download u-boot at:

http://www.sourceforge.net/projects/u-boot (http://www.sourceforge.net/projects/u-boot) (multi-platform/official site)

or

http://www.psyent.com/download (http://www.psyent.com/download) (Nios-II only)

Note that the main source tree tends to lag significantly behind the

psyent site (it's a big project so things move a bit slower). The psyent

site also includes a few "nips & tucks" to ensure a warning-free

build in the Nios-II cygwin environment.

Regards,

--Scott

So, I've been looking at the source code, specifically the nios2 bits. It looks like I should put u-boot in higher memory above where my kernel should go. Then, u-boot will load the exception vectors, which will overwrite the u-boot vectors. Next, u-boot will load my code into RAM. When I jump to _start, my code won't even know about u-boot because it is located in my code's rwdata section.

Does this sound right? I think I'm finally understanding this.

Scott,

Have you used Redboot? Any opinions? I'm still up in the air whether I should use u-boot or redboot. Any pros or cons of either? They seem to have most of the same features. I'm just wondering if I'm missing something that would pull me one way or the other.

Thanks again

-dave

Hi Dave,

> When I jump to _start, my code won't even know about u-boot because it is

> located in my code's rwdata section.

>

> Does this sound right?

That's correct. Your kernel will be unaware of u-boot and will just do

what it needs to do. Once the kernel starts, u-boot it out of the picture :-)

> Have you used Redboot? Any opinions?

Only once. It seems fine.

> Any pros or cons of either?

I think it really boils down to support, accessibility, and

features -- you'll really have to look at your requirements and

pick one that best suits your needs.

Personally, I've found u-boot to have a very active and open

user community. User contributions are submitted frequently

and are welcomed ... and the mailing list remains very active.

Ecos/Redboot does not seem as healthy in this regard, HOWEVER,

the FSF is supposed to pick-up ecos ... so I'm sure this won't be

an issue in the future.

Feature-wise, u-boot is clearly ahead of Redboot ... but this doesn't

matter if you don't need the features.

In the end, I think it really boils down to you requirements. I think

both will serve you just fine.

> I'm just wondering if I'm missing something that would pull me one

> way or the other.

I'd be glad to pull you towards u-boot ... but I am admittedly biased ;-)

I don't think you're missing anything ... a bootloader shouldn't make/break the success of your product ... so I think either would be just fine.

Regards,

--Scott

Well Scott, you've almost got me sold on u-boot. A couple of final questions.

The code I downloaded from psyent works for the dev. kits. What's it going to take to port them to my boards?

The only permanent connection on my boards is through an LVDS link. What will it take to support a new comms mode? I'll probably only need this for downloading, not for console use.

> The code I downloaded from psyent works for the dev. kits.

> What's it going to take to port them to my boards?

You'll need to do the following:

1. Copy an existing board source tree to your own tree. E.g.:

--copy: board/psyent/common ==> board/xyzcorp/common

--copy: board/psyent/pk1c20 ==> board/xyzcorp/myboard

2. Rename the main board source file in board/xyzcorp/myboard:

--rename: board/xyzcorp/myboard/pk1c20.c ==> board/xyzcorp/myboard/myboard.c

3. Create a configuration header file in include/configs:

--copy: include/configs/PK1C20.h ==> include/configs/MYBOARD.h

4. Add an entry in the top-level Makefile for your new board. Here it's

handy to simply copy 'n' edit another entry (e.g. PK1C20). E.g.:

MYBOARD_config : unconfig

@./mkconfig MYBOARD nios2 nios2 myboard xyzcorp

5. make distclean; make MYBOARD_config; make

6. If all goes well, you can now start customizing for your specific hardware

in include/configs/MYBOARD.h & in your board's tree. The config editing is

mostly setting base addresses & removing definitions for hardware you

don't have.

> What will it take to support a new comms mode?

u-boot is command-line based. If "uart emulation" is acceptable,

you can just replace a few low-level routines with your own.

E.g. serial_putc(), serial_getc().

> I'll probably only need this for downloading, not for console use.

To initiate a download, u-boot will require a command (e.g. loads,

loadb, tftpboot, etc). As long as your comms link can send a command

to get things started, you shouldn't have a problem.

Regards,

--Scott