linux-mips
[Top] [All Lists]

Re: [PATCH][MIPS][2/7] AR7: mtd partition map

To: Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH][MIPS][2/7] AR7: mtd partition map
From: Matteo Croce <technoboy85@gmail.com>
Date: Thu, 20 Sep 2007 20:34:21 +0200
Cc: linux-mips@linux-mips.org, Felix Fietkau <nbd@openwrt.org>, Eugene Konev <ejka@imfi.kspu.ru>, dwmw2@infradead.org, linux-mtd@lists.infradead.org, Andrew Morton <akpm@linux-foundation.org>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; bh=IfheUKiB9DJ1tLG/6KjMHy2oG9HLcpPqz8zIkGPhTZw=; b=mlhAYTR8+LIbX74/tXQARdBwCuOqVM7i95qsGQbXH9FAhZxsh88Al5v5BEIIbelwWqav8ZcA788Q2GDfOwLg4UuZBVgxf9BmjjjCl1PqWt+Bip5PIthOkho12Qb413m3EUo+YNDO+2iNVah052DpE28ifAc6EOcyaPQQMPGyd4g=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=G2ObAyDDddOwfp1uqy7KMo/WXuDX3ZHUkAKWwL2BGHfZfzZ017nbTptxtARr8BoUvJa6I/STfI480ZokIQA75dc9VJ4Q/wP3W7Bp/Cpt8rDdb0gm5V9wgErOZoBI+8+T+0xAVK+vOXHO9QhieEH/XdwQ5DHQKWbBN/7Qs6sQv7U=
In-reply-to: <20070920175204.GA26132@lst.de>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <200709201728.10866.technoboy85@gmail.com> <200709201755.06712.technoboy85@gmail.com> <20070920175204.GA26132@lst.de>
Sender: linux-mips-bounce@linux-mips.org
User-agent: KMail/1.9.6 (enterprise 0.20070907.709405)
Il Thursday 20 September 2007 19:52:05 hai scritto:
> > +#include <linux/squashfs_fs.h>
> 
> As Ralf mentioned this is not in mainline, so you can't include it.
> Fortunately for you including it seems to be a rather dumb idea anyway,
> see below for further comments.

You're right, i'll move the magic into linux/magic.h

> > +static struct mtd_partition ar7_parts[5];
> 
> Can we please get a symbolic name for that 5?  Then again we only
> seems to use 3 anyway, and create_mtd_partitions returns 4..

we use 4, and bootloader  is right, it returns 4
The fourth partition is empty, the kernel formats it as jffs2
when mounting

> > +   unsigned int root_offset = 0xe0000;
> 
> Please provide a symbolic name for this one.

Ok

> > +   printk(KERN_INFO "Parsing AR7 partition map...\n");
> 
> Do we really need this printk?

No?

> > +           if (header.checksum == 0xfeedfa42)
> > +                   break;
> > +           if (header.checksum == 0xfeed1281)
> > +                   break;
> 
> These two want symbolic names, please:
> 
> enum {
>       /* some comment */
>       FOO_PART_MAGIC = 0xfeedfa42,    
> 
>       /* more comment */
>       BAR_PART_MAGIC = 0xfeed1281,
> };
> 
> > +   switch (header.checksum) {
> > +   case 0xfeedfa42:
> > +           while (header.length) {
> > +                   offset += sizeof(header) + header.length;
> > +                   master->read(master, offset, sizeof(header),
> > +                                &len, (u_char *)&header);
> > +           }
> > +           root_offset = offset + sizeof(header) + 4;
> > +           break;
> > +   case 0xfeed1281:
> 
> Especially as you use them here again.

Right, will do


> > +   default:
> > +           printk(KERN_WARNING "Unknown magic: %08x\n", header.checksum);
> > +           break;
> > +   }
> > +
> > +   master->read(master, root_offset,
> > +           sizeof(header), &len, (u_char *)&header);
> > +   if (header.checksum != SQUASHFS_MAGIC) {
> > +           root_offset += master->erasesize - 1;
> > +           root_offset &= ~(master->erasesize - 1);
> > +   }
> 
> And after this I'm pretty sure either of the two hex constants above
> is SQUASHFS_MAGIC.  But not actually the magic in the squashfs
> superblock, but someone decided to reuse it for the partitions magic.
> So one of the comments for *_PART_MAGIC becomes:
> 
>       /* same as SQUASHFS_MAGIC for some odd reason.. */

No. There are MIPS instructions. We look for the loader
start offset since it is in the first partition

<Prev in Thread] Current Thread [Next in Thread>