On Tue, 2 Nov 2010 10:17:23 +0100
Stefan Roese s...@denx.de wrote:
Hi Heiko,
On Tuesday 02 November 2010 09:55:46 Heiko Schocher wrote:
- preloader copies first page of nand (nand_spl code) to
0xbb00 (some cpu internal mem) and jumps to this address
- nand_spl does
Dear V, Aneesh,
In message ff55437e1f14da4baeb721a458b6701706fd313...@dbde02.ent.ti.com you
wrote:
If the preloader loads the u-boot to the location that it is built for
everything should work fine once bss is initialized, right?
There is no such thing as a location that it is built for,
Dear Wofgang,
-Original Message-
From: Wolfgang Denk [mailto:w...@denx.de]
Sent: Wednesday, November 03, 2010 4:58 PM
To: V, Aneesh
Cc: Reinhard Meyer; Albert ARIBAUD; u-boot@lists.denx.de; h...@denx.de
Subject: Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
Dear V
Le 03/11/2010 13:03, V, Aneesh a écrit :
Just curious. Why don't we allocate memory for such needs below the
u-boot (lower address) like we do for malloc area and stack. This way
the location where u-boot is relocated will only depend on the SDRAM
size and size of u-boot itself, right?
My
Dear Albert, Wolfgang,
-Original Message-
From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
Sent: Wednesday, November 03, 2010 5:38 PM
To: V, Aneesh
Cc: Wolfgang Denk; u-boot@lists.denx.de; h...@denx.de
Subject: Re: [RFC] arm926ejs: fix jump to RAM nand_boot
Le 03/11/2010
Dear V, Aneesh,
In message ff55437e1f14da4baeb721a458b6701706fd313...@dbde02.ent.ti.com you
wrote:
Just curious. Why don't we allocate memory for such needs below the
u-boot (lower address) like we do for malloc area and stack. This way
the location where u-boot is relocated will only depend
Dear Wolfgang,
-Original Message-
From: Wolfgang Denk [mailto:w...@denx.de]
Sent: Wednesday, November 03, 2010 6:30 PM
To: V, Aneesh
Cc: Reinhard Meyer; Albert ARIBAUD; u-boot@lists.denx.de; h...@denx.de
Subject: Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
Dear V
Dear V, Aneesh,
In message ff55437e1f14da4baeb721a458b6701706fd313...@dbde02.ent.ti.com you
wrote:
Also, I checked the time it takes to do relocation.
On OMAP4430 with Cortex-A9 at 1GHz and LPDDR2 SDRAM at 400MHz it
took a mere 16 ms to do the relocation of u-boot image that was
about
] arm926ejs: fix jump to RAM nand_boot
Dear Albert ARIBAUD,
Le 02/11/2010 09:57, Reinhard Meyer a écrit :
Dear Heiko Schocher,
But there is a possibility to prevent one copy, if TEXT_BASE =
relocation address = CONFIG_SYS_NAND_U_BOOT_DST
In this case nand_spl code copies u-boot from nand
Dear V, Aneesh,
In message ff55437e1f14da4baeb721a458b6701706fd313...@dbde02.ent.ti.com you
wrote:
Shouldn't we provide a CONFIG option by which users can disable
Elf relocation?
Why should we? It would just make the code even more complicated, and
require a lot of additional test cases.
Le 02/11/2010 07:29, Heiko Schocher a écrit :
- preloader copies first page of nand (nand_spl code) to
0xbb00 (some cpu internal mem) and jumps to this address
- nand_spl does lowlevelinit, relocate itself to TEXT_BASE (nand_spl code)
- from there, it copies u-boot code from nand to
Hello Albert,
Albert ARIBAUD wrote:
Le 02/11/2010 07:29, Heiko Schocher a écrit :
- preloader copies first page of nand (nand_spl code) to
0xbb00 (some cpu internal mem) and jumps to this address
- nand_spl does lowlevelinit, relocate itself to TEXT_BASE (nand_spl
code)
- from
Hello Wolfgang,
Wolfgang Denk wrote:
Dear Heiko Schocher,
In message 4ccfafe4.3000...@denx.de you wrote:
- preloader copies first page of nand (nand_spl code) to
0xbb00 (some cpu internal mem) and jumps to this address
- nand_spl does lowlevelinit, relocate itself to TEXT_BASE
Dear Heiko Schocher,
But there is a possibility to prevent one copy, if TEXT_BASE =
relocation address = CONFIG_SYS_NAND_U_BOOT_DST
In this case nand_spl code copies u-boot from nand to
CONFIG_SYS_NAND_U_BOOT_DST. As this is equal to the relocation address,
no need to copy code in
Le 02/11/2010 09:57, Reinhard Meyer a écrit :
Dear Heiko Schocher,
But there is a possibility to prevent one copy, if TEXT_BASE =
relocation address = CONFIG_SYS_NAND_U_BOOT_DST
In this case nand_spl code copies u-boot from nand to
CONFIG_SYS_NAND_U_BOOT_DST. As this is equal to the
Hi Heiko,
On Tuesday 02 November 2010 09:55:46 Heiko Schocher wrote:
- preloader copies first page of nand (nand_spl code) to
0xbb00 (some cpu internal mem) and jumps to this address
- nand_spl does lowlevelinit, relocate itself to TEXT_BASE (nand_spl
code)
Why is this
Dear Reinhard Meyer,
In message 4ccfd27e.3080...@emk-elektronik.de you wrote:
I would recommend that we add code to check for overlapping relocation into
board.c and print a panic message if an overlap is detected.
Why should we try to detect a problem when we can as well avoid the
problem?
Le 02/11/2010 10:34, Reinhard Meyer a écrit :
My original message was: please to not give people the idea that they can
avoid relocation by loading u-boot at the exact address the relocation would
calculate. That is bound to *really* break at the slightest change to u-boot.
Oh, I see. What
Le 02/11/2010 10:38, Wolfgang Denk a écrit :
Dear Reinhard Meyer,
In message4ccfd27e.3080...@emk-elektronik.de you wrote:
I would recommend that we add code to check for overlapping relocation into
board.c and print a panic message if an overlap is detected.
Why should we try to detect a
hi Albert,
On Tue Nov 02, 2010 at 10:47:49AM +0100, Albert ARIBAUD wrote:
Now a solution would be that the actual u-boot size be flashed along
with it, for instance as a literal defined as '.word _end - _start'
right after the vectors. The SPL could load a first NAND block, read the
Le 02/11/2010 10:56, Sughosh Ganu a écrit :
hi Albert,
On Tue Nov 02, 2010 at 10:47:49AM +0100, Albert ARIBAUD wrote:
Now a solution would be that the actual u-boot size be flashed along
with it, for instance as a literal defined as '.word _end - _start'
right after the vectors. The SPL
On Tue Nov 02, 2010 at 12:16:55PM +0100, Albert ARIBAUD wrote:
Le 02/11/2010 10:56, Sughosh Ganu a écrit :
hi Albert,
On Tue Nov 02, 2010 at 10:47:49AM +0100, Albert ARIBAUD wrote:
Now a solution would be that the actual u-boot size be flashed along
with it, for instance as a literal
Dear Albert ARIBAUD,
In message 4ccfde45.3060...@free.fr you wrote:
These is a valid point that the SPL isn't necessarily rebuilt and
flashed every time u-boot itself is built and flashed, so whatever
constant the SPL would carry would only be valid for the u-boot that was
built
Le 01/11/2010 06:13, sughosh ganu a écrit :
On Mon, Nov 1, 2010 at 4:34 AM, Albert ARIBAUDalbert.arib...@free.frwrote:
Le 31/10/2010 23:28, Alexander Holler a écrit :
On 31.10.2010 22:20, Albert Aribaud wrote:
Alexander, Darius, others who already tested the previous RFC patch,
please test
Dear Albert ARIBAUD,
In message 4cce768b.1010...@free.fr you wrote:
Thanks Sugish. Which commands do you use to build the tx25? I tried
make distclean; make tx25_config; make
and
./MAKEALL tx25
Both is correct.
... but this ends up with the code in start.S as if
Dear Albert ARIBAUD,
In message 4ccdf5fc.4060...@free.fr you wrote:
Wolfgang, could you:
- make available to me the exact source tree you're compiling, including
my patches as you applied them plus your changes to them, either as a
clonable git repo or as a patch set to apply on the current
Le 01/11/2010 20:23, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4ccef2e4.5080...@free.fr you wrote:
Also, I understand why the second RFC change I did was harmful to tx25.
Contrary to u-boot itself, u-boot-spl is not compiled to be position
independent; it actually loads at a
Dear Albert ARIBAUD,
In message 4ccf1558.1040...@free.fr you wrote:
Yes, I will now prepare a patchset for mainline master. Do I include the
increase of tx25 size?
If you like - yes please (as separate commit, though). Or I can do
that, if it saves you some trouble.
Best regards,
Wolfgang
On Tuesday, November 2, 2010, Albert ARIBAUD albert.arib...@free.fr wrote:
Le 01/11/2010 20:23, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4ccef2e4.5080...@free.fr you wrote:
Also, I understand why the second RFC change I did was harmful to tx25.
Contrary to u-boot itself,
Le 01/11/2010 20:44, Graeme Russ a écrit :
On Tuesday, November 2, 2010, Albert ARIBAUDalbert.arib...@free.fr wrote:
Le 01/11/2010 20:23, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4ccef2e4.5080...@free.fryou wrote:
Also, I understand why the second RFC change I did was
Le 01/11/2010 20:35, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4ccf1558.1040...@free.fr you wrote:
Yes, I will now prepare a patchset for mainline master. Do I include the
increase of tx25 size?
If you like - yes please (as separate commit, though). Or I can do
that, if it
On Tue, 2 Nov 2010 06:44:41 +1100
Graeme Russ graeme.r...@gmail.com wrote:
Wow, what a terrible waste!
Why does u-boot-spl need to relocate?
Because it is typically initially loaded into a special hardware
buffer. That buffer needs to be freed up to be used to load the
payload.
Can't
Dear Albert Aribaud,
In message 1288560046-6458-1-git-send-email-albert.arib...@free.fr you wrote:
RFC again. WARNING -- apply *above* the previous one, not instead!
I *think* the current jump to nand_boot was wrong, because it
loads an offset but does not add it to the relocated base before
Le 31/10/2010 22:51, Wolfgang Denk a écrit :
Dear Albert Aribaud,
In message1288560046-6458-1-git-send-email-albert.arib...@free.fr you
wrote:
RFC again. WARNING -- apply *above* the previous one, not instead!
I *think* the current jump to nand_boot was wrong, because it
loads an offset
On 31.10.2010 22:20, Albert Aribaud wrote:
Alexander, Darius, others who already tested the previous RFC patch,
please test for non-regression.
Still works here with that patch applied. But that isn't remarkable, because
#ifdef CONFIG_NAND_SPL
that isn't defined here. ;)
Regards,
Le 31/10/2010 23:28, Alexander Holler a écrit :
On 31.10.2010 22:20, Albert Aribaud wrote:
Alexander, Darius, others who already tested the previous RFC patch,
please test for non-regression.
Still works here with that patch applied. But that isn't remarkable, because
#ifdef
On Mon, Nov 1, 2010 at 4:34 AM, Albert ARIBAUD albert.arib...@free.frwrote:
Le 31/10/2010 23:28, Alexander Holler a écrit :
On 31.10.2010 22:20, Albert Aribaud wrote:
Alexander, Darius, others who already tested the previous RFC patch,
please test for non-regression.
Still works here
37 matches
Mail list logo
