Buffalo NAS-Central Forums

I have completed porting U-Boot 1.1.4 to the LinkStation v2 (mips). It is based on my port of U-Boot to the LinkStation v1 / LinkStation HG and it has the same functionality. I have also completed porting linux-2.6.22 to the LinkStation v2.
I have uploaded u-boot-1.1.4-list-v2-1.0.0.tar.gz, vmlinux-2.6.22.ls2.gz and kernel-modules-2.6.22.ls2.tar.gz.
As usually, full instructions on my web page http://www.linuxnotincluded.org.uk.

Ya rule

As one of many, who will benefit from your work let me say: well done! and thanks a million!

Brahma !

thats AWESOME.

LNI....you are one of small group of persons who already managed to get into the hall of fame....and now you did it again! unbelievable!

i hope you enjoy the tera pro v1..

unfortunately we are not able to test Uboot + 2.6-kernel on our dev-LS2`s...the flash chip cannot be detected anymore on both LS2`s kuroguy has....

ok, someone needs to confirm this. then its time to create an announcement on the mainpage-news-box.

In the process of putting your work into foonas, great stuff!

However, I run into issues building u-boot:

http://paste.lisp.org/display/46390

The toolchain involved is using gcc 4.2.1 and glibc 2.6 for cross compiling (these can easily be changed), any suggestions here?

You might have a buggy compiler. I have read about problems with gcc 4.1 compiling the Linux kernel.
The first error appears to be a problem with the expansion of a macro invoked in the line 60 of pci.c:


The printf warning is a red herring. It is true that I should have included common.h but the function dump_bridge is not used anyway.

I am using the Denx ELDK 4.0 for mips and it uses gcc 4.0 and it compiles u-boot without any problem. I have just used gcc 3.3.3 from ELDK 3.1.1 and it worked too. However, the size of the generated code is well larger than the size given by gcc 4.0.

Continuing to investigate this. I also use a powerpc version of this toolchain to build for the other linkstation platforms (but this could still mean its buggy I guess!). It seems the rest of the foonas distribution for ls2 (kernel et all) all build with this toolchain, however im 75% through the build and other things can still break!

Hoping to post foonas for ls2 with your kernel inside this evening for someone to test out!

It is also possible that the code is not compatible with gcc 4.1. I remember all kind of strange things happening when I was trying to build the kernel with an unsupported version of gcc.
In my experience, a few things can happen when you get a compilation error with code that compiles fine in a different environment:

1. compiler bug;
2. the compiler doesn't like the code;
3. the wrong header gets included because of the order of the -I options;
4. a real bug in the compiled code masked by features of the compiler used for the original build;

I don't think it is a bug as the code compiles fine with both gcc 3.3.3 and gcc 4.0.
I am quite sure that I have seen the recommendation not to use gcc 4.1 to build the Linux kernel. They considered that version experimental and buggy. Moreover, the fact that a version of gcc works fine on a platform, it doesn't necessarily mean that it will work on another platforms. I have seen comments on http://www.linux-mips.org about bugs in gcc for mips. They have recommendations about the toolchain to use. I chose ELDK because I am sure that lots of people use it to compile both U-Boot and the Linux kernel. I also like the fact that it comes with a native environment which I can use as nfs root.
What I can suggest at this time is that you download ELDK 4.0 and try it. Depending on the speed of your Internet connection, it shouldn't take more than 30 min to download and install ELDK. You can always delete the installation if you don't like it.

Ahha, I'm trying to do this completely from within openembedded to build the whole foonas distribution with, using the toolchain(s) provided there. I dont know if I can use an external toolchain with OE (I will check), this would not be the preferred option thinking from on OE point of view. Thanks for the tip though

Its pretty easy to change the foonas toolchain for this one platform and I think I will try tinkering with the gcc versions next.

ok, we have the first brick.

Bauldrick and Kaiten both loaded uboot successfully via uloader.o

Kaiten flashed it to the flash and now has a brick for now.
4 blinks first (fan error), then 5 blinks (flash rom error).

i ll take care to get Kaiten a jtag10 cable for reflashing.

any clues what the problem could be?

i know we got LNI an LS2 which was crippled from the beginning...maybe there was something that hasn`t discovered so far.

It is too late now to double check the build but I'll try to do it tomorrow. The RAM and flash builds are identical but the link address is different. Flashing the RAM build is guaranteed to brick and the result is quite amazing as the code executed is "random" (read from uninitialized RAM) so it can send any kind of weird commands to the microcontroller until it generates and exception and dies.
The LS I have is in fine shape, kuroguy has done a great job. I couldn't find anything wrong with it.
The information is too sketchy. Was the wrong flash done with U-Boot itself? Which binary has been used? The one that I have uploaded or another one? If it is another one, can it be uploaded so I could look at it? What compiler has been used?
The best thing would be a step-by-step description of what exactly Kaiten did without omitting anything.

U-Boot 1.1.4 LiSt V2 (mips) 1.0.0 (Aug 18 2007 - 15:18:51)
stdin : nc
stdout: nc
stderr: nc
IDE: Bus 0: OK Bus 1: OK
Device 0: Model: SAMSUNG HA250JC Firm: WE100-34 Ser#: 0S491JYS094808
Type: Hard Disk
Supports 48-bit addressing
Capacity: 238475.1 MB = 232.8 GB (488397168 x 512)
Boot in 01 seconds ('s' to stop)...s

=> md
md
Usage:
md - memory display

=>


From here do I simply :

=>run upgrade ??

I have u-boot-v2-mips.flash.bin in /mnt/hda/share/u-boot
I don't want to needlessly brick it if this is how Kaiten did it?

lol, it's like seeing a big red button saying "don't press me, whatever you do, don't press me!"

The only thing that the flash build does over the RAM build is to initialise the DRAM controller. The code just checks if it's running from RAM or flash addresses and skips the initialisation part if it's running from RAM.

The only way you could brick your ls2 is if the RAM chips in your ls2 are so different from the ones in mine that they fail to initialise properly. I don't see this being possible as I took the initialisation parameters from the original bootloader and compared them with the spec for the actual RAM chips. I can't believe that Buffalo used RAM chips with different specs, especially that the specs are quite straightforward: DDR 400 MHz, CL3.

I agree, however, that you should wait for Kaiten's reply before going any further. A step-by-step account would really help.