[U-Boot] [PATCH] mxs: mxsboot: Add support for SD card generation for i.MX23
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(-)
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:
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
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
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
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
Dear Otavio Salvador,
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 ...
So, Fabio, can you please explain this to me? How does the SD boot work on mx23?
Does the inlined patch work on MX23 and MX28? We can use that as a temporary workaround.
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.
Make a doc/README.mx23 with quirks needed for MX23. Once the issues are ironed out, adjust the readme. No problem.
PATCH: diff --git a/tools/mxsboot.c b/tools/mxsboot.c index 6c05aa4..d92c39f 100644 --- a/tools/mxsboot.c +++ b/tools/mxsboot.c @@ -551,7 +551,7 @@ static int mx28_create_sd_image(int infd, int outfd)
fsize = lseek(infd, 0, SEEK_END); lseek(infd, 0, SEEK_SET); - size = fsize + 512; + size = fsize + 4 * 512;
buf = malloc(size); if (!buf) { @@ -559,7 +559,7 @@ static int mx28_create_sd_image(int infd, int outfd) goto err0; }
- ret = read(infd, (uint8_t *)buf + 512, fsize); + ret = read(infd, (uint8_t *)buf + 4 * 512, fsize); if (ret != fsize) { ret = -1; goto err1; @@ -574,8 +574,8 @@ static int mx28_create_sd_image(int infd, int outfd) cb->drv_info[0].chip_num = 0x0; cb->drv_info[0].drive_type = 0x0; 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; + cb->drv_info[0].first_sector_number = sd_sector + 4; + cb->drv_info[0].sector_count = (size - 4) / 512;
wr_size = write(outfd, buf, size); if (wr_size != size) {
Best regards, Marek Vasut
On Thu, Jan 24, 2013 at 4:39 PM, Marek Vasut marex@denx.de wrote:
PATCH: diff --git a/tools/mxsboot.c b/tools/mxsboot.c index 6c05aa4..d92c39f 100644 --- a/tools/mxsboot.c +++ b/tools/mxsboot.c @@ -551,7 +551,7 @@ static int mx28_create_sd_image(int infd, int outfd)
fsize = lseek(infd, 0, SEEK_END); lseek(infd, 0, SEEK_SET);
size = fsize + 512;
size = fsize + 4 * 512; buf = malloc(size); if (!buf) {@@ -559,7 +559,7 @@ static int mx28_create_sd_image(int infd, int outfd) goto err0; }
ret = read(infd, (uint8_t *)buf + 512, fsize);
ret = read(infd, (uint8_t *)buf + 4 * 512, fsize); if (ret != fsize) { ret = -1; goto err1;@@ -574,8 +574,8 @@ static int mx28_create_sd_image(int infd, int outfd) cb->drv_info[0].chip_num = 0x0; cb->drv_info[0].drive_type = 0x0; 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;
cb->drv_info[0].first_sector_number = sd_sector + 4;cb->drv_info[0].sector_count = (size - 4) / 512; wr_size = write(outfd, buf, size); if (wr_size != size) {
My mx28evk does not boot with this patch applied.
On Mon, Feb 4, 2013 at 4:12 PM, Fabio Estevam festevam@gmail.com wrote:
On Thu, Jan 24, 2013 at 4:39 PM, Marek Vasut marex@denx.de wrote:
PATCH: diff --git a/tools/mxsboot.c b/tools/mxsboot.c index 6c05aa4..d92c39f 100644 --- a/tools/mxsboot.c +++ b/tools/mxsboot.c @@ -551,7 +551,7 @@ static int mx28_create_sd_image(int infd, int outfd)
fsize = lseek(infd, 0, SEEK_END); lseek(infd, 0, SEEK_SET);
size = fsize + 512;
size = fsize + 4 * 512; buf = malloc(size); if (!buf) {@@ -559,7 +559,7 @@ static int mx28_create_sd_image(int infd, int outfd) goto err0; }
ret = read(infd, (uint8_t *)buf + 512, fsize);
ret = read(infd, (uint8_t *)buf + 4 * 512, fsize); if (ret != fsize) { ret = -1; goto err1;@@ -574,8 +574,8 @@ static int mx28_create_sd_image(int infd, int outfd) cb->drv_info[0].chip_num = 0x0; cb->drv_info[0].drive_type = 0x0; 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;
cb->drv_info[0].first_sector_number = sd_sector + 4;cb->drv_info[0].sector_count = (size - 4) / 512; wr_size = write(outfd, buf, size); if (wr_size != size) {My mx28evk does not boot with this patch applied.
As it does not work in mx28evk I'd prefer to use my previously proposed patch as it keeps clear what is done for mx23 and mx28. What people think?
-- 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
Dear Otavio Salvador,
On Mon, Feb 4, 2013 at 4:12 PM, Fabio Estevam festevam@gmail.com wrote:
On Thu, Jan 24, 2013 at 4:39 PM, Marek Vasut marex@denx.de wrote:
PATCH: diff --git a/tools/mxsboot.c b/tools/mxsboot.c index 6c05aa4..d92c39f 100644 --- a/tools/mxsboot.c +++ b/tools/mxsboot.c @@ -551,7 +551,7 @@ static int mx28_create_sd_image(int infd, int outfd)
fsize = lseek(infd, 0, SEEK_END); lseek(infd, 0, SEEK_SET);
size = fsize + 512;
size = fsize + 4 * 512; buf = malloc(size); if (!buf) {@@ -559,7 +559,7 @@ static int mx28_create_sd_image(int infd, int outfd)
goto err0; }
ret = read(infd, (uint8_t *)buf + 512, fsize);
ret = read(infd, (uint8_t *)buf + 4 * 512, fsize); if (ret != fsize) { ret = -1; goto err1;@@ -574,8 +574,8 @@ static int mx28_create_sd_image(int infd, int outfd)
cb->drv_info[0].chip_num = 0x0; cb->drv_info[0].drive_type = 0x0; 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;
cb->drv_info[0].first_sector_number = sd_sector + 4;cb->drv_info[0].sector_count = (size - 4) / 512; wr_size = write(outfd, buf, size); if (wr_size != size) {My mx28evk does not boot with this patch applied.
As it does not work in mx28evk I'd prefer to use my previously proposed patch as it keeps clear what is done for mx23 and mx28. What people think?
NAK. Your patch is just adding churn, which the bootrom ignores. Did you manage to get reply from FSL why the bootrom ignores it already?
Best regards, Marek Vasut
On Mon, Feb 4, 2013 at 4:46 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
On Mon, Feb 4, 2013 at 4:12 PM, Fabio Estevam festevam@gmail.com wrote:
On Thu, Jan 24, 2013 at 4:39 PM, Marek Vasut marex@denx.de wrote:
PATCH: diff --git a/tools/mxsboot.c b/tools/mxsboot.c index 6c05aa4..d92c39f 100644 --- a/tools/mxsboot.c +++ b/tools/mxsboot.c @@ -551,7 +551,7 @@ static int mx28_create_sd_image(int infd, int outfd)
fsize = lseek(infd, 0, SEEK_END); lseek(infd, 0, SEEK_SET);
size = fsize + 512;
size = fsize + 4 * 512; buf = malloc(size); if (!buf) {@@ -559,7 +559,7 @@ static int mx28_create_sd_image(int infd, int outfd)
goto err0; }
ret = read(infd, (uint8_t *)buf + 512, fsize);
ret = read(infd, (uint8_t *)buf + 4 * 512, fsize); if (ret != fsize) { ret = -1; goto err1;@@ -574,8 +574,8 @@ static int mx28_create_sd_image(int infd, int outfd)
cb->drv_info[0].chip_num = 0x0; cb->drv_info[0].drive_type = 0x0; 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;
cb->drv_info[0].first_sector_number = sd_sector + 4;cb->drv_info[0].sector_count = (size - 4) / 512; wr_size = write(outfd, buf, size); if (wr_size != size) {My mx28evk does not boot with this patch applied.
As it does not work in mx28evk I'd prefer to use my previously proposed patch as it keeps clear what is done for mx23 and mx28. What people think?
NAK. Your patch is just adding churn, which the bootrom ignores. Did you manage to get reply from FSL why the bootrom ignores it already?
Well; your patch does the same but reuses the churn from mx28. Nobody replied.
-- 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
Dear Otavio Salvador,
On Mon, Feb 4, 2013 at 4:46 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
On Mon, Feb 4, 2013 at 4:12 PM, Fabio Estevam festevam@gmail.com wrote:
On Thu, Jan 24, 2013 at 4:39 PM, Marek Vasut marex@denx.de wrote:
PATCH: diff --git a/tools/mxsboot.c b/tools/mxsboot.c index 6c05aa4..d92c39f 100644 --- a/tools/mxsboot.c +++ b/tools/mxsboot.c @@ -551,7 +551,7 @@ static int mx28_create_sd_image(int infd, int outfd)
fsize = lseek(infd, 0, SEEK_END); lseek(infd, 0, SEEK_SET);
size = fsize + 512;
size = fsize + 4 * 512; buf = malloc(size); if (!buf) {@@ -559,7 +559,7 @@ static int mx28_create_sd_image(int infd, int outfd)
goto err0; }
ret = read(infd, (uint8_t *)buf + 512, fsize);
ret = read(infd, (uint8_t *)buf + 4 * 512, fsize); if (ret != fsize) { ret = -1; goto err1;@@ -574,8 +574,8 @@ static int mx28_create_sd_image(int infd, int outfd)
cb->drv_info[0].chip_num = 0x0; cb->drv_info[0].drive_type = 0x0; 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;
cb->drv_info[0].first_sector_number = sd_sector + 4;cb->drv_info[0].sector_count = (size - 4) / 512; wr_size = write(outfd, buf, size); if (wr_size != size) {My mx28evk does not boot with this patch applied.
As it does not work in mx28evk I'd prefer to use my previously proposed patch as it keeps clear what is done for mx23 and mx28. What people think?
NAK. Your patch is just adding churn, which the bootrom ignores. Did you manage to get reply from FSL why the bootrom ignores it already?
Well; your patch does the same but reuses the churn from mx28. Nobody replied.
So let's wait for the official reply from FSL. Can you tell me the support ticket number please?
Best regards, Marek Vasut
Dear Fabio Estevam,
[...]
@@ -574,8 +574,8 @@ static int mx28_create_sd_image(int infd, int outfd)
cb->drv_info[0].chip_num = 0x0; cb->drv_info[0].drive_type = 0x0; 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;
cb->drv_info[0].first_sector_number = sd_sector + 4;cb->drv_info[0].sector_count = (size - 4) / 512; wr_size = write(outfd, buf, size); if (wr_size != size) {My mx28evk does not boot with this patch applied.
Can you add this section to arch/arm/cpu/arm926ejs/mxs/u-boot-imx28.bd
-->8-- options { driveTag = 0x00; flags = 0x01; } --8<--
and paste the output you get on serial port? the flags = 1 should enable debug output from the bootrom.
Best regards, Marek Vasut
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
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
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
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
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:
- Figure out what's with MX23 -- did you place FSL supp. ticket already?
I contacted someone internal which is trying to find it out.
- 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
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:
- 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.
- 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
participants (3)
-
Fabio Estevam -
Marek Vasut -
Otavio Salvador