It should be in linux.c32 in 4.06 and directly supported in 5.00.
Thierry Reding wrote:
>On Fri, Jun 29, 2012 at 03:37:54PM -0700, H. Peter Anvin wrote:
>> On 05/31/2012 08:41 AM, Thierry Reding wrote:
>> > This patch series adds support for passing a Flattened Device Tree
&
On 05/31/2012 08:41 AM, Thierry Reding wrote:
> This patch series adds support for passing a Flattened Device Tree (FDT)
> blob to the Linux kernel. Currently, only the linux.c32 module can do so
> and some additional checking should be done to only pass the blob if the
> kernel supports boot proto
work on it, but I haven't seen anything.
See the LKML thread "[PATCH] ACPI: Implement overriding of arbitrary
ACPI tables via initrd":
http://lkml.kernel.org/r/1332512984-79664-1-git-send-email-tr...@suse.de
-hpa
--
H. Peter
On 01/12/2011 09:07 AM, Sebastian Andrzej Siewior wrote:
>>
>> I'm confused here. Are there multiple ioapic's described by a single
>> device tree node?
>
> Yes, the CE4100 has two IO-APICs. It looks like the first one is
> responsible for the "legacy devices" (like RTC) and the second one is
> u
On 01/03/2011 10:06 AM, H. Peter Anvin wrote:
>
> The problem with that kind of boot wrapper is that they are
> per-architecture, increasing the differences between architectures
> needlessly, and they are often implemented very poorly.
>
> As such, it's nice to have an
On 01/03/2011 09:52 AM, Grant Likely wrote:
>
> I think we've got an impedance mismatch.
>
> The whole point of the ppc boot wrapper, and the kind of boot wrapper
> that I'm talking about here, is that it becomes part of the kernel
> image and is *not* part of firmware. ie. an executable wrapper
On 01/03/2011 04:20 AM, Sebastian Andrzej Siewior wrote:
> Grant Likely wrote:
>>> +extern char cmd_line[COMMAND_LINE_SIZE];
>>> +/* This number is used when no interrupt has been assigned */
>>> +#define NO_IRQ (-1)
>>
>> 0 means NO_IRQ on x86 and most architectures. I will change thi
On 01/03/2011 08:05 AM, H. Peter Anvin wrote:
> On 12/30/2010 12:58 PM, Grant Likely wrote:
>>
>> Right, but in all of those cases a boot wrapper provides the same
>> functionality with better flexability, such as being able to provided
>> the dtb image(s) at install t
On 12/30/2010 12:58 PM, Grant Likely wrote:
>
> Right, but in all of those cases a boot wrapper provides the same
> functionality with better flexability, such as being able to provided
> the dtb image(s) at install time instead of compile time.
>
Assuming the boot wrapper is written correctly.
On 12/30/2010 01:01 PM, Grant Likely wrote:
> Hi Peter,
>
> Since this series is based on the tip tree, these should be merged via
> the same route. Aside from the comments below, I'm okay with patches
> 1 & 2 going in for 2.6.38 (assuming NO_IRQ is fixed). I've picked up
> patch 12 since it is
On 12/30/2010 12:26 AM, Grant Likely wrote:
>
> Since Linux on x86 has pretty much always depended on a two stage boot
> (firmware boots a bootloader like grub which in turn boots the
> kernel), then what is the use case for pursuing an in-kernel dtb
> linkage? simpleimage was used on powerpc for
On 11/29/2010 03:42 PM, Alan Cox wrote:
>> The usual layout is that the PCI bus is a direct child of
>> the root node, and the ISA bus is a child of the PCI bus.
>> That reflects the "Northbridge + Southbridge" wiring that
>
> That isn't strictly true either. On many PC devices the ISA bus (or LPC
On 11/28/2010 05:34 PM, Mitch Bradley wrote:
>
> The OLPC interface might be of some use as a starting point, but would
> need some work. It is currently in use on AMD Geode, Via C7, and Intel
> Atom based systems, but, among other issues, it conflicts with the
> Physical Address Extension fea
to agree with this one. In general I dislike relying on an
implicit (even well-defined) initialized value; unfortunately we ripped
out explicit initializations across the Linux kernel, not due to
readability but due to the fact that long-since-obsolete versions of gcc
would put explicitly-initializ
t doesn't work if you have few,
> or no other variables other than the statics to declare.
>
I wouldn't object to a convention like that, but let's bloody well
realize that that is a brand new convention, and if this convention is
going to stick at all it needs to be mad
On 11/13/2010 10:22 PM, Grant Likely wrote:
>
> 'char' is completely bogus in this context. Either void or struct
> boot_param_header would be more accurate and useful. I believe you
> can do:
>
> extern void __dtb_start;
> extern_void __dtb_end;
>
> And then reference the addresse
On 11/15/2010 08:37 AM, Dirk Brandewie wrote:
>>
>> To match other definitions in this file, this should be defined with
>> parentheses: #define KERNEL_DTB()
>>
>>> + . = ALIGN(32); \
>>> + VMLINUX_SYMBOL(__dtb_start) = .;
On 11/14/2010 11:02 PM, Ingo Molnar wrote:
>
> * H. Peter Anvin wrote:
>
>> What? What is wrong with static variables in functions? It really doesn't
>> seem
>> to be a good idea to make them file-scope if they don't need to be.
>
> They are ve
hat? What is wrong with static variables in functions? It really
doesn't seem to be a good idea to make them file-scope if they don't
need to be.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On 11/12/2010 08:24 AM, Dirk Brandewie wrote:
>
> The second issue is being able to parse the section in the kernel image to
> find
> each of the blobs that have been concatenated together. If the DTB size is
> modulo 32 bytes I can use blob = blob+be32_to_cpu(blob->totalsize) to find
> the
On 11/11/2010 04:03 PM, dirk.brande...@gmail.com wrote:
> From: Dirk Brandewie
>
> This patch forces the size of the DTB to be modulo 32 bytes. This is
> needed to support linking multiple DTB's into a single section in the
> image. GCC wants structures to be 32 byte aligned without this change
>
On 11/10/2010 11:06 AM, Dirk Brandewie wrote:
> On 11/10/2010 10:46 AM, H. Peter Anvin wrote:
>> On 11/10/2010 10:52 AM, dirk.brande...@gmail.com wrote:
>>>
>>> The DTB's have been moved into the .init.data section.
>>
>> Writeable? (As opposed to .i
On 11/10/2010 10:52 AM, dirk.brande...@gmail.com wrote:
>
> The DTB's have been moved into the .init.data section.
>
Writeable? (As opposed to .init.rodata)?
-hpa
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https:/
On 10/28/2010 09:04 PM, David Gibson wrote:
> On Thu, Oct 28, 2010 at 02:44:47PM -0700, H. Peter Anvin wrote:
>> On 10/28/2010 10:32 AM, David VomLehn wrote:
>>>
>>> In my case, where there are a lot of up-front reservations of memory
>>> at a static address,
On 10/28/2010 10:32 AM, David VomLehn wrote:
>
> In my case, where there are a lot of up-front reservations of memory
> at a static address, there is a fair amount of work to do before
> it's possible to do the dynamic address allocation for the blob's
> ultimate destination, but I'm okay with eit
On 10/28/2010 9:35 AM, Sebastian Andrzej Siewior wrote:
H. Peter Anvin wrote:
How big are these blobs in the typical case? Padding to the page size
You usually pad the dtb by 1kib (-p 1024 in dtc). Converting all dtbs in
powerpc's tree leads to:
991545 / 130 = 7627 bytes average.
On 10/27/2010 5:57 PM, David VomLehn wrote:
I've been playing a bit with the patch, and would suggest something
like the following for the second target:
$(obj)/%.dtb.S: $(obj)/%.dtb
@echo '#include'>$@
@echo '.balign PAGE_SIZE'>> $@
@ech
On 10/27/2010 4:09 AM, Grant Likely wrote:
On Tue, Oct 26, 2010 at 07:24:17AM -0700, Dirk Brandewie wrote:
Hi All,
I am working on working on adding support device tree support to an
x86 based platform, hpa pointed out that the device tree blob is
architecture independent and should be part of
7 merge window
> has already been open for almost a week.
>
Right... which means that our attention is going to be elsewhere for a
bit -- probably until after KS/LPC. Sorry, just immediate
prioritization and nothing to do with the relative importance.
-hpa
--
H. Peter Anvin, Intel
On 09/20/2010 07:06 PM, Andres Salomon wrote:
> Any additional comments (ACKs, NACKs, etc) on the patches? If I need
> to rework it (or them), I can certainly make the patch description
> longer.
Sorry... fell off my radar. Will try to look at it tomorrow.
-hpa
--
H. Pe
30 matches
Mail list logo
