Patchwork [U-Boot] mxs: mxsboot: Add support for SD card generation for i.MX23

login
register
mail settings
Submitter Otavio Salvador
Date Jan. 24, 2013, 5:54 p.m.
Message ID <1359050048-25415-1-git-send-email-otavio@ossystems.com.br>
Download mbox | patch
Permalink /patch/215459/
State Not Applicable
Headers show

Comments

Otavio Salvador - Jan. 24, 2013, 5:54 p.m.
The mxsboot now receives the SoC type as parameter to generate binary
compatible with the SoC. Currently the NAND support has not been add
for i.MX23 as it is not yet supported in U-Boot.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
 doc/README.mx28_common |  4 +--
 tools/mxsboot.c        | 92 ++++++++++++++++++++++++++++++++++++++++++++------
 2 files changed, 83 insertions(+), 13 deletions(-)
Marek Vasut - Jan. 24, 2013, 5:56 p.m.
Dear Otavio Salvador,

> The mxsboot now receives the SoC type as parameter to generate binary
> compatible with the SoC. Currently the NAND support has not been add
> for i.MX23 as it is not yet supported in U-Boot.

Please fix the NAND support as well, then resubmit.

The patch basically does dd if=u-boot.sb ... bs=512 seek=4 ; any kind of 
information can be stored in those first four blocks and the mx23 bootrom 
ignores it, so what's the gain of this?

I wonder, will MX28 bootrom ignore them as well? Then maybe we can get rid of 
all this SD-specific junk.

Furthermore, I'd like to see all of this reworked as another plugin for mkimage.

Best regards,
Marek Vasut
Otavio Salvador - Jan. 24, 2013, 6:03 p.m.
On Thu, Jan 24, 2013 at 3:56 PM, Marek Vasut <marex@denx.de> wrote:
> Dear Otavio Salvador,
>
>> The mxsboot now receives the SoC type as parameter to generate binary
>> compatible with the SoC. Currently the NAND support has not been add
>> for i.MX23 as it is not yet supported in U-Boot.
>
> Please fix the NAND support as well, then resubmit.

I won't work on NAND now; first I wish to fix the NAND driver support
to later work in boot support.

> The patch basically does dd if=u-boot.sb ... bs=512 seek=4 ; any kind of
> information can be stored in those first four blocks and the mx23 bootrom
> ignores it, so what's the gain of this?

Well, it works fine for users. A good gain in my opinion.

> I wonder, will MX28 bootrom ignore them as well? Then maybe we can get rid of
> all this SD-specific junk.

Did not test but MX28 expects a BCB data structure (as said in 12.11.2
- MX28RM) while MX23 does not. So I think MX28 won't work without the
BCB.

> Furthermore, I'd like to see all of this reworked as another plugin for mkimage.

Yes; it would be a good long term solution but I don't want to hold it
due any of above reasons. It works fine so improvements can be done
later.

Regards,

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
Marek Vasut - Jan. 24, 2013, 6:08 p.m.
Dear Otavio Salvador,

> On Thu, Jan 24, 2013 at 3:56 PM, Marek Vasut <marex@denx.de> wrote:
> > Dear Otavio Salvador,
> > 
> >> The mxsboot now receives the SoC type as parameter to generate binary
> >> compatible with the SoC. Currently the NAND support has not been add
> >> for i.MX23 as it is not yet supported in U-Boot.
> > 
> > Please fix the NAND support as well, then resubmit.
> 
> I won't work on NAND now; first I wish to fix the NAND driver support
> to later work in boot support.
> 
> > The patch basically does dd if=u-boot.sb ... bs=512 seek=4 ; any kind of
> > information can be stored in those first four blocks and the mx23 bootrom
> > ignores it, so what's the gain of this?
> 
> Well, it works fine for users. A good gain in my opinion.

How is a simple documented dd if=... different? It's the same on imx, you have 
to dd u-boot.imx with some offset.

> > I wonder, will MX28 bootrom ignore them as well? Then maybe we can get
> > rid of all this SD-specific junk.
> 
> Did not test but MX28 expects a BCB data structure (as said in 12.11.2
> - MX28RM) while MX23 does not. So I think MX28 won't work without the
> BCB.

Fabio?

> > Furthermore, I'd like to see all of this reworked as another plugin for
> > mkimage.
> 
> Yes; it would be a good long term solution but I don't want to hold it
> due any of above reasons. It works fine so improvements can be done
> later.

We already have a solution:

dd if=u-boot.sb of=/dev/sdX1 bs=512 seek=4

I think this is enough for now, until all is fixed in proper sequence. That is, 
NAND driver and only after that, mxsboot for NAND _and_ SD . For now, let's hold 
off this patch, add the above dd stuff into documentation (doc/README.mx23) and 
then when all is ready, fix it all properly please.

> Regards,
> 
> --
> Otavio Salvador                             O.S. Systems
> E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
> Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Best regards,
Marek Vasut
Otavio Salvador - Jan. 24, 2013, 6:31 p.m.
On Thu, Jan 24, 2013 at 4:08 PM, Marek Vasut <marex@denx.de> wrote:
> Dear Otavio Salvador,
>
>> On Thu, Jan 24, 2013 at 3:56 PM, Marek Vasut <marex@denx.de> wrote:
>> > Dear Otavio Salvador,
>> >
>> >> The mxsboot now receives the SoC type as parameter to generate binary
>> >> compatible with the SoC. Currently the NAND support has not been add
>> >> for i.MX23 as it is not yet supported in U-Boot.
>> >
>> > Please fix the NAND support as well, then resubmit.
>>
>> I won't work on NAND now; first I wish to fix the NAND driver support
>> to later work in boot support.
>>
>> > The patch basically does dd if=u-boot.sb ... bs=512 seek=4 ; any kind of
>> > information can be stored in those first four blocks and the mx23 bootrom
>> > ignores it, so what's the gain of this?
>>
>> Well, it works fine for users. A good gain in my opinion.
>
> How is a simple documented dd if=... different? It's the same on imx, you have
> to dd u-boot.imx with some offset.
>
>> > I wonder, will MX28 bootrom ignore them as well? Then maybe we can get
>> > rid of all this SD-specific junk.
>>
>> Did not test but MX28 expects a BCB data structure (as said in 12.11.2
>> - MX28RM) while MX23 does not. So I think MX28 won't work without the
>> BCB.
>
> Fabio?
>
>> > Furthermore, I'd like to see all of this reworked as another plugin for
>> > mkimage.
>>
>> Yes; it would be a good long term solution but I don't want to hold it
>> due any of above reasons. It works fine so improvements can be done
>> later.
>
> We already have a solution:
>
> dd if=u-boot.sb of=/dev/sdX1 bs=512 seek=4
>
> I think this is enough for now, until all is fixed in proper sequence. That is,
> NAND driver and only after that, mxsboot for NAND _and_ SD . For now, let's hold
> off this patch, add the above dd stuff into documentation (doc/README.mx23) and
> then when all is ready, fix it all properly please.

Well; you blocked olinuxino patch until mxsboot where ported and the
dd with offset were not a solution for you, ... so ...

I prefer to have this as is and share documentation with mx28. The
NAND ought to be done providing same interface so one doc for it all.
I think change it in next version is wrong and confuse users.

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
Otavio Salvador - Jan. 25, 2013, 12:35 p.m.
On Thu, Jan 24, 2013 at 4:31 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> I prefer to have this as is and share documentation with mx28. The
> NAND ought to be done providing same interface so one doc for it all.
> I think change it in next version is wrong and confuse users.

Ping?

We won't be able to get rid of mxsboot for NAND use-case so I'd prefer
to have it for SD as well. For me it does not matter much as I use OE
and it automates it all; but for ordinary user it is important to it
to be consistent so all 'mxs' SoC would work same way from user point
of view.

If we find a better way of doing things in future we can base on this
and improve it later but please let's get it in and move forward...

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
Marek Vasut - Jan. 25, 2013, 12:40 p.m.
Dear Otavio Salvador,

> On Thu, Jan 24, 2013 at 4:31 PM, Otavio Salvador
> 
> <otavio@ossystems.com.br> wrote:
> > I prefer to have this as is and share documentation with mx28. The
> > NAND ought to be done providing same interface so one doc for it all.
> > I think change it in next version is wrong and confuse users.
> 
> Ping?
> 
> We won't be able to get rid of mxsboot for NAND use-case so I'd prefer
> to have it for SD as well. For me it does not matter much as I use OE
> and it automates it all; but for ordinary user it is important to it
> to be consistent so all 'mxs' SoC would work same way from user point
> of view.
> 
> If we find a better way of doing things in future we can base on this
> and improve it later but please let's get it in and move forward...

Does my proposed patch not work for you? (the one which shifts the bootstream 
payload to block 4 in partition 1)

Best regards,
Marek Vasut
Otavio Salvador - Jan. 26, 2013, 3:50 p.m.
On Fri, Jan 25, 2013 at 10:40 AM, Marek Vasut <marex@denx.de> wrote:
>> On Thu, Jan 24, 2013 at 4:31 PM, Otavio Salvador
>> <otavio@ossystems.com.br> wrote:
>> > I prefer to have this as is and share documentation with mx28. The
>> > NAND ought to be done providing same interface so one doc for it all.
>> > I think change it in next version is wrong and confuse users.
>>
>> Ping?
>>
>> We won't be able to get rid of mxsboot for NAND use-case so I'd prefer
>> to have it for SD as well. For me it does not matter much as I use OE
>> and it automates it all; but for ordinary user it is important to it
>> to be consistent so all 'mxs' SoC would work same way from user point
>> of view.
>>
>> If we find a better way of doing things in future we can base on this
>> and improve it later but please let's get it in and move forward...
>
> Does my proposed patch not work for you? (the one which shifts the bootstream
> payload to block 4 in partition 1)

I gave it a try today.

And it works for mx23evk; I did not test it in mx28.

So what is the plan? I did not check the NAND format yet to know if it
is the same between mx28 and mx23 but I do want the machines merged as
soon as possible so people can play with it and find bugs.


--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
Marek Vasut - Jan. 26, 2013, 5:03 p.m.
Dear Otavio Salvador,

Putting Stefano on Cc, why is he omitted?

> On Fri, Jan 25, 2013 at 10:40 AM, Marek Vasut <marex@denx.de> wrote:
> >> On Thu, Jan 24, 2013 at 4:31 PM, Otavio Salvador
> >> 
> >> <otavio@ossystems.com.br> wrote:
> >> > I prefer to have this as is and share documentation with mx28. The
> >> > NAND ought to be done providing same interface so one doc for it all.
> >> > I think change it in next version is wrong and confuse users.
> >> 
> >> Ping?
> >> 
> >> We won't be able to get rid of mxsboot for NAND use-case so I'd prefer
> >> to have it for SD as well. For me it does not matter much as I use OE
> >> and it automates it all; but for ordinary user it is important to it
> >> to be consistent so all 'mxs' SoC would work same way from user point
> >> of view.
> >> 
> >> If we find a better way of doing things in future we can base on this
> >> and improve it later but please let's get it in and move forward...
> > 
> > Does my proposed patch not work for you? (the one which shifts the
> > bootstream payload to block 4 in partition 1)
> 
> I gave it a try today.
> 
> And it works for mx23evk; I did not test it in mx28.
> 
> So what is the plan? I did not check the NAND format yet to know if it
> is the same between mx28 and mx23 but I do want the machines merged as
> soon as possible so people can play with it and find bugs.

The plan is to:
1) Figure out what's with MX23 -- did you place FSL supp. ticket already?
2) If 1) fails, try my patch on mx28 (since mx23 ignores it anyway and we can't 
figure out why?)

Best regards,
Marek Vasut
Otavio Salvador - Jan. 26, 2013, 5:19 p.m.
On Sat, Jan 26, 2013 at 3:03 PM, Marek Vasut <marex@denx.de> wrote:
> Dear Otavio Salvador,
>
> Putting Stefano on Cc, why is he omitted?
>
>> On Fri, Jan 25, 2013 at 10:40 AM, Marek Vasut <marex@denx.de> wrote:
>> >> On Thu, Jan 24, 2013 at 4:31 PM, Otavio Salvador
>> >>
>> >> <otavio@ossystems.com.br> wrote:
>> >> > I prefer to have this as is and share documentation with mx28. The
>> >> > NAND ought to be done providing same interface so one doc for it all.
>> >> > I think change it in next version is wrong and confuse users.
>> >>
>> >> Ping?
>> >>
>> >> We won't be able to get rid of mxsboot for NAND use-case so I'd prefer
>> >> to have it for SD as well. For me it does not matter much as I use OE
>> >> and it automates it all; but for ordinary user it is important to it
>> >> to be consistent so all 'mxs' SoC would work same way from user point
>> >> of view.
>> >>
>> >> If we find a better way of doing things in future we can base on this
>> >> and improve it later but please let's get it in and move forward...
>> >
>> > Does my proposed patch not work for you? (the one which shifts the
>> > bootstream payload to block 4 in partition 1)
>>
>> I gave it a try today.
>>
>> And it works for mx23evk; I did not test it in mx28.
>>
>> So what is the plan? I did not check the NAND format yet to know if it
>> is the same between mx28 and mx23 but I do want the machines merged as
>> soon as possible so people can play with it and find bugs.
>
> The plan is to:
> 1) Figure out what's with MX23 -- did you place FSL supp. ticket already?

I contacted someone internal which is trying to find it out.

> 2) If 1) fails, try my patch on mx28 (since mx23 ignores it anyway and we can't
> figure out why?)

I'd prefer to go with 2 in meanwhile. Could you please prepare a patch for it?

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
Marek Vasut - Jan. 26, 2013, 5:46 p.m.
Dear Otavio Salvador,

> On Sat, Jan 26, 2013 at 3:03 PM, Marek Vasut <marex@denx.de> wrote:
> > Dear Otavio Salvador,
> > 
> > Putting Stefano on Cc, why is he omitted?
> > 
> >> On Fri, Jan 25, 2013 at 10:40 AM, Marek Vasut <marex@denx.de> wrote:
> >> >> On Thu, Jan 24, 2013 at 4:31 PM, Otavio Salvador
> >> >> 
> >> >> <otavio@ossystems.com.br> wrote:
> >> >> > I prefer to have this as is and share documentation with mx28. The
> >> >> > NAND ought to be done providing same interface so one doc for it
> >> >> > all. I think change it in next version is wrong and confuse users.
> >> >> 
> >> >> Ping?
> >> >> 
> >> >> We won't be able to get rid of mxsboot for NAND use-case so I'd
> >> >> prefer to have it for SD as well. For me it does not matter much as
> >> >> I use OE and it automates it all; but for ordinary user it is
> >> >> important to it to be consistent so all 'mxs' SoC would work same
> >> >> way from user point of view.
> >> >> 
> >> >> If we find a better way of doing things in future we can base on this
> >> >> and improve it later but please let's get it in and move forward...
> >> > 
> >> > Does my proposed patch not work for you? (the one which shifts the
> >> > bootstream payload to block 4 in partition 1)
> >> 
> >> I gave it a try today.
> >> 
> >> And it works for mx23evk; I did not test it in mx28.
> >> 
> >> So what is the plan? I did not check the NAND format yet to know if it
> >> is the same between mx28 and mx23 but I do want the machines merged as
> >> soon as possible so people can play with it and find bugs.
> > 
> > The plan is to:
> > 1) Figure out what's with MX23 -- did you place FSL supp. ticket already?
> 
> I contacted someone internal which is trying to find it out.

Please fill a support ticket.

> > 2) If 1) fails, try my patch on mx28 (since mx23 ignores it anyway and we
> > can't figure out why?)
> 
> I'd prefer to go with 2 in meanwhile. Could you please prepare a patch for
> it?

Fabio, can you test on mx28 please?

Best regards,
Marek Vasut

Patch

diff --git a/doc/README.mx28_common b/doc/README.mx28_common
index 8bacaf8..f0a5112 100644
--- a/doc/README.mx28_common
+++ b/doc/README.mx28_common
@@ -134,7 +134,7 @@  The partition layout is ready, next the special partition must be filled with
 proper contents. The contents is generated by running the following command
 (see chapter 2)):
 
-	$ ./tools/mxsboot sd u-boot.sb u-boot.sd
+	$ ./tools/mxsboot mx28 sd u-boot.sb u-boot.sd
 
 The resulting file, "u-boot.sd", shall then be written to the partition. In this
 case, we assume the first partition of the SD card is /dev/mmcblk0p1:
@@ -162,7 +162,7 @@  There are two possibilities when preparing an image writable to NAND flash.
 	   there is a tool called "mxsboot" in the "tools/" directory. The tool
 	   is invoked on "u-boot.sb" file from chapter 2):
 
-		 $ ./tools/mxsboot nand u-boot.sb u-boot.nand
+		 $ ./tools/mxsboot mx28 nand u-boot.sb u-boot.nand
 
 	   NOTE: The above invokation works for NAND flash with geometry of
 		 2048b per page, 64b OOB data, 128kb erase size. If your chip
diff --git a/tools/mxsboot.c b/tools/mxsboot.c
index 6c05aa4..e348877 100644
--- a/tools/mxsboot.c
+++ b/tools/mxsboot.c
@@ -1,7 +1,7 @@ 
 /*
- * Freescale i.MX28 image generator
+ * Freescale i.MX23/i.MX28 image generator
  *
- * Copyright (C) 2011 Marek Vasut <marek.vasut@gmail.com>
+ * Copyright (C) 2011, 2013 Marek Vasut <marek.vasut@gmail.com>
  * on behalf of DENX Software Engineering GmbH
  *
  * See file CREDITS for list of people who contributed to this
@@ -49,6 +49,11 @@  uint32_t nand_oobsize = 64;
 uint32_t nand_erasesize = 128 * 1024;
 
 /*
+ * SoC type
+ */
+enum { MX23, MX28 } soc_type;
+
+/*
  * Sector on which the SigmaTel boot partition (0x53) starts.
  */
 uint32_t sd_sector = 2048;
@@ -125,6 +130,13 @@  struct mx28_nand_bbt {
 	uint32_t		badblock[510];
 };
 
+struct mx23_sd_config_block {
+	uint32_t		reserved1[2];
+	uint32_t		first_sector_number;
+	uint32_t		reserved2;
+	uint32_t		sector_count;
+};
+
 struct mx28_sd_drive_info {
 	uint32_t		chip_num;
 	uint32_t		drive_type;
@@ -453,9 +465,10 @@  static int mx28_nand_write_firmware(struct mx28_nand_fcb *fcb, int infd,
 void usage(void)
 {
 	printf(
-		"Usage: mxsboot [ops] <type> <infile> <outfile>\n"
-		"Augment BootStream file with a proper header for i.MX28 boot\n"
+		"Usage: mxsboot [ops] <soc> <type> <infile> <outfile>\n"
+		"Augment BootStream file with a proper header for i.MX23/i.MX28 boot\n"
 		"\n"
+		"  <soc>	\"mx23\" or \"mx28\"\n"
 		"  <type>	type of image:\n"
 		"                 \"nand\" for NAND image\n"
 		"                 \"sd\" for SD image\n"
@@ -540,6 +553,50 @@  err0:
 	return ret;
 }
 
+static int mx23_create_sd_image(int infd, int outfd)
+{
+	int ret = -1;
+	uint32_t *buf;
+	int size;
+	off_t fsize;
+	ssize_t wr_size;
+	ssize_t offset = 512 * 4;
+	struct mx23_sd_config_block *cb;
+
+	fsize = lseek(infd, 0, SEEK_END);
+	lseek(infd, 0, SEEK_SET);
+	size = fsize + offset;
+
+	buf = malloc(size);
+	if (!buf) {
+		printf("Can not allocate output buffer of %d bytes\n", size);
+		goto err0;
+	}
+
+	ret = read(infd, (uint8_t *)buf + offset, fsize);
+	if (ret != fsize) {
+		ret = -1;
+		goto err1;
+	}
+
+	cb = (struct mx23_sd_config_block *)buf;
+
+	cb->first_sector_number = sd_sector + 1;
+	cb->sector_count = (size - 1) / 512;
+	wr_size = write(outfd, buf, size);
+	if (wr_size != size) {
+		ret = -1;
+		goto err1;
+	}
+
+	ret = 0;
+
+err1:
+	free(buf);
+err0:
+	return ret;
+}
+
 static int mx28_create_sd_image(int infd, int outfd)
 {
 	int ret = -1;
@@ -576,7 +633,6 @@  static int mx28_create_sd_image(int infd, int outfd)
 	cb->drv_info[0].tag = 0x1;
 	cb->drv_info[0].first_sector_number = sd_sector + 1;
 	cb->drv_info[0].sector_count = (size - 1) / 512;
-
 	wr_size = write(outfd, buf, size);
 	if (wr_size != size) {
 		ret = -1;
@@ -606,7 +662,7 @@  int parse_ops(int argc, char **argv)
 	};
 	int type;
 
-	if (argc < 4)
+	if (argc < 5)
 		return -1;
 
 	for (i = 1; i < argc; i++) {
@@ -618,7 +674,7 @@  int parse_ops(int argc, char **argv)
 			type = PARAM_ERASE;
 		else if (!strncmp(argv[i], "-p", 2))
 			type = PARAM_PART;
-		else	/* SD/MMC */
+		else	/* SoC type */
 			break;
 
 		tmp = strtol(argv[++i], &end, 10);
@@ -636,7 +692,14 @@  int parse_ops(int argc, char **argv)
 		if (type == PARAM_PART)
 			sd_sector = tmp;
 	}
+	if (strcmp(argv[i], "mx23") == 0)
+		soc_type = MX23;
+	else if (strcmp(argv[i], "mx28") == 0)
+		soc_type = MX28;
+	else
+		return -1;
 
+	i++;
 	if (strcmp(argv[i], "sd") && strcmp(argv[i], "nand"))
 		return -1;
 
@@ -674,10 +737,17 @@  int main(int argc, char **argv)
 		goto err2;
 	}
 
-	if (!strcmp(argv[offset], "sd"))
-		ret = mx28_create_sd_image(infd, outfd);
-	else if (!strcmp(argv[offset], "nand"))
-		ret = mx28_create_nand_image(infd, outfd);
+	if (!strcmp(argv[offset], "sd")) {
+		if (soc_type == MX23)
+			ret = mx23_create_sd_image(infd, outfd);
+		else
+			ret = mx28_create_sd_image(infd, outfd);
+	} else if (!strcmp(argv[offset], "nand")) {
+		if (soc_type == MX23)
+			printf("Not implemented yet\n");
+		else
+			ret = mx28_create_nand_image(infd, outfd);
+	}
 
 	close(outfd);
 err2: