On Thu, 2017-01-26 at 22:41 +0100, Marek Vasut wrote:
On 01/26/2017 10:05 PM, Dalon Westergreen wrote:
On Thu, 2017-01-26 at 21:54 +0100, Marek Vasut wrote:
On 01/26/2017 09:31 PM, Dalon Westergreen wrote:
From: Dalon Westergreen dalon.westergreen@intel.com
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.
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.
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.
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?
--dalon