From: jgunthorpe@obsidianresearch.com (Jason Gunthorpe)
To: linux-arm-kernel@lists.infradead.org
Subject: recommended action for bootloaders regarding modifying device-tree nodes
Date: Thu, 30 Jan 2014 14:15:12 -0700 [thread overview]
Message-ID: <20140130211512.GD13372@obsidianresearch.com> (raw)
In-Reply-To: <20140130204558.GC29184@titan.lakedaemon.net>
On Thu, Jan 30, 2014 at 03:45:58PM -0500, Jason Cooper wrote:
> This is more of a process question: Is there any information captured
> in your EEPROM that can't be represented in the dtb? iow, at the point
> when you write the EEPROM, why not write the dtb to it as configured?
I can share what we do here.. In our systems the serial EEPROM is only
256 bytes, so storing things in DT format would be challenging.
What we do is have a master DTB that has the union of all our
configurations. The boot process has a very simple bit of code that
runs down the DTB in binary format and replaces entire
OF_DT_BEGIN_NODE->OF_DT_END_NODE regions with OF_DT_NOP.
The NOP approach is very simple, no other changes (eg offset
recalculation) needs to be done to the DT, so we can do this process
with a very small code footprint and without libfdt.
Choosing which sections to drop is done with some combination of
hardwired code and searching for specific property patterns. There are
also a few places where placeholder sections are directly fixed up, eg
a mac address is written into a placeholder of 0s, etc.
So an example might be
optional_peripheral at 10000 {
orc,board-style = <1>;
[..]
}
Eg The board-style number comes from the EEPROM and if board-style !=
1 then the entire stanza is replaced with NOP.
Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
To: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>
Cc: Tim Harvey <tharvey-UMMOYl/HMS+akBO8gow8eQ@public.gmane.org>,
Grant Likely
<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
u-boot-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org
Subject: Re: recommended action for bootloaders regarding modifying device-tree nodes
Date: Thu, 30 Jan 2014 14:15:12 -0700 [thread overview]
Message-ID: <20140130211512.GD13372@obsidianresearch.com> (raw)
In-Reply-To: <20140130204558.GC29184-u4khhh1J0LxI1Ri9qeTfzeTW4wlIGRCZ@public.gmane.org>
On Thu, Jan 30, 2014 at 03:45:58PM -0500, Jason Cooper wrote:
> This is more of a process question: Is there any information captured
> in your EEPROM that can't be represented in the dtb? iow, at the point
> when you write the EEPROM, why not write the dtb to it as configured?
I can share what we do here.. In our systems the serial EEPROM is only
256 bytes, so storing things in DT format would be challenging.
What we do is have a master DTB that has the union of all our
configurations. The boot process has a very simple bit of code that
runs down the DTB in binary format and replaces entire
OF_DT_BEGIN_NODE->OF_DT_END_NODE regions with OF_DT_NOP.
The NOP approach is very simple, no other changes (eg offset
recalculation) needs to be done to the DT, so we can do this process
with a very small code footprint and without libfdt.
Choosing which sections to drop is done with some combination of
hardwired code and searching for specific property patterns. There are
also a few places where placeholder sections are directly fixed up, eg
a mac address is written into a placeholder of 0s, etc.
So an example might be
optional_peripheral@10000 {
orc,board-style = <1>;
[..]
}
Eg The board-style number comes from the EEPROM and if board-style !=
1 then the entire stanza is replaced with NOP.
Jason
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] recommended action for bootloaders regarding modifying device-tree nodes
Date: Thu, 30 Jan 2014 14:15:12 -0700 [thread overview]
Message-ID: <20140130211512.GD13372@obsidianresearch.com> (raw)
In-Reply-To: <20140130204558.GC29184@titan.lakedaemon.net>
On Thu, Jan 30, 2014 at 03:45:58PM -0500, Jason Cooper wrote:
> This is more of a process question: Is there any information captured
> in your EEPROM that can't be represented in the dtb? iow, at the point
> when you write the EEPROM, why not write the dtb to it as configured?
I can share what we do here.. In our systems the serial EEPROM is only
256 bytes, so storing things in DT format would be challenging.
What we do is have a master DTB that has the union of all our
configurations. The boot process has a very simple bit of code that
runs down the DTB in binary format and replaces entire
OF_DT_BEGIN_NODE->OF_DT_END_NODE regions with OF_DT_NOP.
The NOP approach is very simple, no other changes (eg offset
recalculation) needs to be done to the DT, so we can do this process
with a very small code footprint and without libfdt.
Choosing which sections to drop is done with some combination of
hardwired code and searching for specific property patterns. There are
also a few places where placeholder sections are directly fixed up, eg
a mac address is written into a placeholder of 0s, etc.
So an example might be
optional_peripheral at 10000 {
orc,board-style = <1>;
[..]
}
Eg The board-style number comes from the EEPROM and if board-style !=
1 then the entire stanza is replaced with NOP.
Jason
next prev parent reply other threads:[~2014-01-30 21:15 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-30 9:11 recommended action for bootloaders regarding modifying device-tree nodes Tim Harvey
2014-01-30 9:11 ` [U-Boot] " Tim Harvey
2014-01-30 9:11 ` Tim Harvey
2014-01-30 9:22 ` [U-Boot] " Michal Suchanek
2014-01-30 9:22 ` Michal Suchanek
2014-01-30 9:22 ` Michal Suchanek
2014-01-30 20:45 ` Jason Cooper
2014-01-30 20:45 ` [U-Boot] " Jason Cooper
2014-01-30 20:45 ` Jason Cooper
2014-01-30 21:15 ` Jason Gunthorpe [this message]
2014-01-30 21:15 ` [U-Boot] " Jason Gunthorpe
2014-01-30 21:15 ` Jason Gunthorpe
2014-01-31 4:44 ` Tim Harvey
2014-01-31 4:44 ` [U-Boot] " Tim Harvey
2014-01-31 4:44 ` Tim Harvey
2014-01-31 4:39 ` Tim Harvey
2014-01-31 4:39 ` [U-Boot] " Tim Harvey
2014-01-31 4:39 ` Tim Harvey
2014-01-31 16:07 ` Jason Cooper
2014-01-31 16:07 ` [U-Boot] " Jason Cooper
2014-01-31 16:07 ` Jason Cooper
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=20140130211512.GD13372@obsidianresearch.com \
--to=jgunthorpe@obsidianresearch.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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.