From: Timur Tabi <timur@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Ideas on U-Boot configuration with FDT
Date: Mon, 21 May 2007 10:19:13 -0500 [thread overview]
Message-ID: <4651B871.2070904@freescale.com> (raw)
In-Reply-To: <4650477F.3040007@grandegger.com>
Wolfgang Grandegger wrote:
> Then something similar to the ENV could be chosen:
>
> CFG_FDT_ADDR
> CFG_FDT_IS_IN_FLASH
> CFG_FDT_IS_IN_xxx
We need two addresses:
1) The address where the FDT is stored when the system is powered up
2) The address in RAM where the FDT should be placed before Linux is booted.
Therefore, we can't have just CFG_FDT_ADDR. We need CFG_FDT_ADDR_xxxx
My vote is to have xxxx be the type of memory. So if CFG_FDT_ADDR_FLASH is defined to
value X, that means that the FDT is stored in flash at address X. If CFG_FDT_ADDR_EEPROM
is defined instead, then it means that FDT is located in EEPROM at address X.
This would eliminate the "CFG_FDT_IS_IN_xxx"-type macros, which I think are redundant.
>>> CFG_FDT_ADDR_BY_ENV:
>>> If defined, the env variable "fdtaddr" is looked up early in the
>>> boot and "fdt" is set accordingly. This allows to hold more
>>> than
I would rather that the FDT subsystem *set* the fdtaddr variable, instead of the other way
around.
>>> CFG_FDT_ADDR_RAM:
>>> If defined, the blob is moved to RAM after relocation for
>>> further preparation or for performance reasons. "fdt" is re-set
>>> accordingly. The blob is then ready and in place for booting
>>> Linux. If CFG_FDT_ADDR_RAM is set to 0, the blob will be copied
>>> to a default location, e.g. before the initrd location.
I think we're going to have to always relocate the FDT to RAM. Considering the level of
functionality that libfdt provides, and considering how much of that functionality depends
on being able to write to the FDT, it makes sense to require it to be in RAM.
>> "checkboard()" is a name that can mean anything. If the function is
The purpose of the function is to provide board-specific code that validates the FDT. The
amount of checking performed is at the discretion of the function.
For example, checkboard() *should* compare the values in the board header file with the
FDT to verify that the memory mappings map, for instance.
--
Timur Tabi
Linux Kernel Developer @ Freescale
next prev parent reply other threads:[~2007-05-21 15:19 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-18 9:09 [U-Boot-Users] Ideas on U-Boot configuration with FDT Wolfgang Grandegger
2007-05-18 14:27 ` Timur Tabi
2007-05-18 14:44 ` Wolfgang Grandegger
2007-05-18 14:48 ` Timur Tabi
2007-05-18 15:01 ` Wolfgang Grandegger
2007-05-18 15:01 ` Timur Tabi
2007-05-18 15:20 ` Wolfgang Grandegger
2007-05-18 15:19 ` Timur Tabi
2007-05-18 19:04 ` Wolfgang Denk
2007-05-18 15:29 ` Jerry Van Baren
2007-05-18 15:35 ` Timur Tabi
2007-05-18 16:05 ` Jerry Van Baren
2007-05-18 16:12 ` Timur Tabi
2007-05-18 16:30 ` Jerry Van Baren
2007-05-20 8:36 ` Wolfgang Grandegger
2007-05-20 9:33 ` Wolfgang Denk
2007-05-20 12:39 ` Jerry Van Baren
2007-05-20 13:05 ` Wolfgang Grandegger
2007-05-21 15:19 ` Timur Tabi [this message]
2007-05-21 16:58 ` Wolfgang Grandegger
2007-05-21 17:02 ` Timur Tabi
2007-05-21 17:18 ` Jerry Van Baren
2007-05-21 18:31 ` Timur Tabi
2007-05-21 19:38 ` Wolfgang Denk
2007-05-21 17:26 ` Wolfgang Grandegger
2007-05-21 19:34 ` Wolfgang Denk
2007-05-21 19:39 ` Timur Tabi
2007-05-21 15:23 ` Timur Tabi
2007-05-21 17:08 ` Wolfgang Grandegger
2007-05-18 19:16 ` Wolfgang Denk
2007-05-18 19:26 ` Jon Loeliger
2007-05-18 19:11 ` Wolfgang Denk
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=4651B871.2070904@freescale.com \
--to=timur@freescale.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox