Author Topic: Reviving a 'bricked' CnMnetboot  (Read 6549 times)

jimux

  • Jr. Member
  • **
  • Posts: 96
Reviving a 'bricked' CnMnetboot
« on: October 31, 2009, 01:14:54 PM »
I recently ended up with a machine which no longer booted up.  The primary cause was numerous bad blocks on the nandflash which resulted in running out of space whilst loading 3MXv3final, and corrupting the bootloader whilst attempting to investigate the cause.  It now no longer performs the recovery function by holding down F3 or Ctrl+Fn+Shft whilst switching on. Simply switching on just shows a tinted screen which fades over time.

However what I do have is a machine which has 3MX1.1 and Retro loaded in nandflash, plus various other images loaded on SD cards.  By inserting a chosen SD card and holding down Fn+Ctrl+Shft I can select which image I want to load.  The process to achieve this is fairly simple once you have gathered all the information and resources.  

1.  Create an SD card which has a 30Mb primary FAT16 partition, and a second primary FAT partition to fill the rest of the card.  If the card is greater than 1Gb then the second partition will have to be FAT32, otherwise FAT16 will do.

2. We now put boot software on the 30Mb partition.  The software is a combined bootloader and minikernel named uImage.   This you can get from http://projects.kwaak.net/twiki/bin/view/Epc700/KernelStartupF2F3

Use uImage-v002_F2mcca2F3mtdblock3 to get you a boot menu choice between the SD card and existing software in flashmemory.
Use uImage-v001_F2nand2F3mtdblock3 to choose between the original in flash and a new image in the extended flash card.  Note: Some machines do not have the extended 2Gb flash so cannot use this option.

3.  Rename your selected file to uImage ( for those viewing with a non-serif font the second letter of the file name is an upper case 'eye')

4.  Now select the additional image you want to load.  eg. Recovery_Retro.img and untar it into place.  
for example
          tar -xjf sourcedir/Recovery_Retro.img -C targetdir/
where sourcedir is where you downloaded the image to, and targetdir is the second partition of the SD card.  This will take some considerable time - go make a cup of tea.  

Now open the new software and remove the file flash_eraseall from the root directory.  This is important as otherwise it will wipe the flash memory during bootup.

5.  Insert the SD card in your netbook, hold down the Fn+Ctrl+Shift keys on the left side and switch on.  Keep the keys held down until you get a display labeled celinux 2.4.20 with  prompts for F2 and F3
The options on the prompts depend on which uImage you selected,
       v002 gives      F2=/dev/mmca & F3=/dev/mtdblock3  (SDcard or original flash)
       v001 gives      F2=/dev/mtdblock5 & F3=/dev/mtdblock3 (original or extended)

You will notice that we have missed a step if we want dual images in flash.  We have to carry out steps 1-3 above to get a bootable SD card.  Miss out step 4 and attempt to boot the machine.  Whilst you will get two options in the boot menu only the /dev/mtdblock3 option will be valid.  Once live you can load the software into Extended flash in the same way as we untarred to an SD card.
DO NOT REBOOT YET.
File /etc/init.d/rcS calls mount_extend to mount nand2, but also erases it.  Use a text editor (midnight commander is good) to open /etc/init.d/mount_extend and place '#' at the start of each of the lines which erases mountblock5
While we have MC up UK users should change keyboard to gb in /etc/init.d/start to save manually doing it each time.
 
    #mount the second nand flash
    if [ "$is_2g" = "1" ] ; then
    #   if test -e /flash_eraseall ; then
    #      echo "flash_eraseall mtd5..."
    #      /flash_eraseall /dev/mtd5
    #   fi
    #    rm -rf "/Extend"
    mkdir -p "/mnt/nandflash2"
    mount -t yaffs2 /dev/nand2 /mnt/nandflash2
.....................
..

Now we have a live machine and an easy choice of software images.  You will need to use Ctrl+Fn+Shft each time you power up, but I will find a way to solve that later - unless someone else wants to add a Howto to this post!
« Last Edit: October 31, 2009, 10:39:53 PM by jimux »

Mijzelf

  • Full Member
  • ***
  • Posts: 143
Re: Reviving a 'bricked' CnMnetboot
« Reply #1 on: November 02, 2009, 09:56:09 AM »
Great howto!

Two remarks:
-uImage is not a combined bootloader/kernel, it's a kernel. The bootloader is the piece of software which reacts on pressing Fn+Ctrl+Shift, and so cannot be in uImage, which is not yet loaded.
-Did you really succeed in booting Retro from a FAT32 SD_2? I'd expect it not to work, since Linux heavily relies on symlinks, which are not supported by FAT. I suggest to use ext3 instead (not ext2, which is not supported by the bare kernel). The downside is that you will need a Linux box to create the filesystem. The LLL doesn't have the needed tools, AFAIK.

jimux

  • Jr. Member
  • **
  • Posts: 96
Re: Reviving a 'bricked' CnMnetboot
« Reply #2 on: November 02, 2009, 10:23:31 AM »
Mijzelf, thank you.  I would not have gathered the information without your help.  To answer your points I originally thought as you do, and you are correct for all Linux systems I have come across before - I've been using SuSE for 12 years and DSL, Puppy, Mandrake(iva), after years of supporting applications running under AIX, HP-UX, SCO, but I suspect that the CmNbox has some odd code that may point towards the Gates Empire.

My reason for suggesting that uImage has a bootloader element is that even after dd'ing it to the mountblock the box will not boot up without the uImage copy on part one of an SD card, regardless of key combinations during power on.  However this may be because the MBR is pointing somewhere other than where it should.  I have been nervous about messing with that.

Yes it really does boot a 1.8Gb FAT32 second primary partition on a 2Gb card.  It would not recognise an ext3 partition, no matter what I used to format it.  It would not even manually mount ext3 once I had booted up.  I did not believe what was happening and took 2 days of messing about before finally trying FAT32.  I suspect that this is something to do with celinux 2.4.20.

Since there are a number of posts regarding failure to flash a recovery image I think I shall look at the possibility of putting together a bootable SD card with a script to clean and tar an image to flash.  But the one thing missing is a mechanism to wipe, format and test the nand.  The original F3 route did not format the nand (although is said it did), it simply wiped all files and did not format/test for true bad block.  This is an increasing problem as each unsuccessful attempt to flash results in more blocks being marked as bad.

Just a thought - what happens if I simply find and edit the file of bad blocks? Where?



Mijzelf

  • Full Member
  • ***
  • Posts: 143
Re: Reviving a 'bricked' CnMnetboot
« Reply #3 on: November 02, 2009, 11:05:57 AM »
Quote
Yes it really does boot a 1.8Gb FAT32 second primary partition on a 2Gb card.  It would not recognise an ext3 partition, no matter what I used to format it.  It would not even manually mount ext3 once I had booted up.  I did not believe what was happening and took 2 days of messing about before finally trying FAT32.  I suspect that this is something to do with celinux 2.4.20.
You are sure it's ext3, not ext2?
On my Laptop the system boots fine into Debian, on ext3 SD_2. So Linux is not the problem. Does /proc/filesystems mention ext3? What does dmesg say when mounting an ext3 bd fails? Maybe that particular kernel doesn't have ext3 build in?
Quote
Just a thought - what happens if I simply find and edit the file of bad blocks? Where?
From Wikipedia:
Quote
YAFFS (...) follows the smart media scheme of marking the 5th byte of the spare area for bad blocks, and ignores any blocks where the spare area byte 5 is not 0xFF.
There is no file. Each block contains it's own flag.
Quote
My reason for suggesting that uImage has a bootloader element is that even after dd'ing it to the mountblock the box will not boot up without the uImage copy on part one of an SD card, regardless of key combinations during power on.  However this may be because the MBR is pointing somewhere other than where it should.
Or your flash is actually dying, and the mtdblock containing the kernel is damaged, and/or the bootloader is damaged and cannot load the kernel from mtd1 anymore.

elamarna

  • Newbie
  • *
  • Posts: 10
Re: Reviving a 'bricked' CnMnetboot
« Reply #4 on: December 14, 2009, 07:04:15 PM »
Hi,
 i wonder if anyone can help me, not to hot on linux, but am trying to put 3mx ultra onto 2nd partition on sd card.

to tar the file can't get the  source of target directories to work-stupid i guess.
using original os and want to have option of using either.
the file is in my documents/downloads

when i give the mount command   sd2 is shown as /dev/mm0p2 on /sd/sd_2
no matter what i enter i get an error of not known,  for both source and target. what should i put in please?

tar -xjf sourcedir/Recovery_3MX-Ultra.img -C targetdir/

jimux

  • Jr. Member
  • **
  • Posts: 96
Re: Reviving a 'bricked' CnMnetboot
« Reply #5 on: December 16, 2009, 11:57:51 AM »
My original instructions above were for a machine which no longer booted up, so I used CELinux on the SD card to boot it.  This changed the device names.  If you have a working machine then you should be able to untar an image to the extended 2nd Gb of storage.   Open a telnet session and issue a df [enter] to show the mounted drives by name and their usage.  Also look at the read/write attributes of the mount command result lines.  If you want to to write to a drive that is mounted read only then you can create another mount point (empty directory) and then mount the drive a second time at that point - but read/write.

I have found that the nand storage devices are problematic, in that the yaffs file system recorded failing records but includes software failures as hardware failures, and the process is not easily reversible.  This can mean that you end up with large chunks of storage being written off.  In my case I no longer had enough space on the original nand1 for an image. 

dartdrinker

  • Newbie
  • *
  • Posts: 8
Re: Reviving a 'bricked' CnMnetboot
« Reply #6 on: September 23, 2010, 07:54:31 AM »
My Maplin MiniBook yesterday started (or rather failed) to be quite unreliable on the power button. It also tended to lock up on exiting the browser. I found that when I eventually got it booted by multiple presses of the button that removing all the add-ons from Bon Echo brought it back to health. Pity as I quite liked the forecastfox function, but the time to load the web pages is now much quicker, even with adblock removed