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.

Dear Otavio Salvador,

Quoted 3 lines

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.

Quoted 7 lines

Dear Otavio Salvador,

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 2 lines

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.

Quoted 2 lines

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 at ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br

Dear Otavio Salvador,

Quoted 9 lines · Marek Vasut

Quoted 7 lines

Dear Otavio Salvador,

Quoted 3 lines

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.

Quoted 8 lines

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

Quoted 3 lines

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.

Quoted 6 lines

Quoted 2 lines

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?

Quoted 6 lines

Quoted 2 lines

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.

Quoted 43 lines

Dear Otavio Salvador,

Quoted 9 lines · Marek Vasut

Quoted 7 lines

Dear Otavio Salvador,

Quoted 3 lines

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.

Quoted 8 lines

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

Quoted 3 lines

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.

Quoted 6 lines

Quoted 2 lines

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?

Quoted 6 lines

Quoted 2 lines

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

Quoted 5 lines

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.

PATCH:

tools/mxsboot.c +2 -2

index 6c05aa4..d92c39f 100644
@@ -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;

Quoted 32 lines · Marek Vasut

PATCH:

tools/mxsboot.c +4 -4

index 6c05aa4..d92c39f 100644
@@ -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;
 

tools/mxsboot.c static int mx28_create_sd_image(int infd, int outfd) · line 581

Quoted 2 lines

tools/mxsboot.c +0 -0

        wr_size = write(outfd, buf, size);
        if (wr_size != size) {

My mx28evk does not boot with this patch applied.

Quoted 42 lines · Marek Vasut

Quoted 41 lines

PATCH:

tools/mxsboot.c +1 -1

index 6c05aa4..d92c39f 100644
@@ -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) {

tools/mxsboot.c +1 -1

@@ -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;

tools/mxsboot.c +2 -2

@@ -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;
 

Quoted 4 lines

Quoted 2 lines

        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?

Dear Otavio Salvador,

Quoted 48 lines · Fabio Estevam

Quoted 46 lines · Marek Vasut

Quoted 41 lines

PATCH:

tools/mxsboot.c +1 -1

index 6c05aa4..d92c39f 100644
@@ -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) {

tools/mxsboot.c +1 -1

@@ -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;

tools/mxsboot.c +2 -2

@@ -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;
 

Quoted 2 lines

        wr_size = write(outfd, buf, size);
        if (wr_size != size) {

My mx28evk does not boot with this patch applied.

Quoted 3 lines

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?

Quoted 57 lines

Dear Otavio Salvador,

Quoted 54 lines · Fabio Estevam

Quoted 45 lines · Marek Vasut

Quoted 44 lines

PATCH:

tools/mxsboot.c +1 -1

index 6c05aa4..d92c39f 100644
@@ -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) {

tools/mxsboot.c +1 -1

@@ -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;

tools/mxsboot.c +2 -2

@@ -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;

Quoted 4 lines

Quoted 2 lines

        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?

Quoted 2 lines

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.

Quoted 11 lines

tools/mxsboot.c +2 -2

@@ -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;
 

Quoted 2 lines

        wr_size = write(outfd, buf, size);
        if (wr_size != size) {

My mx28evk does not boot with this patch applied.

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.

On Thu, Jan 24, 2013 at 4:31 PM, Otavio Salvador

Quoted 3 lines · <[email protected]> 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...

Quoted 14 lines

Quoted 3 lines · Otavio Salvador

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.

Quoted 2 lines

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)

Quoted 15 lines

Quoted 15 lines

On Thu, Jan 24, 2013 at 4:31 PM, Otavio Salvador

Quoted 3 lines · <[email protected]> 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.

Quoted 5 lines

Quoted 2 lines

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.

Dear Otavio Salvador,

Putting Stefano on Cc, why is he omitted?

Quoted 24 lines · Marek Vasut

Quoted 15 lines

Quoted 15 lines

On Thu, Jan 24, 2013 at 4:31 PM, Otavio Salvador

Quoted 3 lines · <[email protected]> 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.

Quoted 5 lines

Quoted 2 lines

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.

Quoted 5 lines

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?)

Quoted 30 lines

Dear Otavio Salvador,

Putting Stefano on Cc, why is he omitted?

Quoted 26 lines · Marek Vasut

Quoted 15 lines

Quoted 15 lines

On Thu, Jan 24, 2013 at 4:31 PM, Otavio Salvador

Quoted 3 lines · <[email protected]> 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.

Quoted 5 lines

Quoted 2 lines

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.

Quoted 6 lines

Quoted 3 lines

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.

Quoted 2 lines

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?