Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 lowlevelinit, relocate itself to TEXT_BASE (nand_spl code) Why is this relocation needed? I understand that this 0xbb00 Thats the question to solve ... don;t know, why nand_spl code on arm (and other architectures?) do this ... I try to have a look to find out, if we can run the nand_spl code complete from this address, and immedietaly copy u-boot from nand to ram ... On PPC4xx we need to copy the code from the original location (4KiB loaded via the ROM IPL boot loader) to SDRAM and continue running it from there. This is necessary since we can't run from the original location (0xfxxx) and use the PPC4xx NAND controller at the same time. We have the same restriction on FSL NAND controllers -- certainly the eLBC, and I think also the NFC which is used on ARM, though I'm less familiar with that one. So there is no relocation to TEXT_BASE on 4xx but only a copy to CONFIG_SYS_NAND_BOOT_SPL_DST. It looks like you do memory init from assembly code to pull that off. On 83xx/85xx we do an actual relocation of the NAND SPL. Not sure about ARM. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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, as the location in RAM may differ, depending on enabled features - for example, pRAM size or (shared) frame buffer size may change depending on environment variable settings. In the result, the location of U-Boot in RAM shifts. You cannot know the final address at build time. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de In matters of principle, stand like a rock; in matters of taste, swim with the current.- Thomas Jefferson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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, 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, as the location in RAM may differ, depending on enabled features - for example, pRAM size or (shared) frame buffer size may change depending on environment variable settings. In the result, the location of U-Boot in RAM shifts. You cannot know the final address at build time. 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? Best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 guess is that the same memory will be allocated by the OS after u-boot, and allocating at the same location in both occasions allows for things like flicker-free boot splashes and such. And if you allocate this below u-boot, you end up with a split memory map with some allocated space in the middle of useable OS or user space. So we allocate that at top of RAM, and later on, Linux can use all the memory below as a single contiguous area. Best regards, Aneesh Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 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 guess is that the same memory will be allocated by the OS after u-boot, and allocating at the same location in both occasions allows for things like flicker-free boot splashes and such. And if you allocate this below u-boot, you end up with a split memory map with some allocated space in the middle of useable OS or user space. So we allocate that at top of RAM, and later on, Linux can use all the memory below as a single contiguous area. I get it now. But in any case, there are many boards that do not use these features like ours. Skipping relocation, if the support is provided may be useful for such boards. Anyway, as I said earlier, we will come back with data on how much time can be saved by skipping relocation. Best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 on the SDRAM=20 size and size of u-boot itself, right? That would mean that all the memory where U-Boot was located is lost for use in Linux, as we reserve these areas by adjusting the mem= boot argument. Allocation of such memory blocks must start at the top, ang do downwards. And U-Boot lies below that, then. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de And now remains That we find out the cause of this effect, Or rather say, the cause of this defect... -- Hamlet, Act II, Scene 2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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, 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 on the SDRAM=20 size and size of u-boot itself, right? That would mean that all the memory where U-Boot was located is lost for use in Linux, as we reserve these areas by adjusting the mem= boot argument. Allocation of such memory blocks must start at the top, ang do downwards. And U-Boot lies below that, then. Thanks. It's clear now. 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 146 KB. I agree with you. Skipping relocation is not worth the complexity. Best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 146 KB. I agree with you. Skipping relocation is not worth the complexity. Thanks a lot for the testing. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Successful and fortunate crime is called virtue. - Seneca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
Dear Reinhard, Wolfgang, -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot- boun...@lists.denx.de] On Behalf Of Reinhard Meyer Sent: Tuesday, November 02, 2010 3:04 PM To: Albert ARIBAUD Cc: u-boot@lists.denx.de; h...@denx.de Subject: Re: [U-Boot] [RFC] 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 to CONFIG_SYS_NAND_U_BOOT_DST. As this is equal to the relocation address, no need to copy code in relocate_code(). But as codesize changes (and with it relocation address) this is not a perfect solution. Worse: it would certainly crash since the original and relocated memory areas must not overlap - they sure would with even the slightest size change. I'm not sure I get you there. If u-boot was linked for a given address and happends to be loaded at that same address, then there is no need to relocate, right? *if* the code size changes, need for relocation would arise... 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. I *think* overlap would be correctly handled if we modify the copy code to copy from top to bottom, because we know that the destination is higher than the source. No, in above case the (new) destination could be lower than the loaded address (e.g. code size increased). In any case it is not worth the effort to plan for overlapping relocations. We can always load u-boot to a very low address of SDRAM and let it relocate. The only tricky case would be when the target address is right in the middle of the source relocation code, because then the last iteratons of the copy code would corrupt this code; that can be avoided by making sure the SPL loads u-boot low enough in RAM. Exactly. 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. Shouldn't we provide a CONFIG option by which users can disable Elf relocation? On production systems you know exactly how much memory you have. Relocation may not be very useful. On the other hand faster boot is a bigger concern. Shouldn't we support this case? Best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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. On production systems you know exactly how much memory you have. Relocation may not be very useful. On the other hand faster boot is a bigger concern. Shouldn't we support this case? If time in your concern, then did you measure the time the relocation costs you? How long is it on your system? Please be aware that a whole number of other features depend on doing real relocation. Also, it brings us a lot closer to use common code across architectures, instead of having to maintain several different (and differently behaving) implementations. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If programming was easy, they wouldn't need something as complicated as a human being to do it, now would they? - L. Wall R. L. Schwartz, _Programming Perl_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 CONFIG_SYS_NAND_U_BOOT_DST and jumps to CONFIG_SYS_NAND_U_BOOT_START - u-boot run into board_init_f, calculates new relocation address and relocates ... 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 relocate_code(). But as codesize changes (and with it relocation address) this is not a perfect solution. bye, Heiko Heiko, Since SPL is loaded in internal RAM, and since U-BOOT itself is loaded only in DRAM, why does SPL need to relocate itself? Can it not run entirely from IRAM and then jump to U-BOOT? If SPL needs to relocate, then why does it run only the copy loop but not the fixups loop? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 there, it copies u-boot code from nand to
CONFIG_SYS_NAND_U_BOOT_DST
and jumps to CONFIG_SYS_NAND_U_BOOT_START
- u-boot run into board_init_f, calculates new relocation address
and relocates ...
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 relocate_code().
But as codesize changes (and with it relocation address) this
is not a perfect solution.
bye,
Heiko
Heiko,
Since SPL is loaded in internal RAM, and since U-BOOT itself is loaded
only in DRAM, why does SPL need to relocate itself? Can it not run
entirely from IRAM and then jump to U-BOOT?
Good question. This was the old behaviour. Check this, if we can
prevent it.
If SPL needs to relocate, then why does it run only the copy loop but
not the fixups loop?
in nand_spl//nand_boot_fsl_nfc.c:
void board_init_f (ulong bootflag)
{
relocate_code (CONFIG_SYS_TEXT_BASE - TOTAL_MALLOC_LEN, NULL,
CONFIG_SYS_TEXT_BASE);
}
- nand_spl code gets copied where it is compiled for ... no need
for fixups.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 (nand_spl code) Why is this relocation needed? I understand that this 0xbb00 Thats the question to solve ... don;t know, why nand_spl code on arm (and other architectures?) do this ... I try to have a look to find out, if we can run the nand_spl code complete from this address, and immedietaly copy u-boot from nand to ram ... address is determined by the given hardware ans as such always fix? Yep. But as codesize changes (and with it relocation address) this is not a perfect solution. Indeed. CONFIG_SYS_NAND_U_BOOT_SIZE should be dropped, and the avtual value should be derived from the actual U-Boot image building process. Yep. bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 relocate_code(). But as codesize changes (and with it relocation address) this is not a perfect solution. Worse: it would certainly crash since the original and relocated memory areas must not overlap - they sure would with even the slightest size change. That idea should not be promoted any further. 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. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 relocation address, no need to copy code in relocate_code(). But as codesize changes (and with it relocation address) this is not a perfect solution. Worse: it would certainly crash since the original and relocated memory areas must not overlap - they sure would with even the slightest size change. I'm not sure I get you there. If u-boot was linked for a given address and happends to be loaded at that same address, then there is no need to relocate, right? 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. I *think* overlap would be correctly handled if we modify the copy code to copy from top to bottom, because we know that the destination is higher than the source. The only tricky case would be when the target address is right in the middle of the source relocation code, because then the last iteratons of the copy code would corrupt this code; that can be avoided by making sure the SPL loads u-boot low enough in RAM. Best Regards, Reinhard Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 relocation needed? I understand that this 0xbb00 Thats the question to solve ... don;t know, why nand_spl code on arm (and other architectures?) do this ... I try to have a look to find out, if we can run the nand_spl code complete from this address, and immedietaly copy u-boot from nand to ram ... On PPC4xx we need to copy the code from the original location (4KiB loaded via the ROM IPL boot loader) to SDRAM and continue running it from there. This is necessary since we can't run from the original location (0xfxxx) and use the PPC4xx NAND controller at the same time. So there is no relocation to TEXT_BASE on 4xx but only a copy to CONFIG_SYS_NAND_BOOT_SPL_DST. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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? The needed image isze if known when we build the image, we just have to use it instead of manually defining a constant value. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The faster I go, the behinder I get. -- Lewis Carroll ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 you mean is if people force the loading of u-boot at a fixed address which happens to be its current relocated address, a change of size in u-boot will break because the relocated address will change but the forced address won't. I was talking about a different thing, which is if u-boot finds that the address at which it runs now is the address at which it should run, then it can skip relocation (copy and fixups). Best Regards, Reinhard Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 problem when we can as well avoid the problem? The needed image isze if known when we build the image, we just have to use it instead of manually defining a constant value. 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 alongside. 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 literal, round it to a multiple of NAND blocks by default, and then read this quantity. That would remove the dependency at the cost of extra code in the SPL, though, and not all boards might be able to afford it. Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 literal, round it to a multiple of NAND blocks by default, and then read this quantity. That would remove the dependency at the cost of extra code in the SPL, though, and not all boards might be able to afford it. Another issue is that the nand_spl might be compiled and flashed to the NAND as a separate entity, using a separate flashing mechanism. If we use the dynamic calculation of the u-boot size, this would necessitate building and flashing the nand_spl each time along with u-boot. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 could load a first NAND block, read the literal, round it to a multiple of NAND blocks by default, and then read this quantity. That would remove the dependency at the cost of extra code in the SPL, though, and not all boards might be able to afford it. Another issue is that the nand_spl might be compiled and flashed to the NAND as a separate entity, using a separate flashing mechanism. If we use the dynamic calculation of the u-boot size, this would necessitate building and flashing the nand_spl each time along with u-boot. Not with the solution I describe, as the once-flashed SPL would fetch the actual size from the actual u-boot. -sughosh Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 defined as '.word _end - _start' right after the vectors. The SPL could load a first NAND block, read the literal, round it to a multiple of NAND blocks by default, and then read this quantity. That would remove the dependency at the cost of extra code in the SPL, though, and not all boards might be able to afford it. Another issue is that the nand_spl might be compiled and flashed to the NAND as a separate entity, using a separate flashing mechanism. If we use the dynamic calculation of the u-boot size, this would necessitate building and flashing the nand_spl each time along with u-boot. Not with the solution I describe, as the once-flashed SPL would fetch the actual size from the actual u-boot. Yes that is correct. I was referring to the other solution of fixing the size through the script. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 alongside. I have to admit that I was not aware that there are systems were SPL and U-Boot itself are not bundled into a single image, but handled separately. [I have to admit that I don;t like such a setup; it cries for incompatibilities and other trouble.] 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 literal, round it to a multiple of NAND blocks by default, and then read this quantity. That would remove the dependency at the cost of extra code in the SPL, though, and not all boards might be able to afford it. Indeed. Maybe be can combine several approaches: - In case SPL and U-Boot are combined into a single image anyway, we can use a compile-time compution of the needed length, without additional code in the SPL. - Where this is not prossible (i. e. SPL and U-Boot are separate), we can try and optionally provide the solution you suggest. - Where memory is toot ight to allow for that code, the old style of a static #define will be used as a fallback. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Due to lack of disk space, this fortune database has been discontinued. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 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. ;) ... and tx25 seems not to have it defined either, so my change should not have affected Wolfgang's tests. :/ I think it is defined in nand_spl/board/karo/tx25/Makefile. We do get a nand_spl/u-boot-spl when we compile for the tx25 board, which has a reference to nand_boot. Thanks Sugish. Which commands do you use to build the tx25? I tried make distclean; make tx25_config; make and ./MAKEALL tx25 ... but this ends up with the code in start.S as if NAND_SPL was not defined, i.e. calling board_inir_r, not nand_boot. -sughosh Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 NAND_SPL was not defined, i.e. calling board_inir_r, not nand_boot. There is u-boot (u-boot.bin) and nand_spl/u-boot-spl (nand_spl/u-boot-spl.bin) which together result in u-boot-nand.bin which then is booted from NAND. And there is u-boot.map and nand_spl/u-boot-spl.map ... More in following messages. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If a computer can't directly address all the RAM you can use, it's just a toy. - anonymous comp.sys.amiga posting, non-sequitir ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 u-boot master branch; Please see git://git.denx.de/u-boot-testing.git , branch reloc-tests - indicate exactly how you build your u-boot; Both with ELDK and CS tools: ./MAKELL tx25 - provide the u-boot binary that you last built (the one that has no output). Will send two tarballs (built with ELDK and CS) in PM. My goal here is to reproduce an u-boot identical to yours, in order to make sur I can produce controlled u-boots for tx25, and then build some specific tx25 u-boots for you to run. Thanks! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de backups: always in season, never out of style. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 given address then copies itself, without relocating, to its home location. It copies _itself_? Not the U-Boot payload? Heiko, is this intentional? Do we really first load the whole image, then copy the U-Boot payload to some other address, then relocate it to yet another one? I haven't been clear. The boot ROM or IPL loads u-boot-spl in RAM at a fixed location and jumps to it. u-boot-spl copies itself at its intended location if not already there, and jumps to tiself at that new location. u-boot-spl loads u-boot at a fixed location and jumps to it. u-boot relocates (copies and fixes up) itself at top of ram if not already there, and jumps to itself at that new location. I also think I might have found out what hit tx25. include/configs/tx25 defines the size of u-boot which SPL will use to load from NAND into RAM. currently it is defined thus: #define CONFIG_SYS_NAND_U_BOOT_SIZE 0x3 Arghh... Wolfgang, please try the following: - on u-boot-testing, branch reloc_tests, revert commit 7fab02d... (that's arm926ejs: fix jump to RAM nand_boot) as this 'fix' is a mistake. - in include/configs/tx25.h, increasing CONFIG_SYS_NAND_U_BOOT_SIZE to 0x31000 Let me know if building tx25 after these two corrections makes things better. Bingo. Phew. Both the ELDK and the CS compiled versions run fine now: with ELDK: U-Boot 2010.12-rc1-00030-g7fec359 (Nov 01 2010 - 20:13:53) U-Boot code: 8120 - 81224E64 BSS: - 8122DF68 CPU: Freescale i.MX25 at 399 MHz monitor len: 0002DF68 ramsize: 0200 TLB table at: 81ff Top of RAM usable for U-Boot at: 81ff Reserving 183k for U-Boot at: 81fc2000 Reserving 1024k for malloc() at: 81ec2000 Reserving 24 Bytes for Board Info at: 81ec1fe8 Reserving 92 Bytes for Global Data at: 81ec1f8c New Stack Pointer is: 81ec1f88 RAM Configuration: Bank #0: 8000 32 MiB relocation Offset is: 00dc2000 monitor flash len: 00024E64 Now running in RAM - U-Boot at: 81fc2000 with CS: U-Boot 2010.12-rc1-00030-g7fec359 (Nov 01 2010 - 20:18:09) U-Boot code: 8120 - 812237E8 BSS: - 8122C8F0 CPU: Freescale i.MX25 at 399 MHz monitor len: 0002C8F0 ramsize: 0200 TLB table at: 81ff Top of RAM usable for U-Boot at: 81ff Reserving 178k for U-Boot at: 81fc3000 Reserving 1024k for malloc() at: 81ec3000 Reserving 24 Bytes for Board Info at: 81ec2fe8 Reserving 92 Bytes for Global Data at: 81ec2f8c New Stack Pointer is: 81ec2f88 RAM Configuration: Bank #0: 8000 32 MiB relocation Offset is: 00dc3000 monitor flash len: 000237E8 Now running in RAM - U-Boot at: 81fc3000 Note that the CS tool chain gives somewhat smaller code... Thanks a lot! You're welcome. :) Guess we should submit the temporary changes now as formal patches? Yes, I will now prepare a patchset for mainline master. Do I include the increase of tx25 size? Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If in any problem you find yourself doing an immense amount of work, the answer can be obtained by simple inspection. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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, u-boot-spl is not compiled to be position independent; it actually loads at a given address then copies itself, without relocating, to its home location. It copies _itself_? Not the U-Boot payload? Heiko, is this intentional? Do we really first load the whole image, then copy the U-Boot payload to some other address, then relocate it to yet another one? I haven't been clear. The boot ROM or IPL loads u-boot-spl in RAM at a fixed location and jumps to it. u-boot-spl copies itself at its intended location if not already there, and jumps to tiself at that new location. u-boot-spl loads u-boot at a fixed location and jumps to it. u-boot relocates (copies and fixes up) itself at top of ram if not already there, and jumps to itself at that new location. Wow, what a terrible waste! Why does u-boot-spl need to relocate? Can't u-boot-spl load AND relocate u-boot, or does u-boot-spl have tight space constraints? Regards Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 harmful to tx25. Contrary to u-boot itself, u-boot-spl is not compiled to be position independent; it actually loads at a given address then copies itself, without relocating, to its home location. It copies _itself_? Not the U-Boot payload? Heiko, is this intentional? Do we really first load the whole image, then copy the U-Boot payload to some other address, then relocate it to yet another one? I haven't been clear. The boot ROM or IPL loads u-boot-spl in RAM at a fixed location and jumps to it. u-boot-spl copies itself at its intended location if not already there, and jumps to tiself at that new location. u-boot-spl loads u-boot at a fixed location and jumps to it. u-boot relocates (copies and fixes up) itself at top of ram if not already there, and jumps to itself at that new location. Wow, what a terrible waste! Why does u-boot-spl need to relocate? As I said, u-boot-spl does not relocate, it only copies itself to its link-time location and jumps there, and it does this only if loaded somewhere else to boot (if I may say so). *Usually* it will be loaded at the right place and thus won't copy itself and jump to itself. It still takes up some space, though. The copy and jump could actually be #ifdef's on CONFIG_NAND_SPL if everyone thinks it is safe -- please comment quickly as I'm preparing a patch set and that could go in it if agreed to. Can't u-boot-spl load AND relocate u-boot, or does u-boot-spl have tight space constraints? It has; it comes from a (usually small) NAND page. Regards Graeme Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 saves you some trouble. I'll do a three-patch set: arm926ejs, nand_spl and tx25. That ok? Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 u-boot-spl load AND relocate u-boot, or does u-boot-spl have tight space constraints? It has tight space constraints -- often 4 KiB, sometimes even less IIRC. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 jumping to it. I thus applied the same sequence as board_init_r. Wolfgang, please test to see if tx25 works with this. Doesn't work at all for me - zero cosole output; neither with ELDK nor with CS toolchains. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Well, the way I see it, logic is only a way of being ignorant by num- bers. - Terry Pratchett, _Small Gods_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 but does not add it to the relocated base before jumping to it. I thus applied the same sequence as board_init_r. Wolfgang, please test to see if tx25 works with this. Doesn't work at all for me - zero cosole output; neither with ELDK nor with CS toolchains. That's when I wish I had a tx25 board here. :( Back to staring at the source code... Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 CONFIG_NAND_SPL that isn't defined here. ;) ... and tx25 seems not to have it defined either, so my change should not have affected Wolfgang's tests. :/ 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 u-boot master branch; - indicate exactly how you build your u-boot; - provide the u-boot binary that you last built (the one that has no output). My goal here is to reproduce an u-boot identical to yours, in order to make sur I can produce controlled u-boots for tx25, and then build some specific tx25 u-boots for you to run. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
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 with that patch applied. But that isn't remarkable, because #ifdef CONFIG_NAND_SPL that isn't defined here. ;) ... and tx25 seems not to have it defined either, so my change should not have affected Wolfgang's tests. :/ I think it is defined in nand_spl/board/karo/tx25/Makefile. We do get a nand_spl/u-boot-spl when we compile for the tx25 board, which has a reference to nand_boot. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
