On Thu, Jan 30, 2014 at 08:39:00PM -0800, Tim Harvey wrote:
On Thu, Jan 30, 2014 at 12:45 PM, Jason Cooper ja...@lakedaemon.net wrote:
Hi Tim,
On Thu, Jan 30, 2014 at 01:11:18AM -0800, Tim Harvey wrote:
My approach has been to define a per-baseboard device-tree in Linux
for a 'fully
Greetings,
I develop the boot-loader and kernel for a family of boards that have
an on-board EEPROM which contains information as to what options are
physically loaded on the board such as memory size/config, and
peripheral IC's. We allow customers to create special builds of our
standard
Hello,
On 30 January 2014 10:11, Tim Harvey thar...@gateworks.com wrote:
Greetings,
Is it more appropriate for the bootloader to 'remove' nodes for
devices that are not physically present or should I be setting their
status property to 'disabled' instead? I'm not clear if either option
Hi Tim,
On Thu, Jan 30, 2014 at 01:11:18AM -0800, Tim Harvey wrote:
My approach has been to define a per-baseboard device-tree in Linux
for a 'fully loaded' board, then remove nodes which the EEPROM claims
are not present in the bootloader before it passes the DTB to the
kernel. I do this by
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
On Thu, Jan 30, 2014 at 12:45 PM, Jason Cooper ja...@lakedaemon.net wrote:
Hi Tim,
On Thu, Jan 30, 2014 at 01:11:18AM -0800, Tim Harvey wrote:
My approach has been to define a per-baseboard device-tree in Linux
for a 'fully loaded' board, then remove nodes which the EEPROM claims
are not
On Thu, Jan 30, 2014 at 1:15 PM, Jason Gunthorpe
jguntho...@obsidianresearch.com wrote:
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
7 matches
Mail list logo
