Patchwork [V2] mtd: bcm47xxpart: detect block aligned Squashfs partition

login
register
mail settings
Submitter Rafał Miłecki
Date Sept. 13, 2013, 8:25 p.m.
Message ID <1379103930-3987-1-git-send-email-zajec5@gmail.com>
Download mbox | patch
Permalink /patch/274865/
State New
Headers show

Comments

Rafał Miłecki - Sept. 13, 2013, 8:25 p.m.
Most of the bcm47xx devices use TRX format for storing kernel and some
partition like Squashfs or JFFS2. This is pretty flexible solution, CFE
(the bootloader) just writes (and later boots) TRX at some hardcoded
place and paritions can vary in the size.

However some devices don't use TRX format. Very recently we have
discovered ZTE H218N that has kernel and rootfs partitions at some
"random" places.

This patch allows Linux find a rootfs partition after installing custom
image with a CFE bootloader.

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
 drivers/mtd/bcm47xxpart.c |    8 ++++++++
 1 file changed, 8 insertions(+)
Florian Fainelli - Sept. 13, 2013, 9:24 p.m.
Le vendredi 13 septembre 2013 22:25:30 Rafał Miłecki a écrit :
> Most of the bcm47xx devices use TRX format for storing kernel and some
> partition like Squashfs or JFFS2. This is pretty flexible solution, CFE
> (the bootloader) just writes (and later boots) TRX at some hardcoded
> place and paritions can vary in the size.
> 
> However some devices don't use TRX format. Very recently we have
> discovered ZTE H218N that has kernel and rootfs partitions at some
> "random" places.
> 
> This patch allows Linux find a rootfs partition after installing custom
> image with a CFE bootloader.
> 

This looks much better, thanks! Couple of nitpicks below.

> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
> ---
>  drivers/mtd/bcm47xxpart.c |    8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/mtd/bcm47xxpart.c b/drivers/mtd/bcm47xxpart.c
> index 9279a91..61213f9 100644
> --- a/drivers/mtd/bcm47xxpart.c
> +++ b/drivers/mtd/bcm47xxpart.c
> @@ -32,6 +32,7 @@
>  #define ML_MAGIC1			0x39685a42
>  #define ML_MAGIC2			0x26594131
>  #define TRX_MAGIC			0x30524448
> +#define SQSH_MAGIC			0x71736873	/* shsq */

You could include uapi/linux/magic.h and use the SQUASHFS_MAGIC constant 
directly, sorry for not noticing earlier.

> 
>  struct trx_header {
>  	uint32_t magic;
> @@ -167,6 +168,13 @@ static int bcm47xxpart_parse(struct mtd_info *master,
>  			offset = rounddown(offset + trx->length, blocksize);
>  			continue;
>  		}
> +
> +		/* Squashfs on devices not using TRX */
> +		if (buf[0x000 / 4] == SQSH_MAGIC) {

In theory le32_to_cpu() should be used to mimic what init/do_mounts_rd.c does 
but we do not support big-endian BCM47xx devices yet so this probably does not 
matter much.
Rafał Miłecki - Sept. 14, 2013, 7:04 a.m.
2013/9/13 Florian Fainelli <f.fainelli@gmail.com>:
> Le vendredi 13 septembre 2013 22:25:30 Rafał Miłecki a écrit :
>> diff --git a/drivers/mtd/bcm47xxpart.c b/drivers/mtd/bcm47xxpart.c
>> index 9279a91..61213f9 100644
>> --- a/drivers/mtd/bcm47xxpart.c
>> +++ b/drivers/mtd/bcm47xxpart.c
>> @@ -32,6 +32,7 @@
>>  #define ML_MAGIC1                    0x39685a42
>>  #define ML_MAGIC2                    0x26594131
>>  #define TRX_MAGIC                    0x30524448
>> +#define SQSH_MAGIC                   0x71736873      /* shsq */
>
> You could include uapi/linux/magic.h and use the SQUASHFS_MAGIC constant
> directly, sorry for not noticing earlier.

OK, I need help with that crazy endianness here... When I look at
flash dump in hexdump (or Okteta for gui) I see:
37:0000 | 73 68 73 71 BB 03 00 00 00 00 00 00 88 1B 00 40 | shsq»..........@

bcm47xx is LE, so reading first 4 bytes results in: 0x71'73'68'73 ([3]
+ [2] + [1] + [0]). That is what I used for my SQSH_MAGIC.

However SQUASHFS_MAGIC is 0x73717368. So I need to read [2] + [3] +
[0] + [1]... Any help how to achieve that?
Florian Fainelli - Sept. 16, 2013, 9:31 a.m.
Hello Rafal,

2013/9/14 Rafał Miłecki <zajec5@gmail.com>:
> 2013/9/13 Florian Fainelli <f.fainelli@gmail.com>:
>> Le vendredi 13 septembre 2013 22:25:30 Rafał Miłecki a écrit :
>>> diff --git a/drivers/mtd/bcm47xxpart.c b/drivers/mtd/bcm47xxpart.c
>>> index 9279a91..61213f9 100644
>>> --- a/drivers/mtd/bcm47xxpart.c
>>> +++ b/drivers/mtd/bcm47xxpart.c
>>> @@ -32,6 +32,7 @@
>>>  #define ML_MAGIC1                    0x39685a42
>>>  #define ML_MAGIC2                    0x26594131
>>>  #define TRX_MAGIC                    0x30524448
>>> +#define SQSH_MAGIC                   0x71736873      /* shsq */
>>
>> You could include uapi/linux/magic.h and use the SQUASHFS_MAGIC constant
>> directly, sorry for not noticing earlier.
>
> OK, I need help with that crazy endianness here... When I look at
> flash dump in hexdump (or Okteta for gui) I see:
> 37:0000 | 73 68 73 71 BB 03 00 00 00 00 00 00 88 1B 00 40 | shsq»..........@
>
> bcm47xx is LE, so reading first 4 bytes results in: 0x71'73'68'73 ([3]
> + [2] + [1] + [0]). That is what I used for my SQSH_MAGIC.
>
> However SQUASHFS_MAGIC is 0x73717368. So I need to read [2] + [3] +
> [0] + [1]... Any help how to achieve that?

My bad, there does not seem to be a good combination of endian
swapping which produces the magic you need.

Patch

diff --git a/drivers/mtd/bcm47xxpart.c b/drivers/mtd/bcm47xxpart.c
index 9279a91..61213f9 100644
--- a/drivers/mtd/bcm47xxpart.c
+++ b/drivers/mtd/bcm47xxpart.c
@@ -32,6 +32,7 @@ 
 #define ML_MAGIC1			0x39685a42
 #define ML_MAGIC2			0x26594131
 #define TRX_MAGIC			0x30524448
+#define SQSH_MAGIC			0x71736873	/* shsq */
 
 struct trx_header {
 	uint32_t magic;
@@ -167,6 +168,13 @@  static int bcm47xxpart_parse(struct mtd_info *master,
 			offset = rounddown(offset + trx->length, blocksize);
 			continue;
 		}
+
+		/* Squashfs on devices not using TRX */
+		if (buf[0x000 / 4] == SQSH_MAGIC) {
+			bcm47xxpart_add_part(&parts[curr_part++], "rootfs",
+					     offset, 0);
+			continue;
+		}
 	}
 
 	/* Look for NVRAM at the end of the last block. */