Program UBoot

Great info.

A few things.

The docs talk about the epcs bootloader ROM as if this is some FPGA onchip ROM whose contents are determined during project compilation.

Yet I see from your steps above the epcs bootloader gets bundled with the u-boot image. Are there two bootloaders?

How do you figure out how much app code you can fit?

For my HW the data sheet says:

EPCS1 = 131072

EPC4 = 115564 ; uncompressed

spare = 15508 ; ignoring bootloader overhead

15KB is not enough for u-boot, but if both the config and app could be compressed, that would allow around 100KB of app code.

Do you lose the ability to use compressed files when you program with the flash programmer?

Hi tns1,

> Are there two bootloaders?

Sort-of ... the code in the epcs on-chip rom is built-in to the device

configation. At reset, this code searches for the end of the config

data in the epcs device, then loads the records that follow (which

in this case would be u-boot). It then jumps to the u-boot entry

point. The epcs u-boot command will tell you the size of the

configuration data.

> How do you figure out how much app code you can fit?

In my case, it's purely observation ... my fpga configuration data

is about 192 KB (compressed). I'm using an EPCS4 ... so that leaves

me plenty of room for u-boot (which ends up being roughly another

128 KB).

> Do you lose the ability to use compressed files when you program

> with the flash programmer?

I use compressed bit streams & haven't had any problems.

Regards,

--Scott

Including the boot=<path> parameter with elf2flash command above does not seem necessary - the flash file is unchanged.

As far as I can tell, the epcs bootloader code that is running from the FPGA epcs module does it all. There would be no reason

to add anything to the app image stored in the epcs chip other than some header info to tell it what chip maybe.

My confusion on compressed files was that the actual sof,pof,jic files dont change size.

If I use the map option in the file converter I can see there is a difference.

I think the sof2flash will produce compressed output only if the sof is already compressed.

The file converter produces compressed files but it only takes sof as input

elf2flash does not compress so I don&#39;t think your u-boot image is compressed.

I am referring to the cyclone (de)compression, not the epcs (de)compression only on epcs4 and up.

It is looking like there is no way for application images stored in epcs1 to take advantage of the cyclone (de)compression scheme.

It appears to be just for config data.

Is there an easy patch process to update a customized version of the u-boot src?

I just noticed I have an older version than appears on the psyent site.

Hi tns1,

> Is there an easy patch process to update a customized version of the u-boot src?

Yes, see the section, "Submitting Patches" in the u-boot top level README file for

details. But basically, create a patch file against the u-boot top-of-tree, then

send the patch to the u-boot mailing list.

To ensure a good experience, please do follow the instructions carefully.

The lead project maintainer (Wolfgang) sets high standards for contributions ;-)

> I just noticed I have an older version than appears on the psyent site.

Please be aware that the u-boot sources at http://www.psyent.com/download (http://www.psyent.com/download)

are *not* official. However, anything that shows up at psyent has been submitted

to the u-boot project ... with the exception of a few very basic nips & tucks to

eliminate compile time warnings.

Since u-boot supports such a large number of architectures and boards,

the maintainers receive a considerable number of patches. Because of this,

some patches can literally take months to make it into the official source

tree -- this why the psyent site exists -- to make the Nios CPU related

patches available to the development community as soon as possible.

As of 2005-Feb-10, the (3) patches required to bring the main u-boot source

tree up to the psyent.com level are in the queue at positions 5, 8, and 23

out of a total of 129. When these patches are finally accepted into the main

source tree, I&#39;ll announce it here in the Nios Forum. It would probably be best

to wait until this time to add your specific board to the main source tree.

Also, with Nios-II 1.1, there were several tool changes that result in compile

time errors/warnings with the sources at psyent. These will be cleaned up

and made available at psyent once the appropriate patch has been submitted

to the u-boot project.

I&#39;m sure this post is much more than you bargained for ;-) ... but I hope it

helps.

Best Regards,

--Scott

PS -- once your board-specific code is in the main u-boot source tree, I&#39;d

be glad to make it available in the psyent distribution.

What I meant was, what tools do you use to merge different versions of two source trees?

I am currently using csdiff for comparing folders, and Compare It! to actually merge files. Surely there are better tools.

Yikes! I guess I missed that by a long shot ;-)

I&#39;m a diff/patch guy so I can&#39;t help much here. Although I recently

started using Subversion with TortoiseSVN ... and it does include

some very nice features to ease the pain.

The reason I started using subversion was so I could maintain the

original CVS metadata as part of my local revision control.

Regards,

--Scott

I have rebuilt my project with the epcs module and to reset from epcs. I have rebuilt u-boot with the epcs features added.

While I wait for those epcs4 compatible parts to arrive, I noticed:

If the reset is set to epcs and there is no actual app code stored there, it locks on reset. I am wondering if the epcs bootloader is spinning in an endless loop, executing FF or what. I sort of expected the Nios to eventually find its way to 0x0 anyway where I have some code.

If I use nios2-download to bypass the epcs boot, I can run u-boot and test the epcs features. If I try an &#39;epcs info&#39;, I get an &#39;device not found&#39;. I must do an &#39;epcs read&#39; before &#39;epcs info&#39; will work. There was mention of an epcs chip select issue. Does the latest psyent code have this issue?

The serial flash devices are getting larger all the time (8MByte!) and cheaper than parallel flash. I am thinking about storing multiple application images in the epcs. One way would be to boot u-boot and have it in turn load the select image from the epcs. This requires both u-boot and the app image to be sram resident at the same time - unclean. This is not the case with parallel flash since each image can have its own bootloader.

I think a better way would be to have the epcs bootloader get its image offset parameter from a new writable (system or epcs) register. That way POR would always boot image0 (u-boot), which could then clean boot any other image. Has this been done? I see some posted IP about an &#39;upgraded epcs&#39; but no docs.

Well thanks for all the replies, one final question, now that U-boot is all fine and working well. I&#39;ve got it using dhcp to download a file to sdram and can then put that into flash with no problems, the question is over how to format and encode it up so that uboot can correctly boot it.

Let&#39;s say it is a normal elf image (not linux, just plain nios). And my reset vectors are at

0x01000020

sdram goes from 0x01000000, uboot gets loaded and runs from 0x01C00000

now when i run dhcp I specify a download address of 0x01100000 (i.e clear of the interrupt trampoline).

what i want to do is then flash this image (which I&#39;ve done with no problems). and then later load and execute it using the bootm command, now the elf image is compiled to run at 0x01000000 with interrupts obviously at 0x01000020. So the

question is what parameters should be used for mkimage to generate the correct type of img file for uboot to load and execute assuming these specified addresses?

Regards,...

> What parameters should be used for mkimage to generate the correct type

> of img file for uboot to load and execute assuming these specified addresses?

Assuming your application entry point is the at the start of your uncompressed

binary image:

$ mkimage -A nios2 -O linux -T kernel -C none -a 0x01000000 -e 0x01000000

-n "MyApp v0.1 2005-02-22" -d MyApp.bin MyApp.img

Basically, you&#39;re just telling u-boot that your image is a linux kernel -- that fact

that it&#39;s not really a kernel doesn&#39;t matter. When bootm is executed it will copy

the image data to the load address then jump to the entry point after disabling interrupts (and a few other things).

If you want to use compression, you can compress your binary file using

gzip:

$ gzip -c MyApp.bin >> MyApp.gz

Then use "-C gzip" with mkimage and the compressed file (-d MyApp.gz). bootm

will then decompress as it copies from flash.

Regards,

--Scott