AW: [ECOS] cat zImage >/dev/mtd1 does not work

[Gary Thomas]

Weiguang Shi wrote:
> Thanks very much Alex. That makes things clear.
> 
> Now for the CDL (please excuse me since I'm a newbie
> to RedBoot), could you explain more? Do I need to build
> Redboot with the correct options and store it in the
> flash?

Note: you don't really need to change RedBoot.  Just update the
FIS [directory] entry for the image you are changing, either with
the corrected checksum, or the value 0.  RedBoot ignores the checksum
when the stored value is 0.

> 
> --- "Neundorf, Alexander" <Alexander.Neundorf@jenoptik.com> wrote:
> 
>>> Von: ecos-discuss-owner@ecos.sourceware.org
>>>
>>> Hi, 
>>>
>>> I'm running snapgear-3.4.0 on an IXDP425 board with RedBoot as 
>>> the bootloader and I want to
>>> be able to upgrade my kernel and filesystem, i.e., zImage and 
>>> ramdisk.gz on the flash, under Linux.
>>>
>>> So I shipped the zImage and ramdisk.gz onto the running system
>>> and did
>>>     # cat zImage >/dev/mtd1
>>>     # cat ramdisk.gz >/dev/mtd2
>>>
>>> after eraseall the two partitions. To my surprise, when I reboot,
>>> RedBoot gave 
>>>                         RedBoot> fis load ramdisk             
>>>                 
>>>                         ** Warning - checksum failure.  
>>> stored: 0x33dbe19b, computed:
>>>                         0xc9d7dfef                            
>>>                 
>>>                         RedBoot> fis load kernel              
>>>                 
>>>                         ** Warning - checksum failure.  
>>> stored: 0xfb99dd45, computed:
>>>                         0x788bb713                            
>>>                 
>>>                         RedBoot> exec -c 
>>> "console=ttyS0,115200 root=/dev/ram0 
>>>                         initrd=0x00800000,6M 
>>> mem=32M@0x00000000" 0x01600000   
>>>                         Can't execute Linux - invalid entry 
>>> address           
>>> and refused to boot.
>>>
>>> I understand here the newly flashed images (as it was not 
>>> done in RedBoot but in the OS) may
>>> not have the same checksum as RedBoot calculated for the 
>>> earlier images. And this caused the problem.
>> When Redboot stores an image, it stores:
>> -the actual data length
>> -the size of the "partition"
>> -the calculated checksum
>>
>> If the checksum doesn't match, it fails.
>> If the actual size of the kernel is bigger than what it stored in the FIS, it won't load
>> everything and it probably will not work.
>>
>> You could:
>> -disable the checksum in Redboot, I think this is possible via a cdl option
>> -when storing the kernel via Redboot, use the partition size also as data length, so it will
>> always load everything as long as it fits in the partition
> 

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss