[U-Boot] OMAP3 SPL Overflow
Using Git bisect, it appears to me that a78cd8613204188991c192b8dae2de0aae3b1722 makes "region `.sram' overflowed by 888 bytes" when I compile for omap3_logic. As I move forward through the git commits that overflow amount is continuing to grow.
Does anyone else with an OMAP3 have this issue?
adam
On Sun, Aug 21, 2016 at 06:29:42AM -0500, Adam Ford wrote:
Using Git bisect, it appears to me that a78cd8613204188991c192b8dae2de0aae3b1722 makes "region `.sram' overflowed by 888 bytes" when I compile for omap3_logic. As I move forward through the git commits that overflow amount is continuing to grow.
Does anyone else with an OMAP3 have this issue?
The best solution I have for this at current is a patch that re-works how we use the download image area and compacts the size we reserve for the scratch area to be still much larger than required.
I'll cc you off-list so you can test it, I put aside testing this when I couldn't convince my beagleboard classic to boot from SD (but the xM is fine with it).
On Sunday 21 August 2016 06:15 PM, Tom Rini wrote:
On Sun, Aug 21, 2016 at 06:29:42AM -0500, Adam Ford wrote:
Using Git bisect, it appears to me that a78cd8613204188991c192b8dae2de0aae3b1722 makes "region `.sram' overflowed by 888 bytes" when I compile for omap3_logic. As I move forward through the git commits that overflow amount is continuing to grow.
Does anyone else with an OMAP3 have this issue?
The best solution I have for this at current is a patch that re-works how we use the download image area and compacts the size we reserve for the scratch area to be still much larger than required.
I agree here. Right now the scratch addr space is 4KB. We can reduce it to 1KB. Below is the patch that is being used in ti-u-boot to solve this issue.
-----------8<------------------8<-------------------------------------
From b9fc60d79ea554aff94a208e18b089bf89b2d2ed Mon Sep 17 00:00:00 2001
From: Lokesh Vutla lokeshvutla@ti.com Date: Tue, 26 Jul 2016 11:26:06 +0530 Subject: [PATCH] ARM: OMAP3: Reduce the size of SRAM scratch addr space
OMAP3 support only SPL of size <= 60KB. In such tight scenarios it is not advisable to have scratch addr space of size 4KB. So, reduce the size to 1KB.
Signed-off-by: Lokesh Vutla lokeshvutla@ti.com --- arch/arm/include/asm/arch-omap3/omap.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-omap3/omap.h b/arch/arm/include/asm/arch-omap3/omap.h index bc0e02a..116d863 100644 --- a/arch/arm/include/asm/arch-omap3/omap.h +++ b/arch/arm/include/asm/arch-omap3/omap.h @@ -145,7 +145,7 @@ struct gpio {
#define NON_SECURE_SRAM_START 0x40208000 /* Works for GP & EMU */ #define NON_SECURE_SRAM_END 0x40210000 -#define SRAM_SCRATCH_SPACE_ADDR 0x4020E000 +#define SRAM_SCRATCH_SPACE_ADDR 0x4020EC00
#define LOW_LEVEL_SRAM_STACK 0x4020FFFC
On Mon, Aug 22, 2016 at 10:13:24AM +0530, Lokesh Vutla wrote:
On Sunday 21 August 2016 06:15 PM, Tom Rini wrote:
On Sun, Aug 21, 2016 at 06:29:42AM -0500, Adam Ford wrote:
Using Git bisect, it appears to me that a78cd8613204188991c192b8dae2de0aae3b1722 makes "region `.sram' overflowed by 888 bytes" when I compile for omap3_logic. As I move forward through the git commits that overflow amount is continuing to grow.
Does anyone else with an OMAP3 have this issue?
The best solution I have for this at current is a patch that re-works how we use the download image area and compacts the size we reserve for the scratch area to be still much larger than required.
I agree here. Right now the scratch addr space is 4KB. We can reduce it to 1KB. Below is the patch that is being used in ti-u-boot to solve this issue.
Ah good. That's the same amount I also cut things down to, for all of the TI platforms that have this setup from ROM.
On Mon, Aug 22, 2016 at 7:08 AM, Tom Rini trini@konsulko.com wrote:
On Mon, Aug 22, 2016 at 10:13:24AM +0530, Lokesh Vutla wrote:
On Sunday 21 August 2016 06:15 PM, Tom Rini wrote:
On Sun, Aug 21, 2016 at 06:29:42AM -0500, Adam Ford wrote:
Using Git bisect, it appears to me that a78cd8613204188991c192b8dae2de0aae3b1722 makes "region `.sram' overflowed by 888 bytes" when I compile for omap3_logic. As I move forward through the git commits that overflow amount is continuing to grow.
Does anyone else with an OMAP3 have this issue?
The best solution I have for this at current is a patch that re-works how we use the download image area and compacts the size we reserve for the scratch area to be still much larger than required.
I agree here. Right now the scratch addr space is 4KB. We can reduce it to 1KB. Below is the patch that is being used in ti-u-boot to solve this issue.
Ah good. That's the same amount I also cut things down to, for all of the TI platforms that have this setup from ROM.
Tom -
Is there any way to get one of these patch options pushed before the next RC candidate? I have evaluated both, and I don't see any issues on the DM3730 that I have.
-- Tom
On Thu, Aug 25, 2016 at 11:02:04AM -0500, Adam Ford wrote:
On Mon, Aug 22, 2016 at 7:08 AM, Tom Rini trini@konsulko.com wrote:
On Mon, Aug 22, 2016 at 10:13:24AM +0530, Lokesh Vutla wrote:
On Sunday 21 August 2016 06:15 PM, Tom Rini wrote:
On Sun, Aug 21, 2016 at 06:29:42AM -0500, Adam Ford wrote:
Using Git bisect, it appears to me that a78cd8613204188991c192b8dae2de0aae3b1722 makes "region `.sram' overflowed by 888 bytes" when I compile for omap3_logic. As I move forward through the git commits that overflow amount is continuing to grow.
Does anyone else with an OMAP3 have this issue?
The best solution I have for this at current is a patch that re-works how we use the download image area and compacts the size we reserve for the scratch area to be still much larger than required.
I agree here. Right now the scratch addr space is 4KB. We can reduce it to 1KB. Below is the patch that is being used in ti-u-boot to solve this issue.
Ah good. That's the same amount I also cut things down to, for all of the TI platforms that have this setup from ROM.
Tom -
Is there any way to get one of these patch options pushed before the next RC candidate? I have evaluated both, and I don't see any issues on the DM3730 that I have.
I'm honestly debating it with myself still right now.
participants (3)
-
Adam Ford -
Lokesh Vutla -
Tom Rini