Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

2010-11-09 Thread Scott Wood
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

2010-11-03 Thread Wolfgang Denk
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

2010-11-03 Thread V, Aneesh
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

2010-11-03 Thread Albert ARIBAUD
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

2010-11-03 Thread V, Aneesh
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

2010-11-03 Thread Wolfgang Denk
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

2010-11-03 Thread V, Aneesh
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

2010-11-03 Thread Wolfgang Denk
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

2010-11-03 Thread V, Aneesh
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

2010-11-03 Thread Wolfgang Denk
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

2010-11-02 Thread Albert ARIBAUD
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

2010-11-02 Thread Heiko Schocher
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

2010-11-02 Thread Heiko Schocher
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

2010-11-02 Thread Reinhard Meyer
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

2010-11-02 Thread 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?

 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

2010-11-02 Thread Stefan Roese
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

2010-11-02 Thread Wolfgang Denk
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

2010-11-02 Thread Albert ARIBAUD
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

2010-11-02 Thread Albert ARIBAUD
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

2010-11-02 Thread Sughosh Ganu
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

2010-11-02 Thread Albert ARIBAUD
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

2010-11-02 Thread Sughosh Ganu
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

2010-11-02 Thread Wolfgang Denk
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

2010-11-01 Thread Albert ARIBAUD
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

2010-11-01 Thread Wolfgang Denk
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

2010-11-01 Thread Wolfgang Denk
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

2010-11-01 Thread Albert ARIBAUD
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

2010-11-01 Thread Wolfgang Denk
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

2010-11-01 Thread Graeme Russ
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

2010-11-01 Thread Albert ARIBAUD
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

2010-11-01 Thread Albert ARIBAUD
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

2010-11-01 Thread Scott Wood
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

2010-10-31 Thread Wolfgang Denk
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

2010-10-31 Thread Albert ARIBAUD
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

2010-10-31 Thread Alexander Holler
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

2010-10-31 Thread Albert ARIBAUD
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

2010-10-31 Thread sughosh ganu
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