Hi.
On 12.05.2013 15:57, KP Kirchdoerfer wrote:
> Hi Andrew;
>
> well done - a first test compiles and builded image boots.
>
> I have to confess, I do not understand your thoughts below :)
> Instead a few comments/questions:
>
> 1) I saw that there is a new buildtool.pl option ("buildtool.pl
> he
Hi Andrew;
well done - a first test compiles and builded image boots.
I have to confess, I do not understand your thoughts below :)
Instead a few comments/questions:
1) I saw that there is a new buildtool.pl option ("buildtool.pl
headers"), but it's not mentioned if I run "buildtool.pl help". Al
Done, distro is still compiled (I'll try to run it when compilation will
be finished), but it seems like all is OK.
I added target 'headers' to build linux headers for platform (this is
development thing), and it looks like there are a lot of redundant code.
Also target plugins loading can be si
Hi Andrew;
Am 29.04.2013 14:21, schrieb Andrew:
> Hi.
> It looks like there will be a three steps that I described, except order
> - 2nd and 1st step should be exchanged. So 1) add linux headers (and
> look if headers for different archs differs - AFAIK some of headers will
> be different); 2)
Hi.
It looks like there will be a three steps that I described, except order
- 2nd and 1st step should be exchanged. So 1) add linux headers (and
look if headers for different archs differs - AFAIK some of headers will
be different); 2) add separate targets and 3) add choose for target
kernel (
On 04/28/2013 04:16 PM, KP Kirchdoerfer wrote:
> Hi Andrew;
>
> is there a possibilty to divide the proposal below in two or more steps,
> so we can test, work with and get more experienced?
>
> Like 1) add three targets, including cleaning each target (and it's
> dependencies) 2) add building dif
Hi Andrew;
is there a possibilty to divide the proposal below in two or more steps,
so we can test, work with and get more experienced?
Like 1) add three targets, including cleaning each target (and it's
dependencies) 2) add building different kernel and modules
kp
Am 23.04.2013 21:59, schri
On 24.04.2013 20:28, KP Kirchdoerfer wrote:
> Am 24.04.2013 19:00, schrieb Andrew:
>> 24.04.2013 19:10, KP Kirchdoerfer пишет:
>>> Hi Andrew;
>>>
>>> I like the idea, but the toolchain is AFAIK related to the architecture
>>> (see uClibc config), so we will still need one toolchain for each
>>> arc
Am 24.04.2013 19:00, schrieb Andrew:
> 24.04.2013 19:10, KP Kirchdoerfer пишет:
>> Hi Andrew;
>>
>> I like the idea, but the toolchain is AFAIK related to the architecture
>> (see uClibc config), so we will still need one toolchain for each
>> architecture, am I wrong?
> Right, toolchain is depende
24.04.2013 19:10, KP Kirchdoerfer пишет:
> Hi Andrew;
>
> I like the idea, but the toolchain is AFAIK related to the architecture
> (see uClibc config), so we will still need one toolchain for each
> architecture, am I wrong?
Right, toolchain is dependent from architecture (for ex., ARMv5, ARMv6
a
KP
Am 24.04.2013 16:10, schrieb KP Kirchdoerfer:
> Hi Andrew;
>
> I like the idea, but the toolchain is AFAIK related to the architecture
> (see uClibc config), so we will still need one toolchain for each
> architecture, am I wrong?
Maybe the link to the architecture dependent libraries can be b
Hi Andrew;
I like the idea, but the toolchain is AFAIK related to the architecture
(see uClibc config), so we will still need one toolchain for each
architecture, am I wrong?
Am 23.04.2013 21:59, schrieb Andrew:
> Hi all.
>
> Now we have building of toolchain, userlevel apps and kernel (with
>
Hi all.
Now we have building of toolchain, userlevel apps and kernel (with
modules) as similar targets, with same logic. But for future embedded
platforms with same/similar CPU arch (but with multiple kernels - for
each SoC required separate kernel, possible even with different versions
- like
13 matches
Mail list logo
