All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Millan <rmh@aybabtu.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [PATCH] Linux loader for OLPC
Date: Sun, 13 Apr 2008 13:41:44 +0200	[thread overview]
Message-ID: <20080413114144.GD20737@thorin> (raw)
In-Reply-To: <ca0f59980804030819p431d78dfo9411af0646563310@mail.gmail.com>

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 :-(

> 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	other threads:[~2008-04-13 11:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-27 23:23 [PATCH] Linux loader for OLPC Bean
2008-03-31 19:47 ` Bean
2008-04-03 15:19   ` Bean
2008-04-13 11:41     ` Robert Millan [this message]
2008-04-13 15:18       ` Bean
2008-04-13 15:52         ` Robert Millan
2008-04-18 14:56           ` Bean
2008-04-18 15:01             ` Bean
2008-04-13 11:14 ` Robert Millan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080413114144.GD20737@thorin \
    --to=rmh@aybabtu.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.