I can't said for sure for the "sheeva.with-linux" kernel but I don't see why not. I compile my own kernel as long as it have the guruplug support then it will boot. the dreamplug have not register to ARM tree as a new machine type so all reference to it is a guruplug board.

Thanks for the information.

I think NOR is different than NAND is there should be no bad block, at least from source code I don't see and bad block management (as there no {read/write}.e subcommand)

So the command you use to flash is "sf probe 0; sf erase 0 ...; sf write 0" ? I was not sure if the "sf" command work will.

Dreamplug is different from the previous plug is that internal storage changed from NAND to NOR, so the access interface changed too. to access the NOR device it go through the SPI interface. also the NOR device MX2510606 is not a well known flash device so far I have yet to find the exact specification for the device. As right now all the main line linux, uboot and openocd have no code support this device.

I been try to reverse engineering to work out a u-boot, so far I still in research stage. Once I got a working version I will post to this forums for the daring soul to try

I am little bit confuse, you should not get the "Invalid boot device" message after you have successful run "fatls usb 0 ..." command. did you reset in between the two commands? so let me reiterate sequencePlease post output from all of above command sequence.

Good luck

The "magic key" sequence require all together four keys in order to happen, right now it looks like only 3 keys press down and the other key(s) is not one of the action key that is why it pop the help messages. I am no sure it is even possible using serial port from keyboard can generate these keycode. you are correct to disconnect the jtag connection and see that help.

Good luck

The kernel is compiled with "magic key" to support reboot. the "magic key" key sequence is 'ctrl-alt-prtscn(SysyRq)' then with one of the letter in the '(' ')' so somehow your serial input is transmiting the "magic key" key sequence.

Good luck

ok, looks good. now do This will load the kernel at 0x06400000, now setup console and tell kernel where is root file system by the last command "bootm ..." should start booting linux, so base on your first post this should be where it failed, please post the command you entered and its output, we will have to check during steps above where it failed.

Good luck

OK, since we are not able to see the screen, we will have to do step by step process.

First get in to Marvell>> prompt. now do the result should stated it have at lease one storage found. if not than you need to check if you have the uSD insert correctly and re do the step above to prove it. once you have it working then do The result should show at lease have a file name "uImage", if not than you have not successful load uImage to the first partition as you stated in the first post, please go back and try to correct it.

If you do get correct result then please post your u-boot env so we can debug from there.

If it is possible please post each step result as is. it will help to understand the situation.

Good luck

What is error message you got when you try to boot? there are no magic setting to make the internal uSD bootable. all setup is in the u-boot environment so as long as you still have your u-boot environment intact than there is no reason why you can not boot.

Please be very careful, if you brick you dreamplug than unless you sent it back to GST there is no way to recover. openocd have no support on spi to flash. there is no u-boot source code for you to build a new one for you self. the 'dream_bum_spi.tar.bz2' have a uboot binary but no sure if any one tested so I would not depend on it.

You can always make your test code save to the internal uSD, just be sure you have one partition formated in "fat" current u-boot only support load from "fat" file system.

good luck

The .kwb contain a checksum and some instructions to direct internal bootrom where to load next bootloader and where to go next.

@crunch, here are promised u-boot 2011-03 boot at 0x600000.

I upload two versions. the u-boot.bin is use to run from memory. the u-boot.kwb is use to flush in to NAND. To run from memory it must be at 0x600000, To flush any where is fine just dont mix with running u-boot (start from 0x1F954000 upward)

Good luch

Check if you have eth1. some version of udev have a rule that will record the MAC address, so moving SD to a new plug will give you a new eth interface.

Good luck

I will upload the correct version later. I am a little bit of concern of you using the version that will load on 0x600000 because your previous post about during your tftp session loading to 0x600000 hung your plug. like I explained earlier the only one time I got that condition is when I was playing with cpu cache. I am not sure what is your plug condition that may cause the session freeze so if you want to try out the production version just be sure you have some back out plan, i.e. using openocd to re-flash you old u-boot.

One option you can consider is to chain load u-boot. use you existing u-boot in NAND chain load the u-boot successful boot linux. to do that you can tftp the uploaded version to memory address 0x800000 then flash it to NAND storage address 0x80000. Once flash successfully you can setup you existing u-boot default load u-boot from NAND@0x80000 to Memory@0x800000. then use the "go" command just like you did in tftp session.

The version I will be uploading will be latest from Das u-boot 2011-03 with minor patches to test speed up in native mem{cpy,move} and fix a small IDE problem.

Good luck