[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Linux loader for OLPC

From: Robert Millan
Subject: Re: [PATCH] Linux loader for OLPC
Date: Sun, 13 Apr 2008 13:41:44 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

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

  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

Also, I'm not sure how stable this will be.  Perhaps it breaks in the future
with firmware updates :-(

> 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).

Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call… if you are unable to speak?
(as seen on /.)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]