1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Flash a new kernel image to the NAS200

Discussion in 'Cisco/Linksys Network Storage Devices' started by jackito, Aug 19, 2010.

  1. jackito

    jackito LI Guru Member


    I have a two questions about flashing a new kernel to the NAS200 to replace the standard one.
    Right now I´m using kexec to boot my custom kernel but since I´m using it for a while and is stable, I would like to make it permanent.

    1- Is it possible to flash only the new kernel image to the NAS200 flash memory or I need to flash a whole firmware file?

    2- My kernel image is this size:

    -rw-r--r--    1 root     root       1848522 Aug  6 00:47 vmlinuz-2.6.19-br-usbip-custom_sd.c
    Based on the information I found in the FAQs:

    I guess my kernel image is too big? What do you think?
    Thanks in advance,

  2. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member

    First of all, yes your kernel is too big to fit into a firmware image: the maximum size is 0x1C0000 bytes, 1835008 decimal. You will have to shrink it by removing some unnecessary stuff, or by compiling stuff as modules.

    I believe I tried using dd to flash another kernel once, and failed, but this was before I knew that the /dev/mtdblock* devices have the wrong major ID.

    Once you have the kernel small enough, you may want to try to dd it to /dev/rom0, using a 128KB block size. If this gives an error message, just reflash the firmware through the web GUI (the kernel flash area is not accessed anymore after the boot loader copies it to RAM). If there is no error message, dd the data back to a file and run a diff to make sure that what's in there is what you put there.

    If you're able to flash the kernel but your system fails to boot, you can use the serial port to get into the Redboot command line to load a known working kernel from an HTTP or TFTP server on the network and boot it (you can even give it boot parameters e.g. to use one of the hard disks as root file system -- this is how I got Gentoo to run). Just download the stock bzImage at address 0x40000 and use the "linux" command (use "help linux" for more info; note, the help is not completely valid because of changes that Sercomm made to Redboot).

    Obligatory Redboot warning: NEVER USE THE FLASH COMMAND IN REDBOOT ON THE NAS200! It will brick your NAS without warning, you will have to use JTAG to recover.

    Let us know how it went!

  3. jackito

    jackito LI Guru Member

    Thanks a lot for the tips Jac!

    Actually just using dd to copy the kernel image to /dev/rom0 worked. The new kernel came up without problems.

    I´m only facing one issue, the new kernel is not launching /init from the rom. So no pivot_root is having place anymore.
    I googled for some time now for a "kernel hack" to accomplish this but I didn´t found where in the kernel configuration (or source file) the path to the init script can be defined.
    Maybe you can tell me? :)

    Thanks in advance

  4. jackito

    jackito LI Guru Member

    I think I found the answer.
    I´m compiling a new bzImage and then I will try it out and update. :biggrin:

  5. jackito

    jackito LI Guru Member

    Problem solved.
    I was using jac2b kernel tree for building the kernel image so it was lacking the modification that jac did in order to run "/init" script.
    Bottom line, as far as the kernel bzImage is less than 1835008 bytes to upgrade only the kernel in the flash you can run: "dd if=bzImage of=/dev/rom0 bs=131072."
    Then just reboot. :biggrin:

    Thanks again jac for the tips.

  6. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member

    That's GREAT news! That means the mtd driver that Sercomm put into the kernel is actually working. I was afraid their closed-source firmware flasher was doing some sort of magic to flash the firmware, and that if we would develop a distro that's not based on the stock firmware it would be impossible or difficult for users to flash the original firmware back. Now we know that a few well-composed dd commands will do the trick.

    Also, this should make it much easier to do kernel development: it's much easier to be able to just flash the kernel without building and flashing the root file system (dev/rom1), and without using the boot loader to do it.

    It should also make it possible for me to reset my MAC address that got changed to something like 00:C0:A0:D0:E0:00 when I had to use upslug to flash it through the boot loader.

    And speaking of boot loader: it should be easier to modify that too now (/dev/rom3), and eliminate that nasty Flash command, perhaps even do some cool stuff like boot from the hard disk. This will really help OpenWRT development (some time this century).

    Thanks for trying this, Jackito!


    PS I just realized this also makes it possible to store configuration data in flash: The Sercomm configuration should be in /dev/rom2.
  7. jackito

    jackito LI Guru Member

    Indeed, this is really great. Even doe, for the sake of testing a kernel image I still prefer to use kexec, it´s a lot more fast, easy and safe in case our kernel is not working. Just reboot and everything will be ok.
    Of course, after testing the kernel enough and if it is stable, as you said, is much more easier and faster to dd it to /dev/rom0 than flashing the whole firmware.

    Are you reading my mind? :tongue:
    I started to learn about redboot now. Because I saw during the kernel boot process that the same options are passed to it all the time (console and root parameters) and I´m interested just for the sake of learning how is this going on.
    About the root device it seems that this can be changed in the kernel image itself, with the help of rdev but I´m not sure if this change will be overrided by redboot parameters (probably yes).
    Anyway, my next test will be to dd a root filesystem (I changed your init script jac :rolleyes:) image to /dev/rom1 to confirm if it works the same way as flashing a kernel to /dev/rom0.

    Do you think there is gonna be some FS in this device or just a binary file (like in the case of the kernel image)?

    Oh BTW the kernel image I uploaded to flash memory is really nice. I disabled the fan control at kernel level (now I have complete control of it with a shell script, it will not be turned on after a few accesses to the disks) which is very very nice. I really wanted to disable this "feature". And also I changed the way how the USB drives are handled at least in one USB port so I can attach more than one disk using a USB hub. :cool:

    The more I learn (thanks to all the people that shares their knowledge and information) the more free I´m....if I have the source and can modify it.... :biggrin:

    Now I finally understand the words from Mr. Stallman, ten years ago when I assisted to one of his open source software conferences......

    <life irony>MCP - MCSA+M - MCSE - MCTS - MCITP: Enterprise Administrator</life irony> :rolleyes:

Share This Page