Thanks for all the responses!
I decided that the approach from Heiko really is the best/simplest one.
Later I will release a first patch as RFC for how saving of the
boot-params could be done.
With the implementation in the SPL boot I will wait until Aneesh V
finished his work on OMAP4/SPL.
Reg
On Fri, Jul 1, 2011 at 10:42 AM, Simon Schwarz
wrote:
> Addition: As I read a bit about FDT it does not replace ATAGS
> (http://elinux.org/Device_Trees) - it is more a supplement to it. So
> it would not harm to implement minimal ATAGS support and later add the
> FDT to it.
That was true in an ea
Dear Simon Schwarz,
In message you wrote:
>
> a comment from your side would be nice - in what approach do you see
> the best chance for getting it into mainline?
I already commented (see
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/102491). I'm
all for simple and efficient solutions
Dear Simon Schwarz,
In message you wrote:
>
> The problem with approach 3 is that you need to copy the ATAGS image.
> Is there a way to do this without a debugger? If yes it really could
You will need the ATAGs image only in U-Boot, so it should be
sufficient to use nand_write in U-Boot to writ
Dear Simon Schwarz,
In message you wrote:
>
> > - we should define a struct, which contains the 3 values
> > offset, size, destination, so we can create a "nand_load_list"
> > which can contain n entries, that could be processed in
> > a while loop ... so no need for the CONFIG_SYS_BOOT_LINUX
Dear Simon Schwarz,
In message you wrote:
>
> I also thought about that. But I actually thought that FDT support for
> ARM isn't ready yet - although I saw much code for it while I worked
> on ATAGS. How is the FDT-state for ARM?
> If it is already usable I would be happy to adapt it. But if not
Dear Detlev,
In message you wrote:
>
> Just a probably dumb side question, but will ATAGS be deprecated once we
> have the flat device tree also on ARM? As I understand, fdt is certainly
This is our understanding. For DT aware boards, no ATAGS are needed
/used any more.
> the way to go forwar
Dear Wolfgang Denk,
a comment from your side would be nice - in what approach do you see
the best chance for getting it into mainline?
Regards
Simon
2011/7/1 Simon Schwarz :
> Thanks for your feedback Igor!
>
> 2011/7/1 Igor Grinberg :
>> On 07/01/11 12:17, Simon Schwarz wrote:
>>> Ok, topic ATA
Thanks for your feedback Igor!
2011/7/1 Igor Grinberg :
> On 07/01/11 12:17, Simon Schwarz wrote:
>> Ok, topic ATAGS:
>> I see three ways doing ATAGS init for SPL:
>> 1. use bootm.c which means init bd correctly and add a bunch of #ifdef
>> CONFIG_PRELOADER to it - maybe also to some others i don'
On 07/01/11 12:17, Simon Schwarz wrote:
> Ok, topic ATAGS:
> I see three ways doing ATAGS init for SPL:
> 1. use bootm.c which means init bd correctly and add a bunch of #ifdef
> CONFIG_PRELOADER to it - maybe also to some others i don't have on the
> radar yet.
While this is not clean, it might w
Addition: As I read a bit about FDT it does not replace ATAGS
(http://elinux.org/Device_Trees) - it is more a supplement to it. So
it would not harm to implement minimal ATAGS support and later add the
FDT to it.
I started a prototype for ATAGS creation by modifying bootm.c - which
seems (so long)
Hi Detlev,
> Just a probably dumb side question, but will ATAGS be deprecated once we
> have the flat device tree also on ARM? As I understand, fdt is certainly
> the way to go forward, so maybe we can already start with that? In that
> case, the fdt blob will be another binary blob to be passed
Hi Simon,
> Ok, topic ATAGS:
> I see three ways doing ATAGS init for SPL:
> 1. use bootm.c which means init bd correctly and add a bunch of #ifdef
> CONFIG_PRELOADER to it - maybe also to some others i don't have on the
> radar yet.
> 2. Have ATAGS config in board config file and init it at compil
Ok, topic ATAGS:
I see three ways doing ATAGS init for SPL:
1. use bootm.c which means init bd correctly and add a bunch of #ifdef
CONFIG_PRELOADER to it - maybe also to some others i don't have on the
radar yet.
2. Have ATAGS config in board config file and init it at compile time
3. Doing it like
thanks Heiko! That seems like half of the work :)
> - we should define a struct, which contains the 3 values
> offset, size, destination, so we can create a "nand_load_list"
> which can contain n entries, that could be processed in
> a while loop ... so no need for the CONFIG_SYS_BOOT_LINUX
>
Hello Simon,
Simon Schwarz wrote:
> for my bachelor thesis I will implement a direct Linux boot from U-Boot SPL.
> My current plan is to utilize do_bootm_[OS].
>
> Simplest solution is to direct boot Linux/other OS and just boot
> u-boot when a key is pressed. In addition i will also have some te
Hi List,
for my bachelor thesis I will implement a direct Linux boot from U-Boot SPL.
My current plan is to utilize do_bootm_[OS].
Simplest solution is to direct boot Linux/other OS and just boot
u-boot when a key is pressed. In addition i will also have some tests
(header check/CRC) - if they fa
17 matches
Mail list logo
