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 /.)
next prev parent 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.