Hi Albert,
On Monday, April 1, 2013 10:26:21 AM, Albert ARIBAUD wrote:
Hi Benoît,
On Mon, 1 Apr 2013 02:30:00 +0200 (CEST), Benoît Thébaudeau benoit.thebaudeau@advansee.com wrote:
Hi Albert,
On Sunday, March 31, 2013 7:30:24 PM, Albert ARIBAUD wrote:
Hi Benoît,
I have managed to rebase your patch series and have tested it over the ARM targets. This particular patch was the only one to cause an issue, and an amusing one at that:
On Wed, 6 Mar 2013 19:59:24 +0100, Benoît Thébaudeau benoit.thebaudeau@advansee.com wrote:
This also fixes support for mx31pdk and tx25, which had been broken by commit e05e5de7fae5bec79617e113916dac6631251156.
Both boards actually build fine with e05e5de7fae (and have built fine since, at least in all of the routine ARM-wide builds I do as the ARM custodian and where I accept zero build failures or warnings).
Yes, for me too. This was not a build issue, but a runtime one.
And both boards actually do not build at all with this patch :) and die with the same error:
.../spl/u-boot-spl.lds:45: non constant or forward reference address expression for section .bss
In both case I have double-checked this using Ubuntu's gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-1ubuntu1) or ELDK 5.3's gcc version 4.7.2 (GCC).
OK. That worked fine for me and Fabio at the time I issued the v9, so it can be the rebase, or something that changed in mainline in the meantime, or the toolchain. According to your tests, it's very unlikely that the toolchain is involved.
I've looked at the Git history, and the guilty commit is 3ebd1cb. But thanks to commit 65cdd64, this build issue should be easily solved by replacing: +#define CONFIG_SPL_LDSCRIPT "arch/$(ARCH)/cpu/u-boot.lds" with: +#define CONFIG_SPL_LDSCRIPT "arch/$(ARCH)/cpu/u-boot-spl.lds" in both mx31pdk.h and tx25.h.
Can you please retest with this change?
Patch 18/30 amended with this change and testing done; all ARM boards build fine now.
Thanks for testing that.
This line could even be dropped from tx25.h since there is no arm926ejs SPL linker script obstructing the default assignment, contrary to arm1136 for mx31pdk, but that would be risky if such a linker script is added later.
Is it still OK for the release if I send v10 on April 8 as I said (so just with the rebase including the change above if you confirm that everything is OK like that)?
You have Scott's acked-by for the NAND parts, and Tom's reviewed-by is proof enough for me that he is ok with the few non-ARM-only patches, so the patch series in itself is fine (assuming v10 is identical to v9 as I rebased it).
I would just like some reports that boards (mx31pdk and tx25 especially, but others too, including a few non-ARM to make sure) have no issue running v10.
OK, then it's probably better if I send v10 ASAP. I may not have access to my repo before this date, and I have not kept my v9 bundle in my outbox, so can you just send me back this bundle please? I will try to send a v10 during this week.
Best regards, Benoît