On 18/03/2015 12:54 am, Daniel Hellstrom wrote:
On 03/15/2015 10:29 PM, Chris Johns wrote:
On 14/03/2015 12:39 pm, Amar Takhar wrote:
On 11/03/2015 1:27 am, Karel Gardas wrote:
Yes, this is a big patch but if you do not merge it now and later
following waf work you do tree/file placement refac
On 03/15/2015 10:29 PM, Chris Johns wrote:
On 14/03/2015 12:39 pm, Amar Takhar wrote:
On 11/03/2015 1:27 am, Karel Gardas wrote:
Yes, this is a big patch but if you do not merge it now and later
following waf work you do tree/file placement refactoring than the patch
would be even harder to mer
On 14/03/2015 12:39 pm, Amar Takhar wrote:
On 11/03/2015 1:27 am, Karel Gardas wrote:
Yes, this is a big patch but if you do not merge it now and later
following waf work you do tree/file placement refactoring than the patch
would be even harder to merge.
I was thinking this would land in 4.12
> On 11/03/2015 1:27 am, Karel Gardas wrote:
> > Yes, this is a big patch but if you do not merge it now and later
> > following waf work you do tree/file placement refactoring than the patch
> > would be even harder to merge.
I was thinking this would land in 4.12 then waf would be based off of t
On 11/03/2015 1:27 am, Karel Gardas wrote:
On 03/ 9/15 08:31 PM, Amar Takhar wrote:
On 2015-03-09 14:23 -0400, Gedare Bloom wrote:
We are close to branching 4.11, but I think there may be value in
merging the patch set for 4.11. Would it be acceptable to all if we
I would be against this.
On 03/ 9/15 08:31 PM, Amar Takhar wrote:
On 2015-03-09 14:23 -0400, Gedare Bloom wrote:
We are close to branching 4.11, but I think there may be value in
merging the patch set for 4.11. Would it be acceptable to all if we
I would be against this. The patch is too large to land just before we
On 2015-03-09 14:23 -0400, Gedare Bloom wrote:
> We are close to branching 4.11, but I think there may be value in
> merging the patch set for 4.11. Would it be acceptable to all if we
I would be against this. The patch is too large to land just before we cut
4.11. With the new waf build syste
On Fri, Feb 27, 2015 at 3:42 AM, Daniel Hellstrom wrote:
> On 02/26/2015 05:58 PM, Gedare Bloom wrote:
>>
>> On Thu, Feb 26, 2015 at 11:38 AM, Daniel Hellstrom
>> wrote:
>>>
>>> Hi,
>>>
>>> I have rebased and tested briefly the RTEMS code that we have used on
>>> LEON2/3/4
>>> on RTEMS-4.10 durin
On 26/02/15 18:01, Gedare Bloom wrote:
TODO:
> * tests.
> * port documentation from RCC manuals to RTEMS doc/ directory.
> * redesign/simplify the driver registration configuration in
drvmgr_confdefs.h.
> * a generic bus driver to support a hardcoded setup that can be used for
>most s
On 02/26/2015 05:58 PM, Gedare Bloom wrote:
On Thu, Feb 26, 2015 at 11:38 AM, Daniel Hellstrom wrote:
Hi,
I have rebased and tested briefly the RTEMS code that we have used on LEON2/3/4
on RTEMS-4.10 during the last couple of years. A couple of years ago most stuff
that did not depend on the P
On Thu, Feb 26, 2015 at 11:38 AM, Daniel Hellstrom wrote:
> Hi,
>
> I have rebased and tested briefly the RTEMS code that we have used on
> LEON2/3/4
> on RTEMS-4.10 during the last couple of years. A couple of years ago most
> stuff
> that did not depend on the PCI and Driver Manager layers wer
Hi,
I have rebased and tested briefly the RTEMS code that we have used on LEON2/3/4
on RTEMS-4.10 during the last couple of years. A couple of years ago most stuff
that did not depend on the PCI and Driver Manager layers were submitted so most
patches are SPARC BSP specific this time. GCC-4.9 comp
12 matches
Mail list logo
