On Sun, Apr 13, 2008 at 7:41 PM, Robert Millan <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 03, 2008 at 11:19:32PM +0800, Bean wrote:
> > Hi,
> >
> > The new patch add support for the nand flash device in OLPC. However,
> > the flash use jffs2 file system, so you can't list file in it yet, but
> > you can dump the disk with hexdump.
> >
> > This patch also include an improvement for hexdump that would allow it
> > to dump device as well as file, for example:
> >
> > hexdump (nand)
>
> I'm surprised that the nand works via ieee1275 calls. See my comment in
> cmain.c:
>
> if (is_olpc)
> {
> /* OLPC / XO laptops have three kinds of storage devices:
>
> - NAND flash. These are accessible via OFW callbacks, but:
> - Follow strange semantics, imposed by hardware constraints.
> - Its ABI is undocumented, and not stable.
> They lack "device_type" property, which conveniently makes GRUB
> skip them.
>
> - USB drives. Not accessible, because OFW shuts down the controller
> in order to prevent collisions with applications accessing it
> directly. Even worse, attempts to access it will NOT return
> control to the caller, so we have to avoid probing them.
>
> - SD cards. These work fine.
>
> To avoid brekage, we only need to skip USB probing. However,
> since detecting SD cards is more reliable, we do that instead.
> */
>
> grub_ieee1275_set_flag (GRUB_IEEE1275_FLAG_OFDISK_SDCARD_ONLY);
> }
>
> but your patch doesn't seem to disable the
> GRUB_IEEE1275_FLAG_OFDISK_SDCARD_ONLY
> hack.
>
> Also, I'm not sure how stable this will be. Perhaps it breaks in the future
> with firmware updates :-(
nand access is different from normal disk, it uses pio-read to read a
page which is normally 2048 bytes.
: pio-read ( adr len page# offset -- )
nand device doesn't have device_type property, it won't be detected by
ofdisk.c, so i put it in a separate module nand.c.
as for GRUB_IEEE1275_FLAG_OFDISK_SDCARD_ONLY, perhaps we can rename it
GRUB_IEEE1275_FLAG_OLPC to indicate OLPC platform, we might need to
use it for other things.
>
>
> > I also add a new function grub_getcrc32 in kern/misc.c, this function
> > is useful in many places, for example, jffs2 use it to verify data. A
> > new command crc is also included that would allow user to calculate
> > the crc checksum of file.
>
> That sounds very useful. But I'm not sure if it's a good idea to put it in
> kernel. Perhaps a "crypt" module would be better? (so that we can add more
> crypto-related functions when we support LUKS, etc).
That's a good idea.
--
Bean
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
