Hi Max,
> mkimage -A Nios2 ...
The parameter should be "nios2" (case is significant). For most architectures, the
-A option is the same as the "arch" part of binutils (e.g. "powerpc", "arm", etc).
This will eliminate the "Unknown Architecture" report.
> When generating the image for uboot, what are the correct values for
> Load Address: ...
> Entry Point: ...
The load address is the address where the image data is copied (after decompressing
if the image is compressed). The entry point is the target __address__ of a jump -- it's
where execution begins. For uClinux, this is currently at __offset__ 0. For some
architectures, the entry point offset is not zero (e.g. arm, powerpc) -- so it's a standard
option for mkimage.
Depending on your hardware, what you are trying to do, and the actual code that
you're booting, the load address may be different. For uClinux, the load address really
doesn't matter since the kernel will relocate itself to the correct run-time address
(although you must be careful not to 'overlap upward' since the Nios-II uClinux
startup code won't handle this situation correctly. A downward overlap -- copying
from a higher address to a lower address -- won't be a problem).
Chances are that your kernel was linked to the start of your SDRAM, which in the
1.1 'standard' config example begins at 0100_0000. So you can just set your load
address and entry point to that value:
$ mkimage -A nios2 -O linux -T kernel -C gzip -a 0x01000000 -e 0x01000000 ....
And don't worry about trashing the exception trampoline ... u-boot disables
interrupts prior to the copy/decompress.
> I tried 0x0 / 0X0. But my kernel still rebooting processor after "decompressing kernel.....OK".
Yep, bootm is trying to decompress into flash ... then it jumps to address 0.
> can I upload my romfs filesystem as I did for the kernel ?
Yes. I believe you can upload it directly into flash (after erasing it), but I never
use that feature ... so I don't know how well it works ... seems a bit dangerous
to me ;-) You can always use the nios2-flash-programmer ... really a very fine
job by Altera on this ... at least from the command line ;-)
> I tried but get "out of limits" each time I try to download the fs
> image into ram, so I couldn't investigate further more at this time.
If u-boot is reporting the "out of limits", try uploading the image into SDRAM
rather than the SRAM. i.e. loadb to address 0100_0100 -- don't loadb over
the exception trampoline at 0100_0020 ;-)
As an aside, you might want to consider using cramfs ... for a read-only fs,
you'll get a much smaller fs image size ... and all the nice side-effects (like
upload time, etc).
Regards,
--Scott