Topic: Unbrick chumby

Hello
I overwrite the loader partition with a custom loader, but the chumby was converted in a brick sad
But with this i can say that is possible overwrite the loader from linux user-space, writing to /dev/mtblock0


But, i'm working in the de-brick process.

I follow the CPU schematic tips:

pull BOOTLBLK and BOOTPLUS low for recovery mode

Now the chumby start in bootstrap mode smile

With the freescale tool: i.MX21_HAB_toolkit.exe.
I load and run successfully  to RAM a simple serial echo  smile

Now, i want to load a new bootloader, i'm reading the chumby bootloader code, and i try to load it on RAM


Best Regards

Re: Unbrick chumby

I can run the test loader program tst.bin, i see on serial terminal:

Unrecognized command.
Chumby > Unrecognized command.
Chumby > Unrecognized command.
Chumby > Unrecognized command.
Chumby > Unrecognized command.
Chumby > Unrecognized command.
Chumby > Chumby self-test routine:
  h            this message
Chumby >


smile

Re: Unbrick chumby

Searching on google i find this page:
http://www.pudn.com/downloads74/sourcec … 7117.html#
This page have many files that are part of your bootloader. But i can't download it, do you have the original file?
Can you share it with me? if no, how can i restore the bootloadeer in nand flash? there is a easy way? or i need write my own code?

Best regards

Re: Unbrick chumby

I never got the binary output of our makescripts to work with the MX21 HAB toolkit. As far as I can tell it's broken, and does not work reliably.

If you need to use the serial port to upload code, refer to the user manual, chapter 13, where it documents the uploader protocol for the serial port. You have to use this to write a binary image, and then jump to it to run that.

note that the binary image you upload isn't just what you want on the NAND flash, because the binary image is written to RAM. In other words, what you want to write into the chumby is the code that can then read the bootloader image and burn that into the FLASH. It's very complicated, and very slow, unfortunately, to do that. It may be easier to desolder your ROM chip and burn it in a ROM burner. That is how we did development in the early days for chumby--in fact, the board still contains the alignment holes so you can solder on a ROM chip socket to help with bootloader development.

7BAA 2E53 01C1 DCFF 497B  E7F0 9699 A303 78F0 D9B9

Re: Unbrick chumby

Ah, I see, I have read one of your previous posts and this post and now I understand that you have uploaded the tst.bin file which is in fact, a program that does nothing but return unrecognized command. It's just a test framework.

The fact that you got tst.bin to work may be a bit of a lark; small programs run well on the chumby from the MX21 HAB toolkit but there is more work required to initialize the SDRAM correctly. The default timings won't work for a long list of reasons.

However, if you did manage to reconfigure the MX21 HAB toolkit to work with a chumby memory configuration--which is certainly possible, but not something I have ever done--you can then use it to upload a zImage and run that. The zImage should then be able to mount the existing root filesystems on the FLASH rom (presuming that you didn't bash those) and you should be able to use the nand flashing routines to properly re-image the bootloader partition.

I also have my own home-grown version of a very simplified, custom-tailored serial protocol driver that talks to the chumby. It's not exactly what you're looking for but I can post a link to the source if you think that's a path you want to take. It does the job of setting up DRAM timings and loading a zImage, although not in the most user-friendly fashion.

7BAA 2E53 01C1 DCFF 497B  E7F0 9699 A303 78F0 D9B9

Re: Unbrick chumby

Hi, thanks for your answers smile

I know that the linker script for run on RAM or ROM (FLASH)  must be different.
I just compile and load tst.bin for testing the MX21 HAB toolkit, i change some definitions on uart.c and the processor initialization and i can compile a right tst.bin file (with the bootloader source files doesn't run properly)

If you want you can give me the link for your home-grown application for setting DRAM and loading zImage, and i try to write an application for write the NAND flash.

I build an acedemic Linux development board: http://wiki.emqbit.com/free-ecb-at91 on this board you can download the kernel image via serial port to SDRAM and then program this binary on FLASH, i can use this application and your application as base.


Best regards

Re: Unbrick chumby

Here's a link to the code. It's ugly, but it works (at least for some configurations of serial port hardware).

http://files.chumby.com/hostboot/hostBoot.c
http://files.chumby.com/hostboot/setupKernel.c

You may want to #ifdef out the part where the intitrd is uploaded, because you won't need an initrd for debricking a pre-flashed chumby (it takes forever to upload a filesystem, so probably better to use the already existing filesystem, assuming you haven't nuked it). You'll need to change the kernel command line args correspondingly.

If you do end up making a self-contained "debricking" script from these I'd appreciate it if you could please post a link to it so others can use it.

thanks!

7BAA 2E53 01C1 DCFF 497B  E7F0 9699 A303 78F0 D9B9

Re: Unbrick chumby

Thanks for the files smile
reading the hostBoost.c file, you implement the serial protocol (bootstrap mode) to change internal registers in the imX21.. Right? Do you set the SDRAM registers using HAB tools? If yes, Can i download to MX21 RAM an application with this settings?

I don't need the flashed filesystem, if i can download the kernel image i can boot from an USB memory.

I want to try some bootloaders like umon, blob or u-boot.

I have another question:
The Nand functions in the bootloader source code works?

Best regards and thanks again

Re: Unbrick chumby

hostBoot.c does manipulate the internal registers so you can download direct to RAM using this. You should not have to use the HAB tools.

I have only tested the NAND read functinons in the source code personally. I would be inclined to believe that the writing functions also probably work as well, but you should sanity test them first before relying on them.

If you do get one of the more sophisticated bootloaders to work on the chumby, do let me know. It would be nice to upgrade the production chumby to use something better, as long as we can still integrate the LCD/touchscreen functionality so you have instant-on access to a bootscreen and touchscreen feedback--waiting until the kernel loads to interact with the user is too long to wait.

7BAA 2E53 01C1 DCFF 497B  E7F0 9699 A303 78F0 D9B9

Re: Unbrick chumby

Of course if i can run a more sophisticated bootloader i'll share the files with you smile
Today i can run Micromonitor http://www.microcross.com/html/micromonitor.html on chumby, but without flash support, i'm working on it !!

Best regards

Re: Unbrick chumby

Hi
I'm working with a umon developer to add nand flash support, at present i can download to RAM an umon binary, this application drive the processor's UART1, i can download via xmodem any file to internal RAM.

Do you know the NAND flash reference? and where  can i download the datasheet?

Best Regards

Re: Unbrick chumby

Hi bunnie
I try to use this files:
http://files.chumby.com/hostboot/hostBoot.c
http://files.chumby.com/hostboot/setupKernel.c

but i have a problem:
I attach the execution log:


[cain@Aldebaran bunnie]$ ./hostBoot ../../kernel/zImage
sending a sync command.
sending init commands.
MPLL command.
CSCR command.
FMCR command.
precharge.
autorefresh.
set mode register.
set dram timing register.
Setting up kernel tags in memory.
Command line: console=ttyS0,115200 root=/dev/mtdblock3 rootfstype=cramfs
uploading kernel file of size 1436776 bytes to memory.
................................................................................................................................................................................
sending a sync command.
ArchID=0x00000353
output_data: 0xc0008000
Uncompressing Linux.............................................................................................. done, booting the kernel.
�x��x�xxxx���xxx�x�x��x�x�x�����x����xx����xx�x�xx�x�xx��x�xxx�x�xxxxx�xx�x�x�x��xxx
���xx�x����xxx�xx�x�xx�xxxxxx�x�xxx�xxx�x��x�xxx����x�xxxxx�xxx�xxx�x�xx���x�xx�x��x�x�
�x�x�x���x���������x�x�xxx��x��x�xxx�xx�x��������xxx�x�xxx�xxxxx�����x��xxx�xxx��
�x������������x�x�xx�����x�x�x�x�x�x�x�xxxx���x�xx��x�x�xxxxx�xx��xx�x�x��xxx�xxx�
x�x�x�x�x��xxx�x���x��x�����xxx�x�x�xxx�x�x�x�xxx�x�xxx�xxx��xx�x�x��xxx�xxx�x�x�x�x�x
��x

I type  CTRL-C
and open minicom, y try with different serial speed 38400 57200 115200 but i can't read the messages sad

Any idea ?

Best regards

Re: Unbrick chumby

The linux kernel is hard-wired to have the console at 38400--it ignores the command fwiw. Probably the easiest way to get around this problem is to change the hostboot code to force the serial port to 38400 right after finishing the upload? I've done that before and it does work...

7BAA 2E53 01C1 DCFF 497B  E7F0 9699 A303 78F0 D9B9

Re: Unbrick chumby

Thanks bunnie for the fast answer, but why i can't see the messages with minicom or kermit with the serial port settings to 38400 N8?
The Pll register values are correct?
This values are different to values in other files,
What is the chumby frequency? 266MHz   ?

Re: Unbrick chumby

Hi i change the serial port settings in hostboot code, but doesn't works sad
if i change in linux-2.6.16/drivers/serial/imx.c line 660 to:
#if 1    // ...hack...for 38400...
    MPCTL0 = 0x01ff297c;  // 352 MHz
    CSCR =  0x17180A0F;
    CSCR = 0x17380A0F;
    while (CSCR & 0x00200000)
      ; // wait for stabilization
#endif

I can see the kernel boot process smile

Re: Unbrick chumby

Hi when i change this file, the clock cpu settings change and some peripherics doesn't works. I replace this file with this one:
http://coglinux.cvs.sourceforge.net/cog … iew=markup

With this file i can set the serial speed using the  kernel  CMD_LINE

now i can boot the kernel and using the CMD_LINE:
console=ttyS0,115200n8 root=/dev/mtdblock3 rootfstype=cramfs

I have my chumby functional again smile

But is necessary re-flash the bootloader NAND flash partition, i can do that using /dev/mtdblock0, but i need the bootloader binary, i brick my chumby trying to re-flash a self-build bootloader.

Can you send me  a link with the bootloader binary please?

Best regards

Re: Unbrick chumby

http://files.chumby.com/resources/chumby_fw_1_2.zip

contains bl.bin.zip which is the bootloader image.

best of luck

7BAA 2E53 01C1 DCFF 497B  E7F0 9699 A303 78F0 D9B9

Re: Unbrick chumby

Hello
Today i finally write the bootloader to NAND chumby smile . The process is:

1. Download modified kernel image Using bunnie hostBoot,  The modifications are:

1.1 with the chumby page's kernel the serial port work at 38400 Baud only. If i replace drivers/serial/imx.c with this one: http://coglinux.cvs.sourceforge.net/cog … iew=markup  the serial port "accept" the kernel COMMAND LINE options.
1.2 Add ext3 filesystem support, downloading images to internal RAM is very slow, so i use a external storage device for the filesystem, i use a buildroot based linux filesystem and modify:

#define CMDLINE "console=ttyS0,38400 root=/dev/ram0 rootfstype=minix init=/linuxrc rw"
to:
#define CMDLINE "console=ttyS0,115200n8 root=/dev/sda2 rootfstype=ext3 rootdelay=6"

in the file: http://files.chumby.com/hostboot/setupKernel.c

At this point you can boot linux from RAM using a USB flash memory.

2. Write the bootloader binary to the NAND flash. Linux already have the MTD driver for this, but there is a problem, the first nand block (16kb) is marked from factory as a bad block, the mtd linux driver skip the bad blocks for write and erase, so is necessary change this driver for write this "bad block" the changes are:
2.1 in linux-2.6.16/drivers/mtd/nand/nand_base.c   :
        /* Check if we have a bad block, we do not erase bad blocks ! */
#if 0
        if (nand_block_checkbad(mtd, ((loff_t) page) << this->page_shift, 0, allowbbt)) {
            printk (KERN_WARNING "nand_erase: attempt to erase a bad block at page 0x%08x\n", page);
            instr->state = MTD_ERASE_FAILED;
            goto erase_exit;
        }
#endif

2.2 In mtd_orig/util/flash_eraseall.c  in main function add:
    bbtest = 0;    //CAIN   

2.3 In mtd_orig/util/nandwrite.c :

#if 0          
                /* Check all the blocks in an erase block for bad blocks */
            do {
                   if ((ret = ioctl(fd, MEMGETBADBLOCK, &offs)) < 0) {
                    perror("ioctl(MEMGETBADBLOCK)");
                    goto closeall;
                }
                if (ret == 1) {
                    baderaseblock = 1;
                       if (!quiet)
                        fprintf (stderr, "Bad block at %x, %u block(s) from %x will be skipped\n", (int) offs, blockalign, blockstart);
                    }
              
                if (baderaseblock) {          
                    mtdoffset = blockstart + meminfo.erasesize;
                }
                    offs = 0;//+=  meminfo.erasesize / blockalign ; CAIN
            } while ( offs < blockstart + meminfo.erasesize );
#endif

This ugly changes must be fixed to skip only the first block !!!

finally if you type:


flash_erase_all /dev/mtd0
..
flash_erase_all /dev/mtd7

nandwrite -p /dev/mtd0 bl.bin
nandwrite -p /dev/mtd1 psp.bin
nandwrite -p /dev/mtd2 k1.bin
nandwrite -p /dev/mtd3 rfs1.bin
nandwrite -p /dev/mtd4 k1.bin
nandwrite -p /dev/mtd5 rfs1.bin



You have a funcional chumby !!!


Best Regards


PDTA: Ed Sutter  and me are working on nand flash support for chumby with u-mon, at present we can run a U-MON RAM version download binaries to ram and we start to write nand functions..

Re: Unbrick chumby

can you tell me more about how you built the root filesystem to run off of the USB drive, and configured the kernel to look there? I could not get that to work. For example, what kernel configurations did you use to get /dev/sda2 mapped to the USB drive? Whenever I tried this the kernel would just hang searching for a USB device that it could not mount.

Interestingly, the first block is not normally marked as bad by the factory. I think what may have happened is that when you bricked your chumby you have have accidentally overwritten the bad block area with garbage. You may find that when you run a normal firmware update now, your chumby will not work again because the normal firmware "stock" to a chumby would find that first block bad and refuse to burn it.

great work!

7BAA 2E53 01C1 DCFF 497B  E7F0 9699 A303 78F0 D9B9

Re: Unbrick chumby

Hi

In my first test i can't use the USB flash memory, i change one define on /arch/arm/mach-imx/generic.c  :

#define USEHS_XTAL 1  to
#define USEHS_XTAL 0


this define control this code:

#if USEHS_XTAL
        // SPLL settings are now all done in the BOOTLOADER for this generation
        //      SPCTL0 = 0x80811446;  // configure for 26 MHz operation
        CSCR &= ~ CSCR_USB_DIV_MASK;
        CSCR |= CSCR_USB_DIV(5);  /* Divide by 6 = 288/48 */

        //      CSCR |= CSCR_SP_SEL; // select the 26 MHz clock

        /* Restart the SPLL and wait for the CSCR_SPLL_RESTART bit to clear */
        //      CSCR |= CSCR_SPLL_RESTART;
        //      while (CSCR & CSCR_SPLL_RESTART)
        //          ;
#else
        /*
         * Set the SPLL so the output frequency is 288MHz by setting
         * PD=0, MFD=626, MFI=8, and MFN=365 when fref=32.768kHz
         */
        SPCTL0 = 0x834621e8; // 288 MHz override by bunnie (makes previous line irrelevant)
        /*
         * Make sure the 48 MHz clock is 48 MHZ, assuming SPLL is set
         * to 288 MHz.
         */
        CSCR &= ~ CSCR_USB_DIV_MASK;
        CSCR |= CSCR_USB_DIV(5);  /* Divide by 6 = 288/48 */

        /* Restart the SPLL and wait for the CSCR_SPLL_RESTART bit to clear */
        CSCR |= CSCR_SPLL_RESTART;
        while (CSCR & CSCR_SPLL_RESTART)
            ;
#endif


The kernel configuration is the same, but with ext3 support and all the option related with usb mass storage buitl-in kernel. Is necesssary add rootdelay=10 when you use a usb as root device, because typically the USB devices aren't enumerated fast enough.


But i have my initial problem, i can't build a "valid" bootloader image, i download the bootloader code from ypur page, and type make goldloader.bin and write this file to the nand flash and doesn't works, which image may i write to nand?

Best regards

Re: Unbrick chumby

Ah, then perhaps the problem I had then is I was missing the rootdelay=10 option--I will give this a try again. You did not have to execute any other mount scripts or the likes? and /dev/sda2 corresponds to any of the USB ports on the back? what gets mapped to /dev/sda1?

goldloader.bin should work, however, you need to pad the image out to an even multiple of 512 bytes because you can only write full pages at a time.

As a note, you don't want to run with HS_XTAL disabled for extended periods of time. The CPU will work for some period of time and then hang due to a bug in the silicon. See http://www.bunniestudios.com/blog/?p=197 for documentation on the bug.

I think the reason you had to disable HS_XTAL is because the hostBoot program is setting up the registers to expect a 12 MHz external crystal when it's really 16 MHz; we had to change the crystal over as part of the bug and it might be that you got an old version of the code. I'll have to look into it when I get a chance--I want to try this boot from USB technique that you have. BTW, do you know if linux recognizes multiple partitions on a USB drive properly? I am thinking this through and for my application I'd need an ext3 partition and a vfat partition to make it most convenient to use.

Actually--one question, do you have a normal production chumby? Or did you get one of the early alpha evaluation units, or a "First50" unit?

7BAA 2E53 01C1 DCFF 497B  E7F0 9699 A303 78F0 D9B9

Re: Unbrick chumby

Hi Bunnie
/dev/sda2  is the second usb partition, i have two partitions the fisrt one us VFAT and the second one ext3, Linux recognizes this partitions and works fine, i use the same USB memory for updates (vfat format) and for QTOPIA files (ext3 format)

So if i build goldloader.bin and use the perl script: align.pl, chumby will boot ?

I don't know what is my chumby version, i bought from ebay smile the  PCB has a banner: Ironforge V 1.7

Best regards

Re: Unbrick chumby

okay, you have a production chumby at v1.7

I'm not sure where align.pl is. buildGoldImage.pl is the latest script that we use in our build system to create rom images, and it has facilities for correctly padding image files. It's also trivial to write a script to do it as well...

7BAA 2E53 01C1 DCFF 497B  E7F0 9699 A303 78F0 D9B9

Re: Unbrick chumby

The source for align.pl can be found in this thread.