From: Pantelis Antoniou <panto@intracom.gr>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ
Date: Mon, 26 Apr 2004 11:16:37 +0300 [thread overview]
Message-ID: <408CC565.9040006@intracom.gr> (raw)
In-Reply-To: <20040426080216.8FEE9C109F@atlas.denx.de>
Wolfgang Denk wrote:
>In message <408CAD48.4020004@intracom.gr> you wrote:
>
>>IMHO the gd data are pretty much useless in a complicated environment.
>>
>
>Agreed. But that's not what they were meant for.
>
>The gd data is intended to store the absolute minimum of rwritable
>date which is really unavoidable to be stored in global variables
>until the RAM has been initialized and a standard data segment and
>stack are available.
>
>
>>For example when you have multiple network interfaces you have no
>>information which network interface was used to obtain the configuration,
>>which was it's ethernet address etc.
>>
>
>This is something which can easily be done after relocation to RAM,
>so there is no need to use gd for this purpose.
>
>
>>For me the gd is usefull only for the simple case of most boards with
>>one network interface, fixed clock etc.
>>
>
>No. This is NOT the intention.
>
>
>>For anything more complicated is better to parse the environment variables.
>>
>
>In the end we will probably have something like bi_recs ...
>
>
>>Why don't we just add the missing information to the environment variables?
>>
>
>Because you cannot access envrionment in very early initialization
>steps, or you have to do it in a very slow way (like reading byte by
>byte from serial EEPROM), which would horribly slow down boot.
>
>
Correct.
But I'm not talking about the early initialization.
I'm talking about how the loaded image/kernel gets access to the
information.
At that point the variables are placed in RAM, and can contain
every info that is present in the gd structure.
U-boot can continue to use the gd structure, but the application
can access all it's configuration from the environment variables.
For example we can fill a environment variable with the system
clock value at the later stages of initialization.
>Best regards,
>
>Wolfgang Denk
>
>
Regards
Pantelis
next prev parent reply other threads:[~2004-04-26 8:16 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-22 16:02 [U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ Kumar Gala
2004-04-22 17:14 ` Wolfgang Denk
2004-04-22 17:28 ` Kumar Gala
2004-04-22 19:44 ` Wolfgang Denk
2004-04-22 19:51 ` Kumar Gala
2004-04-25 14:03 ` Wolfgang Denk
2004-04-26 6:33 ` Pantelis Antoniou
2004-04-26 8:02 ` Wolfgang Denk
2004-04-26 8:16 ` Pantelis Antoniou [this message]
2004-04-26 9:14 ` Wolfgang Denk
2004-04-26 10:18 ` Pantelis Antoniou
2004-04-26 11:13 ` Wolfgang Denk
2004-04-26 11:32 ` Pantelis Antoniou
2004-04-26 13:03 ` Wolfgang Denk
2004-04-26 13:25 ` Pantelis Antoniou
2004-04-26 14:00 ` Wolfgang Denk
2004-04-22 17:58 ` Dan Malek
-- strict thread matches above, loose matches on Subject: below --
2004-04-22 17:52 VanBaren, Gerald
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=408CC565.9040006@intracom.gr \
--to=panto@intracom.gr \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.