On Mon, 4 Apr 2011, Andy Green wrote:
> Well, in the iMX31 case there is only a 2KByte SRAM on-die that gets
> auto-filled by the ROM. In the case of SD Card boot which I implemented - the
> bootloader is on the SD Card at a defined place - it means you need to fit
> your SD init, "mmc stack" and
On Mon, Apr 4, 2011 at 8:50 AM, Nicolas Pitre wrote:
> On Mon, 4 Apr 2011, Eric Miao wrote:
>
>> >> * And very hardware specific code moved out to a controllable place,
>> >> i.e. something like BIOS
>> >
>> > Sorry, but I must vehemently disagree here. BIOSes are a problem for
>> > Open So
On Mon, 4 Apr 2011, Eric Miao wrote:
> >> * And very hardware specific code moved out to a controllable place,
> >> i.e. something like BIOS
> >
> > Sorry, but I must vehemently disagree here. BIOSes are a problem for
> > Open Source, not a solution. On X86 they use BIOS services only when
>> * And very hardware specific code moved out to a controllable place,
>> i.e. something like BIOS
>
> Sorry, but I must vehemently disagree here. BIOSes are a problem for
> Open Source, not a solution. On X86 they use BIOS services only when
> there is simply no other choice, because the
On 04/04/2011 12:12 PM, Somebody in the thread at some point said:
Hi -
Specifically: the bootloader prerequisites for accessing the DT data may
entirely mandate private bootloader knowledge of ALL the information it
would have required from DT. For example, bootloader must init SDRAM,
knowing
On Mon, Apr 4, 2011 at 4:54 AM, Andy Green wrote:
> Another way to solve it, would be to encode the set of device trees
> supported in a way that removes redundancy. Then the additional data needed
> to resolve a generic OMAP3 device table into overo or beagle or any similar
> board would be a sm
On Mon, Apr 4, 2011 at 4:21 AM, Andy Green wrote:
>> Matt and I may differ a little on the responsibilities of the
>> bootloader. I think it should do the bare minimum needed to get the
>> kernel loaded and to feed it a device tree. Matt has it doing more
>> like setting up all of the pin configur
On Mon, Apr 4, 2011 at 1:38 PM, Bryan Wu wrote:
> On Fri, Apr 1, 2011 at 11:43 PM, Eric Miao wrote:
>> Just FYI - lengthy but very interesting read, Linus was really good at
>> wording, enjoy heh :-)
>>
>> https://lkml.org/lkml/2011/3/17/283
>>
>> So maybe it's just a right time to talk about usi
On 04/04/2011 03:22 AM, Somebody in the thread at some point said:
Hi -
In a perfect world, the DT data would be tied to the hardware and
provided by the bootloader to the kernel. It would be produced by
hardware vendors who would only have to describe their hardware in this
OS independent abst
On 04/03/2011 09:09 PM, Somebody in the thread at some point said:
Hi -
Can you describe why code in the bootloader is a better place than code in
the kernel early init? I mean if you go and look in say U-Boot sources,
it's a lot less beautiful and elegant than kernel code.
You shouldn't jus
On Fri, Apr 1, 2011 at 11:43 PM, Eric Miao wrote:
> Just FYI - lengthy but very interesting read, Linus was really good at
> wording, enjoy heh :-)
>
> https://lkml.org/lkml/2011/3/17/283
>
> So maybe it's just a right time to talk about using linaro ARM kernel
> tree as a fork for quick merge of
On Sun, 3 Apr 2011, Andy Green wrote:
> I just don't see people tweaking DT tables by package update and leaving the
> kernel package unchanged, I do see wrong version DT tables getting pulled in,
> bootloader environments pointing to the wrong place or NAND or default
> environments coming in and
On Sun, Apr 3, 2011 at 11:26 AM, Jaswinder Singh
wrote:
> On 3 April 2011 21:44, Andy Green wrote:
>> On 04/03/2011 05:05 PM, Somebody in the thread at some point said:
>>
>>> Above everything else, I definitely like to see DT get done first,
>>> it's essential for SoC these days.
>>
>> All I am
On Sun, Apr 3, 2011 at 1:26 PM, Andy Green wrote:
> On 04/03/2011 06:19 PM, Somebody in the thread at some point said:
>> hardware in the device tree and remove the old kernel code that was
>> building the description. Move on to device trees provided by the
>> bootloader. After basic hardware des
On 04/03/2011 06:19 PM, Somebody in the thread at some point said:
Hi -
On the other hand, device trees aren't a static solution. For example,
they haven't come up with a generic mechanism for completely
describing things like clock and power management domains. But let's
figure out schemes for
On 3 April 2011 21:44, Andy Green wrote:
> On 04/03/2011 05:05 PM, Somebody in the thread at some point said:
>
>> Above everything else, I definitely like to see DT get done first,
>> it's essential for SoC these days.
>
> All I am suggesting is bind the DTs in the kernel. That's easier and fast
On Sun, Apr 3, 2011 at 12:46 PM, Matt Sealey wrote:
> At the point where device tree specification and maintenance is done
> in-kernel, device trees get very Linux-specific and very
> Linux-driver-specific. Plenty of mistakes were made in the move to
> flattened device trees on PowerPC which took
On 04/03/2011 05:46 PM, Somebody in the thread at some point said:
As long as the experience is driven by both the SoC vendor and the
board designer and not the kernel driver engineer, this will go very
well..
At the point where device tree specification and maintenance is done
in-kernel, device
As long as the experience is driven by both the SoC vendor and the
board designer and not the kernel driver engineer, this will go very
well..
At the point where device tree specification and maintenance is done
in-kernel, device trees get very Linux-specific and very
Linux-driver-specific. Plenty
On 04/03/2011 05:05 PM, Somebody in the thread at some point said:
Above everything else, I definitely like to see DT get done first,
it's essential for SoC these days.
All I am suggesting is bind the DTs in the kernel. That's easier and
faster than the alternatives and there is a lot less t
On 04/03/2011 04:25 PM, Somebody in the thread at some point said:
Hi -
Think of the DT as a way of probing a bus that doesn't have probe
capabilities. This gives you a way to dynamically load drivers from
initrd if you want. For example we dynamically loaded drivers for I2C
devices that were p
On Sun, Apr 3, 2011 at 10:25 AM, jonsm...@gmail.com wrote:
> On Sun, Apr 3, 2011 at 4:38 AM, Andy Green wrote:
>> On 04/03/2011 04:07 AM, Somebody in the thread at some point said:
>>
>> Hi -
>>
* And very hardware specific code moved out to a controllable place,
i.e. something li
On Sun, Apr 3, 2011 at 4:38 AM, Andy Green wrote:
> On 04/03/2011 04:07 AM, Somebody in the thread at some point said:
>
> Hi -
>
>>> * And very hardware specific code moved out to a controllable place,
>>> i.e. something like BIOS
>>
>> Sorry, but I must vehemently disagree here. BIOSes ar
On 04/03/2011 04:07 AM, Somebody in the thread at some point said:
Hi -
* And very hardware specific code moved out to a controllable place,
i.e. something like BIOS
Sorry, but I must vehemently disagree here. BIOSes are a problem for
Open Source, not a solution. On X86 they use BIO
On Sat, 2 Apr 2011, Eric Miao wrote:
> On Sat, Apr 2, 2011 at 6:05 AM, Nicolas Pitre
> wrote:
> > On Sat, 2 Apr 2011, Eric Miao wrote:
> >
> >> Yeah, staging is more close to what I meant, a 'fork' is not appropriate
> >> here,
> >> as getting the support into mainline will always be our goal.
On Sat, Apr 2, 2011 at 12:46 PM, Eric Miao wrote:
> On Sat, Apr 2, 2011 at 6:05 AM, Nicolas Pitre
> wrote:
>> On Sat, 2 Apr 2011, Eric Miao wrote:
>>
>>> Yeah, staging is more close to what I meant, a 'fork' is not appropriate
>>> here,
>>> as getting the support into mainline will always be ou
On Sat, Apr 2, 2011 at 6:05 AM, Nicolas Pitre wrote:
> On Sat, 2 Apr 2011, Eric Miao wrote:
>
>> Yeah, staging is more close to what I meant, a 'fork' is not appropriate
>> here,
>> as getting the support into mainline will always be our goal. Yet there seems
>> to be necessary to have such a tem
On Sat, 2 Apr 2011, Eric Miao wrote:
> Yeah, staging is more close to what I meant, a 'fork' is not appropriate here,
> as getting the support into mainline will always be our goal. Yet there seems
> to be necessary to have such a temporary place for those patches to live
> before the mainline is
On Fri, Apr 1, 2011 at 11:57 PM, Philippe Robin wrote:
> Eric,
>
>>> So maybe it's just a right time to talk about using linaro ARM kernel
>>> tree as a fork for quick merge of the ever expanding SoC and board
>>> support, and using it more as a productive kernel for downstream.
>
> I don't think
On Fri, Apr 1, 2011 at 11:55 PM, David Rusling wrote:
> Eric,
> yes, I found that interesting. I've been having discussions about how
> to do this better, I'm interested in your thoughts. Are you by any
> chance at ELC in SF?
Actually a bit busy with the involvement with Freescale, so
Eric,
>> So maybe it's just a right time to talk about using linaro ARM kernel
>> tree as a fork for quick merge of the ever expanding SoC and board
>> support, and using it more as a productive kernel for downstream.
I don't think that a 'fork' is really a solution we are looking for. Using
Lina
Eric,
yes, I found that interesting. I've been having discussions about how
to do this better, I'm interested in your thoughts. Are you by any
chance at ELC in SF?
Dave
On Fri, 2011-04-01 at 23:43 +0800, Eric Miao wrote:
> Just FYI - lengthy but very interesting read, Linus was rea
32 matches
Mail list logo
