brun_mtd

[Xavier Pegenaute]

ollie lho wrote:

>>>In the script of src/util/mtd/burn_mtd there are these lines ..
>>>
>>>- dd conv=notrunc conv=sync bs=65536 if=${linux} of=vmlinux.bin.gz.block
>>>With this we if exist we don't trunc and fix the size of 
>>>vmlinux.bin.gz.block, if it's more smaller than 65536 we put 0 until 
>>>this size.
>>>
>>>- dd conv=notrunc conv=sync bs=63k if=${linuxbios} of=linuxbios.block
>>>The same but with 63k.
>>>
>>>- dd conv=notrunc if=docipl of=/dev/mtd0
>>>We write without trunc /dev/mtd0 with the source of docipl.
>>>
>>>- dd conv=notrunc if=docipl of=/dev/mtd0 seek=1
>>>The same but this time we skip 1 block of "bs" (i supose that we can 
>>>remind the value of bs in the last line, then sizeof(docipl) ).
>>>
>>>- dd conv=notrunc if=linuxbios.block of=/dev/mtd0 seek=2
>>>Without trunc we write linuxbios.block to mtd, skipping 2 times the last 
>>>size (sizeof(docipl) ).
>>>
>>>- dd conv=notrunc if=vmlinux.bin.gz.block of=/dev/mtd0 seek=128
>>>Now without trunc write vmlinux skipping 128 times the size of 
>>>linuxbios.block.
>>>
>>>
>>>My questions, are:
>>>
>>>Why we write two times docipl ?
>>>      
>>>
>
>First of all, you are way wrong with what seek=# means. It skips # of
>(output) blocks of the output device. It has nothing to do with
>sizeof(some image). Please man dd for detail.
>
>There are two copies for IPL one at offset 0 the other at offset 512B
>(seek=1).
>
>And why we skip 128 times the size of linuxbios.block ? (i supose that 
>i'm wrong, any one can help me with these)
>
>The size of linuxbios.block is 63kB plus the 2 copies of IPL == 64kB ==
>128 blocks.
>
Ok, then the default block size (bs) for input and output is 512 Bytes, 
thank you.

Then finally the map of eeprom is this:

0-511 (0x0 - 0x1FF) docipl 512 Bytes
512-1023 (0x200 - 0x3FF)  docipl (security copy) 512 Bytes
1024-65535 (0x400 - 0xFFFF)  linuxbios.block 64512 Bytes
65536-851967 (0x10000 - 0xCFFFF)  vmlinux.bin.gz.block 786432 Bytes

Thanks a lot.
Xavi.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20030522/e8f8992e/attachment.html>