public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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

  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