Hi Guys,

I saw Atmel’s ATNGW100 kit is just recently added and already is tagged as working in Kamikaze, amazing!
Has anyone started playing with it?
It is a good afforrdable piece of h/w – one lack no WiFi.
I guess an option of addingWiFi is MMC/SDIO interface, Any ideas?

Thanks in Advance!

I already try to build OpenWRT for avr32 for 2 days ..., with no success ...

I have never tried to build it,
but installed Kami 7.07 avr32 image form here:
http://downloads.openwrt.org/kamikaze/7.07/avr32-2.6/
there were no problems at all

Hi Boomer,
I m installing the openWRT image 7.09 on the SD card, but I don't know how to configure u-boot to use a squash filesystem booted from SDcard, Do you have any idea ???

Thanks

Has anyone got this to work? Has it been tested on the NGW100? There are no doc's on how to install. The two image's I have 2 NGW100's an tried it on both. Here is what I did:

1. Downloaded openwrt-avr32-2.6-uImage from http://downloads.openwrt.org/kamikaze/7.09/avr32-2.6/

2. I copied the uImage from the ngw100 to my SD card:
cp uImage /mnt/media/uImage.old

3. I renamed openwrt-avr32-2.6-uImage to uImage an copied it to my ngw100 in the / directory.

4. Reset the NGW.

Now it boots up and I get a kernel panic 

The last 2 lines read:

Warning: Unable To Open an initial console.
Kernel panic - not syncing: No init found. Try passing init= option to kernel.

Any help would be great. I would love to boot into openwrt.

It works as expected.

The 7.09 does not have the support for the MMC/SD device. You cannot boot from MMC/SD unless you backport the drivers to 2.6.22.1 and provide them to the kernel in the initrd (or build the current trunk with your options).
You will have to use the squashfs image. The OpenWrt expects to be executed from the flash memory.

There is no warranty of any kind that the following guide will not blow up your computer, the device or your head.

The NGW100's memory map is as follows:

0x00000000-0x0001ffff: U-Boot
0x00020000-0x007effff: usable flash space
0x007f0000-0x007fffff: U-Boot's environment
nothing
0x10000000-0x20000000: SDRAM
nothing
0x24000000-0x24003fff: internal SRAM

Connect to your NGW100 using the serial terminal (115200 8N1), reset it, press space to get into U-Boot. The U-Boot's manual is your mandatory reading.

WARNING: Using wrong addresses or commands may result in the broken u-boot! Remember that the JTAG solution for the AVR32 family is very expensive!

You need to load the squashfs image. You can use any U-Boot's method including the MMC/SD ext2 access which is built-in into the Atmel's u-boot. Train it until you are able to load the image into U-Boot.

You need to setup the IP information for U-Boot (you can use dhcp as well) and load the image to the specified SDRAM address (notice the address 0x10000000 is the start of the SDRAM space):

UBoot> setenv ipaddr <the NGW100's IP address>
UBoot> setenv serverip <the tftp server's IP address>
UBoot> tftp 0x10000000 openwrt-avr32-2.6-squashfs.img

You can copy the image to the ext2 partition of a MMC/SD card (ex.: to the root of the partition) and load it from there:

UBoot> mmcinit
UBoot> ext2load mmc 0:1 0x10000000 /openwrt-avr32-2.6-squashfs.img

0:1 means the card 0, the partition 1 (modify it as needed, you can have more partitions).

If you managed to get the image to the U-Boot's memory, you can write it to the flash. You have not changed anything so far, the original or previous setup is still working. You will not be able to use the original setup after this step unless you write the original / image back to the flash (using the same steps).

You should backup the mtd2 partition if you want to save your changes to the original jffs partition. Otherwise you can restore it using images provided by Atmel (or built by you).

WARNING: Using wrong addresses or commands may result in the broken u-boot!

The U-Boot is preventing you to damage the unwanted part of memory. You need to unprotect the unused part of the flash memory, erase it, load the image to the SDRAM and write it to the flash (see the memory map above for the meaning of 0x20000 and 0x7EFFFF addresses).

UBoot> protect off 0x20000 0x7EFFFF
UBoot> erase 0x20000 0x7EFFFF
....
UBoot> tftp 0x10000000 openwrt-avr32-2.6-squashfs.img
Bytes transferred = 1900544 (1D0000 hex)

Notice the size of the image (1D0000 hex), you will need this number for the following command.

UBoot> cp.b 0x10000000 0x20000 0x1D0000
Copy to Flash... done
UBoot> protect on all

You are writing the contents of the SDRAM at the address 0x10000000 to the flash address 0x20000 with the length of 0x1D0000.

Now you need to modify the U-Boot's parameters to load the image and provide the kernel with necessary parameters. The U-Boot will expand the kernel from the specified address to the start of the SDRAM and execute it.

UBoot> setenv bootcmd 'bootm 0x20000'

The squashfs image has the kernel image prepended, so it starts at the 0x20000 address (see the memory map above). The flash memory is mapped directly into the memory space, so you do not need to load it to the SDRAM. The U-Boot will get the start (+ the length), and the execute address from the kernel image.

UBoot> setenv bootargs 'console=/dev/ttyS0,115200 root=/dev/mtdblock2 rootfstype=squashfs,jffs2 init=/etc/preinit'

This is the default kernel's command line for OpenWrt, the mtd2 is the squashfs/jffs2 partition.

And finally write all changes to the U-Boot's environment:

UBoot> savenv
Saving Environment to Flash...
...

Now you just press the reset button or issue:

UBoot> reset

to load the kernel and start your OpenWrt AVR32 experience.

If you are tired looking at the sys led heartbeat, issue:

[ -f /sys/class/leds/sys/trigger ] && echo none > /sys/class/leds/sys/trigger

If you want to switch the sys led on, issue:

[ -f /sys/class/leds/sys/brightness ] && echo 255 > /sys/class/leds/sys/brightness

If you want to switch the sys led off, issue:

[ -f /sys/class/leds/sys/brightness ] && echo 0 > /sys/class/leds/sys/brightness

if you want to load the kernel image directly, you need to use a different SDRAM address so that the U-Boot would not overwrite the image while decompressing it.

UBoot> tftp 0x10300000 openwrt-avr32-2.6-uImage
UBoot> bootm 0x10300000

You can use any SDRAM address higher than the size of the decompressed kernel. Using the address 0x10300000 will reserve 3 MiB of memory at the start (the kernel image size in the trunk is about 2 MiB).

P.S. What is driving people to repeat the error thinking that it will eventually end up with success?

Thank you that worked great! I had loaded the img but had no idea to add the args to uboot!

THANK YOU!!!

Hi!

What about the SD/MMC-Card patches - it would be great to boot the system from mmc !
This works great for testing and the internal flash is only needed for recovery.

What is needed to get this working ?  AFAIK it already works in buildroot, but what needs to be done to support that in openwrt ?

Just another kernelconfig ? Newer kernel ?

Best regards
Jan

You will have to build it yourself.

The current OpenWrt trunk holds patches for the kernel 2.6.23.1 including the MMC/SD code.

Linux version 2.6.23.1 (gcc version 4.1.2) #11...
...
mmc0: new SD card at address b368                                               
mmcblk0: mmc0:b368 SMI   993792KiB                                              
 mmcblk0: p1 p2 p3                                                              
...

You would need the initrd to use the MMC/SD partition as the rootfs because filesystem modules are standalone. You can of course modify the kernel's configuration for the kernel to include the required fs modules.

How do i enable initrd in openwrt trunk ??
Also if i enable mmc built-in, it is not detected - maybe because of missing rootwait cmdline-option (available since atmel.3)

Sorry, I have not tried it yet. Try it yourself and write a howto.

I am currently running the OpenWrt trunk from the flash and the Atmel's build from the SD card.

The OpenWrt AVR32 port is still problematic. The 7.09 repository contains only packages that compiled successfully at that time, the packages were not updated for the AVR32 target in the trunk.

I am just fighting with the buildroot (although nbd claims that it builds without issues for him):
- the uClibc-0.9.28(.2) does not work for all packages (OpenWrt uses only one version for all targets)
- there are several packages marked dependant on the dynamic libgcc, which is not built for this target
- many packages need the updated config.guess and config.sub - not all packages use the Build/Configure/Default, some of them use the aux dir which is not updated by the Build/Configure/Default
- some packages need the update to compile for the AVR32 target, for example strace

I think that the AVR32 port needs a full update to the gcc, uClibc versions and kernel patches used in the Atmel's buildroot.

BTW: The rootwait parameter is the standard kernel's command line parameter (see Documentation/kernel-parameters.txt).