upgrading STK1000 to current buildroot failed [now fixed]

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I grabbed the current Atmel buildroot version, installed and compiled everything from scratch for STK1002.

No errors, and I ended up with the root filesystem.

I upgraded uboot several times to get past the arch=11 error, that finally worked.

Then I used the instructions on the Wiki to copy the image to the SD card, as in:

https://www.avrfreaks.net/wiki/in...

So far, so good. One thing that I noticed is that the previous SD card image had uImage in the root directory, however in this resulting SD card image it is in the /boot subdirectory. I was wondering how uBoot would know to look in there, and in fact it didn't, even though I upgraded uBoot to the image that gets compiled with the latest buildroot. To get past this silly error I made a copy of uImage, and now uBoot finds the copy in root and proceeds to boot it.

Note that I have made absolutely no modifications.

We're talking an out of the box STK1000, and a successful buildroot with no modifications to any files. So these are the versions I end up with:

U-Boot 1.3.0.atmel.2
Image Name: Linux-2.6.23

The full boot log and error message is in the attached file, here is the last part:

Using physmap partition information
Creating 3 MTD partitions on "physmap-flash.0":
0x00000000-0x00020000 : "u-boot"
0x00020000-0x007f0000 : "root"
0x007f0000-0x00800000 : "env"
atmel_spi atmel_spi.0: Atmel SPI Controller at 0xffe00000 (irq 3)
mmc_host mmc0: Atmel MCI controller at 0xfff02400 irq 28
Registered led device: r1:red
Registered led device: g1:green
Registered led device: b1:blue
Registered led device: r2:red
Registered led device: g2:green
Registered led device: b2:blue
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Root-NFS: No NFS server available, giving up.
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "mmcblk0p1" or unknown-block(2,0)
Please append a correct "root=" boot option; here are the available partitions:
1f00 128 mtdblock0 (driver?)
1f01 8000 mtdblock1 (driver?)
1f02 64 mtdblock2 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)

Attachment(s): 

Last Edited: Sat. Dec 29, 2007 - 06:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since buildroot was successful and since it wasn't a beta version, I'm guessing that the build and the software are both OK, and the main problem is related to getting from the root file system compressed image to the SD card.

Are there any better instructions than the ones referenced in the previous post?

Interesting that the instructions for the NGW reference a method based on the dd command, whereas for the STK1000 you mount a temporary file system and use dd.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

RayKAvr wrote:
One thing that I noticed is that the previous SD card image had uImage in the root directory, however in this resulting SD card image it is in the /boot subdirectory. I was wondering how uBoot would know to look in there, and in fact it didn't, even though I upgraded uBoot to the image that gets compiled with the latest buildroot. To get past this silly error I made a copy of uImage, and now uBoot finds the copy in root and proceeds to boot it.
The real way around this is changing the /uImage clauses in your uboot bootargs to /boot/uImage.
RayKAvr wrote:
Note that I have made absolutely no modifications.

We're talking an out of the box STK1000, and a successful buildroot with no modifications to any files. So these are the versions I end up with:

You sure you haven't made mods? It's trying to boot over NFS, it's not looking at the SD card. Make sure your bootargs point to your SD card with no references to nfs or /dev/nfs or anything.

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Squidgit, as always thanks for your reply.

Right, I have not made any changes AT ALL, and that's why I'm perplexed that this doesn't work.

If changes to bootargs are required then those are not documented.

Regarding NFS, again I made absolutely no changes.

Maybe if there is a problem with the SDcard it somehow then proceeds to try other methods like NFS?

Your wonderful instructions were the key in getting a clean buildroot... and now I just need to get it from the build directory onto the Atmel supplied SDcard while preserving the file structure.

Maybe a different size or type of SDcard is now default?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Herrm, it shouldn't default to NFS if the SD card bit buggers out.

Could you post your bootargs and bootcmd?

Bootcmd should look something like "mmcinit; ext2load mmc 0:1 0x10300000 /uImage; bootm 0x10300000" and bootargs should be something like "console=ttyS0 root=/dev/mmcblk0p1"

After that's been fixed, can you stick the SD card in a linux PC can you open it and see all the files and junk?

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the distribution in the current buildroot release doesn't change the bootargs, or if the 2 uBoot updates didn't change the arguments, they would be factory stock. With 2 uBoot updates I'm referring to one uBoot update to resolve the arch=11 failure and another update to use the uBoot that results from the buildroot. Anyway, here goes.

I took out the SD card and then captured the text from uBoot. When it was done I typed printenv.

Yes, I can see all the files on the SDCard just fine if I simply plug the SDcard into a Sony PC that has Ubuntu 6.10.

Toolchain was not installed separately, after a virgin Ubuntu 6.10 install I used your very excellent method of adding the staging_dir to the PATH.

And yes, I can see that this bootcmd is looking for a /uImage so that's why I'm perplexed that the buildroot generated image does not have it in / and instead has it in a /boot subdirectory. Maybe that is the new default?

------

U-Boot 1.3.0.atmel.2 (Dec 27 2007 - 17:47:50)

U-Boot code: 00000000 -> 00010020 data: 00015df0 -> 0004c440
SDRAM: 8 MB at address 0x10000000
Testing SDRAM...OK
malloc: Using memory from 0x10773000 to 0x107b3000
DMA: Using memory from 0x1076f000 to 0x10773000
Flash: 8 MB at address 0x00000000
DRAM Configuration:
Bank #0: 10000000 8 MB
In: serial
Out: serial
Err: serial
Net: macb0, macb1
Press SPACE to abort autoboot in 2 seconds
mmc: command 55 failed (status: 0x00100025)
mmc: command 1 failed (status: 0x00100025)
No MMC card found
** Bad partition 1 **
## Booting image at 90400000 ...
Bad Magic Number
Uboot> printenv

bootargs=console=ttyUS0 root=/dev/mmcblk0p1 fbmem=600k
bootdelay=2
baudrate=115200
ethact=macb0
ethaddr=00:04:25:19:0A:98
eth1addr=00:04:25:19:0A:99
bootcmd=mmcinit; ext2load mmc 0:1 0x90400000 /uImage; bootm 0x90400000
stdin=serial
stdout=serial
stderr=serial

Environment size: 261/65532 bytes
Uboot>

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

RayKAvr wrote:
I took out the SD card and then captured the text from uBoot. When it was done I typed printenv.
You can just hit 'space' when it tells you too, but your method works as well :-)
RayKAvr wrote:
Yes, I can see all the files on the SDCard just fine if I simply plug the SDcard into a Sony PC that has Ubuntu 6.10.
Coolies
RayKAvr wrote:
And yes, I can see that this bootcmd is looking for a /uImage so that's why I'm perplexed that the buildroot generated image does not have it in / and instead has it in a /boot subdirectory. Maybe that is the new default?
It is the default for buildroot, yes. It isn't too hard to change the /uImage to /boot/uImage in your bootargs :-)
RayKAvr wrote:
Uboot> printenv

bootargs=console=ttyUS0 root=/dev/mmcblk0p1 fbmem=600k

Quite, quite confused here. That bootarg should not produce what we're seeing. In fact, it should not produce any output. At all. The ttyUS0 should be ttyS0, US0 was used on very old kernels and when used on newer ones, no boot output will be produced.

Do you have a jtagicemkii? Maybe a good way to proceed would be to erase the top 64k of flash where the uboot environment lives. uboot will see that there is no environment there and use some defaults which should work OK. You can do the erase from the uboot command line if you don't have a jtagicemkii.

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmmm. Well, this STK1000 was completely stock.

I tested it out of the box, and it worked as the factory default is supposed to work. Remember, they come from the factory programmed to be consistent with the v0.93 BSP CD.

I do have both the BSP 1.0.0 CD and the BSP 2.0.0 CD updates, but they never worked. (Separate issue related to Ubuntu and toolchain versions, now fixed with a virgin install of Ubuntu)

Prior to upgrading uBoot to take care of the arch=11 problem everything worked fine.

I understand that most people here have been upgrading their STKs with every new release, but especially now that the BSP 2.0.0 CD is no longer available there has to be a documented path from a factory stock STK1000 to something that runs the current stable release of Linux, which according to the buildroot results appear to be U-Boot 1.3.0.atmel.2 and Linux-2.6.23

Lots of AVR tools here but no JTAGicemkII.

The uBoot upgrade program works fine and that's how I got to the 1.3.0 version.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, found it.

Current buildroot = 2.6.23.atmel1, which according to the following needs "rootwait"

That fixed it, so basically we need 2 updates to the boot arguments of a factory stock STK1000 to be able to boot a current buildroot release. One to make it wait for the root file system and the other to let it know that uImage is now in the boot subdirectory.

-----------

http://avr32linux.org/twiki/bin/...

2.6.23.atmel.1
This is basically the 2.6.22.atmel.5 release rebased onto the 2.6.23 upstream release, with the avr32-related changes that are scheduled for 2.6.24 included as well.

Note that in order to use root filesystem on MMC or SD card, you need to specify "rootwait" on the command line instead of "rootwait=1". Unfortunately, there's currently no common parameter that works on both 2.6.22.atmel.x and 2.6.23. This will be fixed in the next release.