arm: socfpga: update default u-boot environment

From: Dalon Westergreen <[email protected]>

These patches update the boot and os partition numbers in the default uboot environment for a number of socfpga boards. Per request, common environment configurations have been moved to a shared header.

Changed in v7:
Changed the bootloader partition to 3 to match the default layout for socfpga. commit 61520ac4d5545cc8d2e1792092e46ab8043d5f36 changed this to 1 which broke a number of socfpga kits.

The default sdcard layour places
partition 3 at the start of the fpga at +1MB. The partition is of type 0xA2. This is followed by partition 1 (FAT), and partition 2 (RootFS). Partition 1 should be the FAT partition or windows appears not to recognize the sdcard.

Changed in v6:
Changed CONFIG_SYS_MMCSD_FS_BOOT_PARTITION to be 1 for SPL_FAT and 2 for SPL_EXT support. I believe this is the original intent for whomever changed CONFIG_SYS_MMCSD_FS_BOOT_PARTITION to be 2. This allows us to keep the original sdcard layout and support FAT and EXT loading of the u-boot image
Changes in v5:
- Fixed sockit linux devicetree name
- Changed default socfpga.dtb to match board name
- sr1500 -> socfpga_cyclone5_sr1500.dtb
- de1 -> socfpga_cyclone5_de1_soc.dtb
Changes in v4:
- Removed extraneous define in socfpga_common.h
and only use CONFIG_EXTRA_ENV_SETTINGS for
common uboot environment
Changes in v3:
- Corrected error in common default environment

Dalon Westergreen (7):
arm: socfpga: add env settings to common header
arm: socfpga: update de0 nano default environment
arm: socfpga: update cyclone5 socdk default environment
arm: socfpga: update arria5 socdk default environment
arm: socfpga: Update DE1 environment
arm: socfpga: Update SoCKit environment
arm: socfpga: Update sr1500 environment

 configs/socfpga_arria5_defconfig         |  1 +
 configs/socfpga_cyclone5_defconfig       |  1 +
 configs/socfpga_de0_nano_soc_defconfig   |  3 +--
 configs/socfpga_de1_soc_defconfig        |  1 +
 configs/socfpga_sockit_defconfig         |  1 +
 configs/socfpga_sr1500_defconfig         |  1 +
 include/configs/socfpga_arria5_socdk.h   | 25 -----------------------
 include/configs/socfpga_common.h         | 35 ++++++++++++++++++++++++++++++--
 include/configs/socfpga_cyclone5_socdk.h | 25 -----------------------
 include/configs/socfpga_de0_nano_soc.h   | 19 +----------------
 include/configs/socfpga_de1_soc.h        | 19 +----------------
 include/configs/socfpga_sockit.h         | 27 +-----------------------
 include/configs/socfpga_sr1500.h         | 25 -----------------------
 13 files changed, 42 insertions(+), 141 deletions(-)

Quoted 12 lines · Dalon Westergreen

From: Dalon Westergreen <[email protected]>

These patches update the boot and os partition numbers in the???????????????????
default uboot environment for a number of socfpga boards.??Per??????????????????
request, common environment configurations have been moved to a?????????????????
shared header.??????????????????????????????????????????????????????????????????

Quoted 5 lines

Changed in v7:
? Changed the bootloader partition to 3 to match the default layout for ? socfpga.??commit 61520ac4d5545cc8d2e1792092e46ab8043d5f36 changed this to 1
? which broke a number of socfpga kits.

And this commit will break another bulk of kits, great ...

Quoted 9 lines

The default sdcard layour places?
? partition 3 at the start of the fpga at +1MB.??The partition is of type 0xA2.
? This is followed by partition 1 (FAT), and partition 2 (RootFS).??Partition 1
? should be the FAT partition or windows appears not to recognize the sdcard.

Isn't this fixing problems at the wrong place ? Maybe Microsoft should fix their OS instead ...

Quoted 47 lines

Changed in v6:
? Changed CONFIG_SYS_MMCSD_FS_BOOT_PARTITION to be 1 for SPL_FAT and 2 ? for SPL_EXT support.??I believe this is the original intent for whomever ? changed CONFIG_SYS_MMCSD_FS_BOOT_PARTITION to be 2.??This allows us to keep
? the original sdcard layout and support FAT and EXT loading of the u-boot ? image?
Changes in v5:
?- Fixed sockit linux devicetree name?
?- Changed default socfpga.dtb to match board name
????????- sr1500 -> socfpga_cyclone5_sr1500.dtb
????????- de1 -> socfpga_cyclone5_de1_soc.dtb??????????????????????????????????? Changes in v4:
?- Removed extraneous define in socfpga_common.h
???and only use CONFIG_EXTRA_ENV_SETTINGS for
???common uboot environment
Changes in v3:
?- Corrected error in common default environment

Dalon Westergreen (7):
? arm: socfpga: add env settings to common header ? arm: socfpga: update de0 nano default environment ? arm: socfpga: update cyclone5 socdk default environment ? arm: socfpga: update arria5 socdk default environment ? arm: socfpga: Update DE1 environment
? arm: socfpga: Update SoCKit environment
? arm: socfpga: Update sr1500 environment

?configs/socfpga_arria5_defconfig?????????|??1 +
?configs/socfpga_cyclone5_defconfig???????|??1 +
?configs/socfpga_de0_nano_soc_defconfig???|??3 +--
?configs/socfpga_de1_soc_defconfig????????|??1 +
?configs/socfpga_sockit_defconfig?????????|??1 +
?configs/socfpga_sr1500_defconfig?????????|??1 +
?include/configs/socfpga_arria5_socdk.h???| 25 -----------------------
?include/configs/socfpga_common.h?????????| 35
++++++++++++++++++++++++++++++--
?include/configs/socfpga_cyclone5_socdk.h | 25 -----------------------
?include/configs/socfpga_de0_nano_soc.h???| 19 +----------------
?include/configs/socfpga_de1_soc.h????????| 19 +----------------
?include/configs/socfpga_sockit.h?????????| 27 +-----------------------
?include/configs/socfpga_sr1500.h?????????| 25 -----------------------

?13 files changed, 42 insertions(+), 141 deletions(-)

Quoted 19 lines · Marek Vasut

Quoted 17 lines · Dalon Westergreen

From: Dalon Westergreen <[email protected]>

These patches update the boot and os partition numbers in the
default uboot environment for a number of socfpga boards. Per
request, common environment configurations have been moved to a
shared
header.

Changed in v7:
Changed the bootloader partition to 3 to match the default layout for socfpga. commit 61520ac4d5545cc8d2e1792092e46ab8043d5f36 changed this to
1
which broke a number of socfpga kits.

Quoted 1 line

And this commit will break another bulk of kits, great ...

I think the only kit that MAY be affected is the DE1 kit and I actually dont even think that is true b/c they are probably using the method described in the former thread where they just write the u-boot-with-spl.sfp to +64KB. CONFIG_SPL_ABORT_ON_RAW_IMAGE is defined for the board.

If i had a board I would test it. But that said, this is currently how all of the altera kits, and the de0 kit work.

Quoted 25 lines · Dalon Westergreen

Quoted 23 lines · Marek Vasut

Quoted 20 lines · Dalon Westergreen

From: Dalon Westergreen <[email protected]>

These patches update the boot and os partition numbers in the???????????????????
default uboot environment for a number of socfpga boards.??Per??????????????????
request, common environment configurations have been moved to a?????????????????
shared header.????????????????????????????????????????????????????????????????? ?

Changed in v7:
? Changed the bootloader partition to 3 to match the default layout for ? socfpga.??commit 61520ac4d5545cc8d2e1792092e46ab8043d5f36 changed this to
1
? which broke a number of socfpga kits.

Quoted 6 lines

Quoted 1 line

And this commit will break another bulk of kits, great ...

I think the only kit that MAY be affected is the DE1 kit and I actually dont even think that is true b/c they are probably using the method described in the former thread where they just? write the u-boot-with-spl.sfp to +64KB.?? CONFIG_SPL_ABORT_ON_RAW_IMAGE is defined for the board.

And all the kits which used the environment in mainline U-Boot.

Quoted 3 lines

If i had a board I would test it.??But that said, this is currently? how all of the altera kits, and the de0 kit work.

I'd be happy to take the previous patchset without this new "windows compatibility"/"ancient u-boot compatibility" crap and then proceed with a discussion on this new topic.

But now that it came up, well, I guess I'll wait for Dinh to make the decision, since we clearly have totally different opinions.

Quoted 43 lines · Marek Vasut

Quoted 25 lines · Dalon Westergreen

Quoted 23 lines · Marek Vasut

Quoted 20 lines · Dalon Westergreen

From: Dalon Westergreen <[email protected]>

These patches update the boot and os partition numbers in the
default uboot environment for a number of socfpga boards. Per
request, common environment configurations have been moved to a
shared
header.

Changed in v7:
Changed the bootloader partition to 3 to match the default layout for socfpga. commit 61520ac4d5545cc8d2e1792092e46ab8043d5f36 changed this
to
1
which broke a number of socfpga kits.

Quoted 6 lines

Quoted 1 line

And this commit will break another bulk of kits, great ...

I think the only kit that MAY be affected is the DE1 kit and I actually dont even think that is true b/c they are probably using the method described in the former thread where they just write the u-boot-with-spl.sfp to +64KB. CONFIG_SPL_ABORT_ON_RAW_IMAGE is defined for the board.

And all the kits which used the environment in mainline U-Boot.

Quoted 3 lines

If i had a board I would test it. But that said, this is currently how all of the altera kits, and the de0 kit work.

I'd be happy to take the previous patchset without this new "windows compatibility"/"ancient u-boot compatibility" crap and then proceed with a discussion on this new topic.

Quoted 3 lines

But now that it came up, well, I guess I'll wait for Dinh to make the decision, since we clearly have totally different opinions.

Thanks. I am open to any suggestions, i could just wrap the boot partition number in socfpga_common with an ifndef? and define it as partition 3 in the altera boards which currently use that setup?

another option would be to re-implement the method used in the older 2013.01.01 uboot used by socfpga which, rather than using a partition number specifically looked for a partition of type 0xa2 making the partition number irrelevant?

Quoted 53 lines · Dalon Westergreen

Quoted 51 lines · Marek Vasut

Quoted 31 lines · Dalon Westergreen

Quoted 28 lines · Marek Vasut

Quoted 24 lines · Dalon Westergreen

From: Dalon Westergreen <[email protected]>

These patches update the boot and os partition numbers in the???????????????????
default uboot environment for a number of socfpga boards.??Per??????????????????
request, common environment configurations have been moved to a?????????????????
shared header.????????????????????????????????????????????????????????????? ????
?

Changed in v7:
? Changed the bootloader partition to 3 to match the default layout for
? socfpga.??commit 61520ac4d5545cc8d2e1792092e46ab8043d5f36 changed this
to
1
? which broke a number of socfpga kits.

Quoted 6 lines

Quoted 1 line

And this commit will break another bulk of kits, great ...

I think the only kit that MAY be affected is the DE1 kit and I actually dont even think that is true b/c they are probably using the method described in the former thread where they just? write the u-boot-with-spl.sfp to +64KB.?? CONFIG_SPL_ABORT_ON_RAW_IMAGE is defined for the board.

And all the kits which used the environment in mainline U-Boot.

Quoted 4 lines

If i had a board I would test it.??But that said, this is currently? how all of the altera kits, and the de0 kit work.

I'd be happy to take the previous patchset without this new "windows compatibility"/"ancient u-boot compatibility" crap and then proceed with a discussion on this new topic.

Quoted 6 lines

Quoted 3 lines

But now that it came up, well, I guess I'll wait for Dinh to make the decision, since we clearly have totally different opinions.

Thanks.??I am open to any suggestions, i could just wrap the? boot partition number in socfpga_common with an ifndef? and define? it as partition 3 in the altera boards which currently use that setup?

Uh no, let's not add more ifdefs.

Quoted 1 line

Quoted 4 lines

another option would be to re-implement the method used in the older 2013.01.01 uboot used by socfpga which, rather than using a partition number specifically looked for a partition of type 0xa2 making the partition number irrelevant?

Either that or load u-boot.img from FS (even better). Do you have an example patch for the first approach ? How intrusive is it ?

Quoted 69 lines · Marek Vasut

Quoted 53 lines · Dalon Westergreen

Quoted 51 lines · Marek Vasut

Quoted 31 lines · Dalon Westergreen

Quoted 28 lines · Marek Vasut

Quoted 24 lines · Dalon Westergreen

From: Dalon Westergreen <[email protected]>

These patches update the boot and os partition numbers in the
default uboot environment for a number of socfpga boards. Per
request, common environment configurations have been moved to a
shared
header.

Changed in v7:
Changed the bootloader partition to 3 to match the default layout
for
socfpga. commit 61520ac4d5545cc8d2e1792092e46ab8043d5f36 changed
this
to
1
which broke a number of socfpga kits.

Quoted 6 lines

Quoted 1 line

And this commit will break another bulk of kits, great ...

I think the only kit that MAY be affected is the DE1 kit and I actually dont even think that is true b/c they are probably using the method described in the former thread where they just write the u-boot-with-spl.sfp to +64KB. CONFIG_SPL_ABORT_ON_RAW_IMAGE is defined for the board.

And all the kits which used the environment in mainline U-Boot.

Quoted 4 lines

If i had a board I would test it. But that said, this is currently how all of the altera kits, and the de0 kit work.

I'd be happy to take the previous patchset without this new "windows compatibility"/"ancient u-boot compatibility" crap and then proceed with a discussion on this new topic.

Quoted 6 lines

Quoted 3 lines

But now that it came up, well, I guess I'll wait for Dinh to make the decision, since we clearly have totally different opinions.

Thanks. I am open to any suggestions, i could just wrap the boot partition number in socfpga_common with an ifndef? and define it as partition 3 in the altera boards which currently use that setup?

Uh no, let's not add more ifdefs.

Quoted 5 lines

another option would be to re-implement the method used in the older 2013.01.01 uboot used by socfpga which, rather than using a partition number specifically looked for a partition of type 0xa2 making the partition number irrelevant?

Quoted 2 lines

Either that or load u-boot.img from FS (even better). Do you have an example patch for the first approach ? How intrusive is it ?

I am working on it as we speak. I like that approach, i am thinking searching for the a2 partition is a failover in spl_mmc_load_image after mmc_load_image_raw_sector. i can test it, and send a patch for you to decide if it is too invasive?