u-boot and NIOS dk 1s10 board

hi all,
I'm trying to use u-boot on a altera's stratix 1S10 board.... I've downloaded the stephan's RPM u-boot port for this board...and downloaded intoo my board...but it doesn't work
has anyone succeded to boot u-boot on this board?
is the port incorporated in the 1.0.0 u-boot version...I just see the cyclone board....

Is anyone try to port ?Clinux on NIOS ? I'm currently working on this point and having a linux bootloader is the first step... Cheer's
Pat.

Patrice Kadionik. F6KQH / F4CUQ
-----------

+---------------------------------------------------------------------+
+"Tout doit etre aussi simple que possible, pas seulement plus simple"+
+---------------------------------------------------------------------+
+ Patrice Kadionik                http://www.enseirb.fr/~kadionik     +
+ ENSEIRB                         fax   : +33 5.56.37.20.23           +
+ PO BOX 99                       voice : +33 5.56.84.23.47           +
+ 33402 TALENCE Cedex             http://www.enseirb.fr               +
+ FRANCE                          mailto:kadionik at enseirb.fr          +
+---------------------------------------------------------------------+

Am Freitag, 14. November 2003 14:06 schrieb Patrice Kadionik:

Yes, I did. It works good to me.

Sorry there was no time and no very important reason to release the Stratix pacht to u-boot cvs (I think, I can do it now :-), because there are no significant differences between Cyclone and Stratix in context of current U-Boot code. Further this patch depends on a few outstanding patches, one for a DK1C20 configuration bug fix and the other one for the LAN91C111 ethernet driver (see:
http://sourceforge.net/mailarchive/forum.php?thread_id=3410088&forum_id=12898).

Here the patches you need against current 1.0.0:

1.) LAN91C111 ethernet driver

Patch: u-boot-smc91111_fix.patch.bz2
State: waiting of a successful validation and cross verification from Richard

- bug fix: change type of smc_mac_addr[] from signed to unsigned (important)
- bug fix: LED configuration (defines in header)
- bug fix: write to right PHY register (PHY_MASK_REG)
- exclude version string for non-debug versions (saves memory)

2.) DK1C20 configuration bug fix

Patch: u-boot-dk1c20_cfg_fix.patch.bz2
State: waiting of CVS inclusion by Wolfgang

see:
http://sourceforge.net/mailarchive/forum.php?thread_id=3397431&forum_id=12898

Wolfgang, could you put it into the CVS repository?

3.) DK1S20 Stratix support

Patch: u-boot-dk1s10_support.patch.bz2
State: not released at u-boot list -- I'm not sure about (if finished or not)

For Stratix I've copied include/configs/DK1C20.h to include/configs/DK1S10.h, change CONFIG_DK1C20 to CONFIG_DK1S10, and expanded main Makefile to new board configuration DK1S10_config. For this new board configuration Cyclon's board directory board/dk1c20 will be used too. In it I've expand checkboard() with a second board-ID string.

You can download all the patches from CDK4NIOS project file list at sourceforge.net:

http://sourceforge.net/project/showfiles.php?group_id=81497
(go to the end, looking for resources --> patches)

Hm, I think Scott McNutt works with uClinux on NIOS. Ask him, he is the maintainer of NIOS U-Boot port.

Yes, and U-Boot works already.

Best Regards

Mit freundlichen Gruessen
Stephan Linz



======================================================================
Stephan Linz
Softwareentwicklung

MAZeT GmbH                   Email: mailto:linz at mazet.de
G?schwitzer Str. 32          Tel. : (3641) 2809-55
D-07745 Jena                 Fax  : (3641) 2809-12

Besuchen Sie bitte unsere Web-Seiten: http://www.MAZeT.de
======================================================================

Good evening...

Since I haven't got any feedback for the serial receive problem I tried many combination of settings and finally decided to hardcode in "bootcmd" which shows version and flinfo...

After that the serial receiving on SCC2 is working...

Also strange is that with CFG_ENV_IS_IN_FLASH defined it didn't say anything about wrong crc. But it is saving the environment settings correctly to flash...

rick

You mean by pre-defining the bootcmd setting you solved a SCC2 problem? Really??

Where is the problem? With an embedded environment U-Boot is expected to build a valid CRC checksum, too.

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Every program has at least one bug and can be shortened by  at  least
one instruction - from which, by induction, one can deduce that every
program can be reduced to one instruction which doesn't work.

Ah nope (o; changed some fcc bits....

The problem is that after reset it always reverts to the same default settings and ignores the ones saved to the flash...

rick

Yup. This is still a problem for many boards.

Wolfgang this is the one we discussed a long time ago.

So what is actually different on those platforms which work and those who don't?

Got two different 8260 boards here and on one saving/loading environment is just fine...

rick

here is the thread

http://sourceforge.net/mailarchive/message.php?msg_id=5315855

Nye Liu
nliu at mrv.com
(818) 772-6235x248
(818) 772-0576 fax

"Who would be stupid enough to quote a fictitious character?"
	-- Don Quixote

Can you please check first, before spreading rumors? I think this has been fixed long ago. I might have missed a thing, though. So please check.

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Conscious is when you are aware of something, and conscience is  when
you wish you weren't.

Sorry, yes, you are correct, the 8xx/FADS is fixed in CVS.

I was looking at an older CVS tree.

Nye Liu
nliu at mrv.com
(818) 772-6235x248
(818) 772-0576 fax

"Who would be stupid enough to quote a fictitious character?"
	-- Don Quixote

Dear All
I'm using a u-boot 1.0.0 which is released 2003-10-30 for SMDK2410 Board made by Samsung electronics.
I patched u-boot for NAND Booting. It works good.
When I boot and set ipddr, serverip, gatewayip and so on using setenv.. it works good too.
But save values such as ipaddr, serverip, gatewayip, ethaddr .. using saveenv. U-boot return messages like that
Unknown command 'saveenv' - try 'help'

printenv, setenv ,saveenv command works good before patching and using AMD NOR Flash

which is the problem?

Thank you very much .

Best regards.

...

There is at least one bug in the patch?

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Until you walk a mile in another man's moccasins, you  can't  imagine
the smell.

I'm trying to get a boot loader running on the 5200, but I'm getting stuck at the compilation of the images. I only have a Pentium2 Redhat 9 environment to work from. I downloaded GCC 3.3.1, bintools 2.11.90 and built them both with a target of powerpc-linux.

To build the MPC5200LITE images, I used 'make MPC5200LITE' which in rummaging through the configuration files in the "board" directory seems to select the correct defaults for flash size and such on the rev 2 board. My problem seems to be in my cross-compiler toolset in any case.

I changed the line CROSS_COMPILE = ppc_8xx-
to CROSS_COMPILE = powerpc-linux- because that seemed to be the architecture that it was using (when I didn't change it, I got a goodly pile of ppc_8xx related failures). Now the make largely goes ahead, but when it hits a certain point (stubs.c in the 'examples' directory) it errors out with many repetitions of "Error: Relocation cannot be done when using -mrelocatable"

This would seem to be something dead-simple that I'm missing in building a cross-compiler, because nobody else seems to have this problem. Any suggestions? I built GCC without changing the prefix, so it built in /usr/local/powerpc-linux and /usr/local/lib/gcc-lib/powerpc-linux/ Do I need to add something to ld.so.conf? The Makefile does seem to be finding the path. Sorry about my ignorance. I'm really a mechanical designer in disguise, and I'm definitely new to cross-compiling.

I have one other question: In the archives for the forum, I noticed a contribution to the CVS regarding a low-loading image config. The assertion was that this image would load at 0xFF000000, and that moving the boot jumper to the "low" position would boot there. According to the docs I have from Motorola, moving the jumper to the "low" position boots from 0x00000100 (SDRAM). High boot is 0xFFF00100 (FLASH)
("Lite5200 Manual.pdf", page 19)

Is there a misprint in the manual?

Thanks,
Victor Wren

Victor Wren
Designer,
Timension Inc.
1350 C Pear Ave
Mountain View CA 94043
(650) 564-9397
Fax: (650) 564-9398
Opinions stated in this letter are not necessarily those of Timension Inc. or the management. All Rights Reserved. No spitting.

Use the DENX cross-compiler, unless you are VERY familiar with gcc3.3-isms

Compiling u-boot under gcc3.3 powerpc hosted on x86 is possible, it is just a HUGE pain getting the environment right unless you have done that sort of thing before.

Nye Liu
nliu at mrv.com
(818) 772-6235x248
(818) 772-0576 fax

"Who would be stupid enough to quote a fictitious character?"
	-- Don Quixote

If you don't realy want to learn all the pitfalls and obstacles of building a working cross toolchain you can simply download our ELDK and use this one.

See http://www.denx.de/twiki/bin/view/DULG/ELDK

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Es sind ?berhaupt nur die Dummk?pfe, die sich den Befehlen der  M?ch-
tigen  widersetzen.  Um  sie  zu ruinieren ist es genug, ihre Befehle
treu zu erf?llen.                  - Peter Hacks: "Die sch?ne Helena"

Hey, there. I am working with the MPC5200 Lite, and thanks to the suggestions of using ELDK, I successufully (I think) compiled a boot image for the 5200 under RH9_i386. I used the patch for lowboot (although, because patch on RH9 didn't seem to like the diff file regardless of "-p" levels, I had to apply it with VIm). I move the jumper over, hit the reset button, and I get this on minicom:
===============================
U-Boot 1.0.1 (Nov 24 2003 - 17:10:38)

CPU: MPC5200 (JTAG ID 0001101d) at 399.999 MHz

       Bus 133 MHz, IPB 66 MHz, PCI 33 MHz
Board: Motorola MPC5200 (IceCube)
I2C:   86 kHz, ready
DRAM:  64 MB
FLASH: 16 MB
PCI:   Bus Dev VenId DevId Class Int
        00  1a  1057  5803  0680  00
In:    serial
Out:   serial
Err:   serial
Net:   FEC ETHERNET

Type "run flash_nfs" to mount root filesystem over NFS

Hit any key to stop autoboot: 0
## Booting image at 00100000 ...
Bad Magic Number
=>
=============================
The countdown starts at 5, but it doesn't seem to be recognizing keystrokes before it plunges into the void of random memory.

The BAUD settings appear to be the same as I've been successfully using with the Motorola dMon (115200), and it seems to be writing to minicom quite legibly, but it doesn't seem
to be reading the serial port. Any suggestions where I could look to see why? The ethernet is at its default of bootp, but I didn't think that shold make any difference to the serial terminal. I'm also curious about it booting the image at 0x100000 (doesn't exist, obviously), but I expect I'll figure that out once I see how to set up initrd (or whatever ramdisk is needed).

Thanks,
Victor Wren

Yes, your boot log looks fine.

...

Did you make sure to disable all handshake (software and hardware) in minicom? Most probably minicom is waiting for some modem handshake lines which are not set by the MPC5200 serial driver.

Better, avoid minicom. See
http://www.denx.de/twiki/bin/view/DULG/SystemSetup#Section_4.1.

This is just the default boot sequence.

Well, you can also read the output and follow the instructions:
Type "run flash_nfs" to mount root filesystem over NFS

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Respect is a rational process
	-- McCoy, "The Galileo Seven", stardate 2822.3

I'm having some trouble with the lowboot config on the MPC5200LITE.

In looking through the configs, I notice, where TEXT_BASE=0xFF000000 #define ENVADDR=CFG_FLASH_BASE+30000

Since the u-boot image goes from FF000000 to FF035250, this would appear to drop the environment inside the u-boot code. This is apparently confirmed by the fact that when I do saveenv, u-boot will not come up anymore. (this is without setting any environment variables, even).

When I write a virgin copy of u-boot to the flash, the addresses at FF0030000 appear to hold something other than environment values. After saveenv, they hold environment variables, and everything after the values is filled with zeroes (and u-boot is dead).

Is there a particular reason for having the ENV below the end of the u-boot image? Is there a better place to put it? Possibly the beginning of the next sector (0xFF040000)

Victor Wren

Victor Wren
Designer,
Timension Inc.
1350 C Pear Ave
Mountain View CA 94043
(650) 564-9397
Fax: (650) 564-9398
Opinions stated in this letter are not necessarily those of Timension Inc. or the management. All Rights Reserved. No spitting.

You are right. There is a bug in this configuration.

This is the problem. The U-Boot image should never get that big. It's a bug.

Please change this:

Index: include/configs/IceCube.h
===================================================================
RCS file: /cvsroot/u-boot/include/configs/IceCube.h,v retrieving revision 1.15

diff -u -r1.15 IceCube.h
@@ -206,7 +206,7 @@
 #   define CFG_RAMBOOT		1
 #endif
 
-#define CFG_MONITOR_LEN		(256 << 10)	/* Reserve 256 kB for Monitor	*/
+#define CFG_MONITOR_LEN		(192 << 10)	/* Reserve 192 kB for Monitor	*/
 #define CFG_MALLOC_LEN		(128 << 10)	/* Reserve 128 kB for malloc()	*/
 #define CFG_BOOTMAPSZ		(8 << 20)	/* Initial Memory map for Linux */
 

Yes, there was a configuration error which caused the environment to get embedded instead of placed at the intended location.

The location at 0x0xFF030000 is OK (as long as U-Boot doesn't grow much); just the configuration was wrong. Sorry.

Thanks for pointing this out!

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Most legends have their basis in facts.
	-- Kirk, "And The Children Shall Lead", stardate 5029.5

Thanks! That fixed the problem. I figured it was something like that when the image shrank by one block when I moved the ENV up to FF04000. If I can just figure out how to build an initrd when I don't have any of the ppc executables, I think I'll be in business. I think I'm going to have to dust off the old Apple 8500 and see if I can figure out the yellowdog install.

Victor Wren

Dear Victor,

Excellent. Thanks for the confirmation.

You have all the PPC executables when you install the ELDK :-) Also you can download a ready-to-run image from our FTP server: see ftp://ftp.denx.de/pub/LinuxPPC/usr/src/SELF/images/ppc_82xx/

Also see http://www.denx.de/twiki/bin/view/DULG/HowToAddFiles and
http://www.denx.de/twiki/bin/view/DULG/HowToIncreaseSizeOfRamdisk

There is no real need to do this.

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"Though a program be but three lines long,
someday it will have to be maintained."
- The Tao of Programming

D'oh! That works! I've got it booting BusyBox. What threw me is I was searching all over the ELDK tree for anything that looked like "initrd." Once I knew what to look for, I also found another possible in the Metrowerks BSP tree. Didn't think to look for ramdisk. Next stop: IDE. It LOOKS like there is support for the internal IDE in the kernel config (MGT 5xxx?)...

I just want to thank you effusively for the vast amount of work you have saved me, especially considering that, as a programmer, I'm a total hack. I was wondering, can the other development trees under the ELDK install directory be safely deleted? I only need ppc_82xx-

Victor Wren

Victor Wren
Designer,
Timension Inc.
1350 C Pear Ave
Mountain View CA 94043
(650) 564-9397
Fax: (650) 564-9398
Opinions stated in this letter are not necessarily those of Timension Inc. or the management. All Rights Reserved. No spitting.

Congrats :-)

In Linux? yes. But don't try enabling DMA (yet).

Yes, of course (alternatively you can start installing only
ppc_82xx).

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
It seems intuitively obvious to me, which  means  that  it  might  be
wrong.                                                 -- Chris Torek

So far, it looks like it's working good (without DMA :-). I've been able to mount an ext2 partition under a directory in the ramdisk. One odd thing I've had is that I can't seem to use a compressed uImage since I added the IDE config. If I gunzip the vmlinux.gz and use mkimage to create an uncompressed uImage, I can upload it to 100000, change kernel_addr to 100000, and run it just fine with flash_self (I have the initrd in flash at ff180000).

If I use the SAME vmlinux, and create a gzipped uImage, it starts to boot, then has a fatal error while trying to uncompress the image (this happened with the image that was created with "make uImage," which is why I started monkeying around to begin with.) Oddly, though, the gzipped uImage file I made wasn't exactly the same size as the one "make uImage" made -- different gzip versions? "mkimage -l" seems to like the image, so the header is okay.

I can't help but think that this has something to do with the size, since there's not much else that gunzip cares about. The "stripped" uImage is 670072 (0xA3978) bytes compressed (I don't remember the uncompressed size, but I think it was about a meg and a half), and the IDE-enabled image is 785281(0xBFB81) compressed, and 1887000 (0x1CCB18) uncompressed.

Could the gunzipper be running out of allocated space? I certainly have enough flash to store an unzipped kernel image, but I don't like mysteries. On this processor, too, it takes only a split second to unzip the kernel, so boot speed isn't an issue.

In looking around for memory allocation defs, I did find a typo in cmd_bootm.c:
#if defined(CONFIG_MPC5XXXX)

Every other reference I've found refers to "CONFIG_MPC5XXX"

Thanks again!
Victor Wren

Dear Victor,

This just means that your kernel image has become too big to be loaded at 1 MB; try downloading to and booting from 0x200000 instead.

It's overwriting the image as it uncompresses.

Fixed. Well spotted!

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Physician: One upon whom we set our hopes when ill and our dogs  when
well.                                                - Ambrose Bierce

Which one? The SCC or the environment problem?

I think we fixed this long ago.

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
He'd been wrong, there _was_ a light at the end of the tunnel, and it
was a flamethrower.                         - Terry Pratchett, _Mort_

Hi Stephan,

It works now...in fact, my reference design for STRATIX configuration was not similar to the IO mapping used by u-boot for NIOS...
It works with the Altera's "standard 32" reference design (with the .SREC in the CDKNIOS project and after u-boot recompilation too). I'll write a little doc on the IO and memory mapping to respect in order to used u-boot...
My student will work on the u-boot APEX port...just an adaptation I think... I may be a good idea that the stratix 1S10 board appears as its own board and not as a cyclone board in the u-boot distro...
My next step is to see is the standard 32 reference design is OK for uClinux support in order to freeze the hardware....
Many thanks;
Pat

Patrice Kadionik. F6KQH / F4CUQ
-----------

+---------------------------------------------------------------------+
+"Tout doit etre aussi simple que possible, pas seulement plus simple"+
+---------------------------------------------------------------------+
+ Patrice Kadionik                http://www.enseirb.fr/~kadionik     +
+ ENSEIRB                         fax   : +33 5.56.37.20.23           +
+ PO BOX 99                       voice : +33 5.56.84.23.47           +
+ 33402 TALENCE Cedex             http://www.enseirb.fr               +
+ FRANCE                          mailto:kadionik at enseirb.fr          +
+---------------------------------------------------------------------+