Having trouble building new kernel for this target.  I am using the serial port and flashing form U-Boot.  I have successfully flashed Attitude Adjustment and this is working great.  However I would like to use the USB support so I am building a newer version with USB support pre-installed.

The build, BARRIER BREAKER (Bleeding Edge, r38461), builds good, flashes good, and boots up OK.  My only problem is when I try to reboot from flash, then I get:

## Booting image at b0040000 ...
Check vendor string...    Image Name:   ADM8668 Linux Kernel(2.4.31)
   Created:      2013-10-21   2:48:18 UTC
   Image Type:   MIPS Linux Kernel Image (uncompressed)
   Data Size:    1048512 Bytes = 1023.9 kB
   Load Address: 80400000
   Entry Point:  80400000
   Verifying Checksum ... Bad Data CRC
##### Boot failed! #####

Researching the problem led me to conclude that the new kernel may be too big, so I tried several more times to ensure that the new build is the most basic:

1. make clean
2. echo CONFIG_TARGET_adm8668=y > .config
3. make defconfig
4. make menuconfig (with no changes, just verify target)
5. make

This gives me a kernel and squashFS the same size as Attitude Ajustment, but still will not boot from flash.  I can see that there were some changes in this file when I compare the bootup sequence near where the U-Boot environemnt is modified following a flash:

./target/linux/adm8668/files/drivers/mtd/maps/adm8668.c

Attitude Adjustment boot following flash:
===============================
[    0.390000] number of CFI chips: 1
[    0.390000] adm8668-nor: Filesystem type: squashfs, size=1675kB
[    0.400000] Updating U-boot image:
[    0.400000]   old: [size:  2883520 crc32: 0x04751f89]
[    0.580000]   new: [size:  1048512 crc32: 0x4e1b9585]
[    1.940000] Done
[    1.950000] Creating 3 MTD partitions on "adm8668-nor":
[    1.950000] 0x000000040000-0x000000800000 : "linux"
[    1.960000] 0x000000140000-0x000000800000 : "rootfs"
[    1.980000] mtd: partition "rootfs" set to be root filesystem
[    1.980000] mtd: partition "rootfs_data" created automatically, ofs=2F0000, len=510000
[    1.990000] 0x0000002f0000-0x000000800000 : "rootfs_data"
[    2.010000] 0x000000020000-0x000000040000 : "uboot_env"

Barrier Breaker (Bleeding Edge, r38461) boot following flash:
================================================
[    0.380000] number of CFI chips: 1
[    0.380000] adm8668-part: filesystem type: squashfs, size=1665kB
[    0.390000] adm8668-part: Updating U-boot image:
[    0.390000] adm8668-part:   old: [size:  2883520 crc32: 0x77f3319b]
[    0.450000] adm8668-part:   new: [size:  1048512 crc32: 0x37372a10]
[    1.760000] adm8668-part: done
[    1.760000] 3 adm8668part partitions found on MTD device physmap-flash
[    1.770000] Creating 3 MTD partitions on "physmap-flash":
[    1.770000] 0x000000040000-0x000000800000 : "linux"
[    1.790000] 0x000000140000-0x000000800000 : "rootfs"
[    1.800000] mtd: partition "rootfs" set to be root filesystem
[    1.810000] mtd: partition "rootfs_data" created automatically, ofs=2F0000, len=510000
[    1.820000] 0x0000002f0000-0x000000800000 : "rootfs_data"
[    1.830000] 0x000000020000-0x000000040000 : "uboot_env"

I need some guidance on what to look for so I can find the solution.  Again, the system will boot and run fine form TFTP, but not from flash.

Cheers!
Marc Giannoni

A brief review of my problem:   amd8668 Wildpass [wrtu54g-tm] builds successfully and flashes successfully.  But the reboot fails at the boot loader kernel checksum: "Bad Data CRC".  So the flash becomes corrupted by the first boot after flash. 

I have made incremental progress here.  The first area where the first boot appears to corrupt the flash I confirmed by repeated flashing attempts and using a power strip power switch.  I was able to flash and pass the boot loader CRC test repeatedly if I halted the boot process prior to this proceedure:

[    0.400000] Updating U-boot image:
[    0.400000]   old: [size:  2883520 crc32: 0x04751f89]
[    0.580000]   new: [size:  1048512 crc32: 0x4e1b9585]
[    1.940000] Done

Not sure why the MTD driver tries to update the boot loader flash map.  This does not seem to help.  SO... I stubbed this out in "trunk/target/linux/adm8668/files/drivers/mtd/maps/adm8668.c" by reusing a "goto" label in the code:

marc@kontiki maps]$ diff -p adm8668.orig adm8668.c
*** adm8668.orig    2013-11-07 23:16:25.337701353 -0500
--- adm8668.c    2013-11-10 10:35:32.368959767 -0500
*************** found:
*** 173,178 ****
--- 173,181 ----
          unsigned char *block;
          unsigned int offset;
 
+         goto out;
+
+
          offset = adm8668_parts[PART_LINUX].offset +
               sizeof(struct uboot_header);
 
Not I can reboot a new firmware image repeatedly as long as I halt the boot process in FAILSAFE.  SO.. yet again,  it appears that the FLASH is being corrupted.  By the same technique of preventing the following section from execution by etnering FAILSAFE or else the power switch I am confident this section is also corrupting the flash:

[   77.930000] jffs2_scan_eraseblock(): End of filesystem marker found at 0x0
[   77.950000] jffs2_build_filesystem(): unlocking the mtd device... done.
[   77.950000] jffs2_build_filesystem(): erasing all blocks after the end marker... done.
[  121.720000] JFFS2 notice: (823) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0.

Here again I need to come up to speed on the flash layout and the booting process.  I'm not sure what this is doing and why it needs to be "ERASING". 

Cheers!

The problem is changeset 34554

https://dev.openwrt.org/changeset/34554/

If you revert this patch, your wrtu54g-tm will be back in business.
I don't know whats is wrong, I just reverted the changeset 34554

This is an excerpt from my bash history how I made it boot again.

  512  git log

search for 34554 and take note of the git-id

  513  git revert e9824bd88f25c41db1a09e1752d44c4edb5fff48
  514  git status

shows that it could not revert the patch cleanly
I removed the build for linux

  515  rm -rf build_dir/target-mipsel_mips32_uClibc-0.9.33.2/linux-adm8668/
  516  make V=s

comment out the new code, using the above URL as hints

  517 vi build_dir/target-mipsel_mips32_uClibc-0.9.33.2/linux-adm8668/linux-3.3.8/arch/mips/adm8668/platform.c

  518  make V=s
  519  cp bin/adm8668/openwrt-adm8668-squashfs.bin /var/lib/tftpboot

And we are back in business

I have opened a ticket for this issue

https://dev.openwrt.org/ticket/14745
/Peter

(Last edited by lorenzen on 9 Jan 2014, 17:55)

r34554 was reverted recently in r42170.

The problem with r34554, was that the new crc was not computed over the full linux mtd partition.

I made a fix for that, which you can see in https://dev.openwrt.org/ticket/14745

I still have one issue, whenever I install a new image using sysupgrade, it will not boot
the first time. To get around that I boot the same image from tftp which fixes the crc,
and the everything is OK after that.

Do any-one have an idea, why a virgin image does not include the crc uboot requires? and where to look?

The real way to fix this would probably be to make the image with the linux mtd's length/crc embedded,
or have a way to fix that after sysupgrade - that way we would not need the first-time fix at all

edit: I should note that sysupgrade -n  works as expected, it only when trying to bringover the old configuration it goes wrong
        like described here: https://dev.openwrt.org/ticket/8960, although it is a different platform it is similar

/Peter

(Last edited by lorenzen on 4 Sep 2014, 17:43)

Inspired by how they handled a similar problem with the wrt160nl (ticket 8960) I though I would just try a similar cure here.
and it works very well, adding just 17 lines and making 105 lines redundant in the codebase. and now sysupgrade transfer of config files works too.

Before the  lzma-loader, linux-kernel, squashfs where encapsulated in an uImage. which has a crc-check

The cure is to only encapsulate lzma-loader and linux-kernel in the uImage and append squashfs and maybe files saved by sysupgrade to it

The best part is that we can remove the whole fixing of the crc in driver/mtd/maps/adm8668.c since it will never be executed.

I have successfully installed a new systems both with u-boot update_kernel, and sysupgrade.

Here are the necessary changes to target/linux/adm8668/image/Makefile relative to r42162

I will update the https://dev.openwrt.org/ticket/14745 with full changes shortly

/Peter

PS: for people wanting to use  fw_printenv/fw_setenv on the uboot environment, you need to do:
      echo /dev/mtd3 0 0x400 0x2000 >/etc/fw_env.config

diff --git a/target/linux/adm8668/image/Makefile b/target/linux/adm8668/image/Makefile
index 9e25224..44626a4 100644
--- a/target/linux/adm8668/image/Makefile
+++ b/target/linux/adm8668/image/Makefile
@@ -25,6 +25,13 @@ define MkImage
         -d $(3) $(4)
 endef
 
+define MkImageLzma
+    mkimage -A mips -O linux -T kernel -a 0x80400000 -e 0x80400000 \
+        -C $(1) $(2) \
+        -n "ADM8668 Linux Kernel(2.4.31)" \
+        -d $(3) $(4)
+endef
+
 define Build/Clean
     $(MAKE) -C lzma-loader clean
 endef
@@ -40,8 +47,12 @@ define Image/Prepare
 endef
 
 define Image/Build
-    ./my-mkimage $(KDIR)/loader.bin $(KDIR)/root.squashfs    \
-        $(KDIR)/fs_mark $(BIN_DIR)/$(IMG_PREFIX)-$(1).bin
+    $(call MkImageLzma,none,,$(KDIR)/loader.bin,$(KDIR)/loader.uImage)
+    dd if=$(KDIR)/loader.uImage bs=64k conv=sync of=$(KDIR)/vmlinuz.tmp
+    dd if=$(KDIR)/root.squashfs bs=64k conv=sync >> $(KDIR)/vmlinuz.tmp
+    dd if=$(KDIR)/fs_mark bs=64k conv=sync >> $(KDIR)/vmlinuz.tmp
+    cp $(KDIR)/vmlinuz.tmp $(BIN_DIR)/$(IMG_PREFIX)-$(1).bin
+#    rm -f $(KDIR)/vmlinuz.tmp $(KDIR)/loader.uImage
 endef
 
 define Image/BuildKernel
@@ -51,7 +62,7 @@ define Image/BuildKernel
     $(call MkImage,gzip,,$(KDIR)/vmlinux.bin.gz,$(BIN_DIR)/$(UIMAGE)-gzip.bin)
 ifeq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),y)
     cp $(KDIR)/vmlinux-initramfs.elf $(VMLINUX)-initramfs.elf
-    cp $(KDIR)/vmlinux $(VMLINUX)-initramfs.bin
+    cp $(KDIR)/vmlinux-initramfs $(VMLINUX)-initramfs.bin
     $(call CompressGzip,$(KDIR)/vmlinux-initramfs,$(KDIR)/vmlinux-initramfs.bin.gz)
     $(call MkImage,gzip,,$(KDIR)/vmlinux-initramfs.bin.gz,$(BIN_DIR)/$(UIMAGE)-initramfs-gzip.bin)
 endif