On 01/27/2017 03:30 AM, Dalon Westergreen wrote:
On Fri, 2017-01-27 at 03:11 +0100, Marek Vasut wrote:
On 01/26/2017 11:33 PM, Dalon Westergreen wrote:
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?
Uh no, let's not add more ifdefs.
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 ?
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?
OK, thanks