On 27/03/18 01:15, Chris Johns wrote:
On 26/03/2018 17:32, Sebastian Huber wrote:
On 25/03/18 05:20, Chris Johns wrote:
On 24/3/18 1:27 am, Sebastian Huber wrote:
Hello,
I tried to consolidate the cpukit Makefile.am. This ended up in the following
problem. The content of librtemscpu.a depends
-- Forwarded message -
From: 'Stephanie' via Google Summer of Code Discuss <
google-summer-of-code-disc...@googlegroups.com>
Date: Mon, Mar 26, 2018, 10:21 PM
Subject: Final Hours for Students to submit their Final PDF Proposal and
Proof of Enrollment for 2018
To: Google Summer of C
On 26/03/2018 17:32, Sebastian Huber wrote:
> On 25/03/18 05:20, Chris Johns wrote:
>> On 24/3/18 1:27 am, Sebastian Huber wrote:
>>> Hello,
>>>
>>> I tried to consolidate the cpukit Makefile.am. This ended up in the
>>> following
>>> problem. The content of librtemscpu.a depends on the CPU port.
Great job and effort!
On Mon, Mar 26, 2018 at 9:39 AM, Sebastian Huber
wrote:
> Hello,
>
> I finished the libcpu removal today.
>
> https://devel.rtems.org/ticket/3285
>
> Now, all BSP-specific objects for librtemsbsp.a are defined by the BSP's
> Makefile.am without the need for *.rel objects. Pl
mcpu32p is also referenced by rtems/score/m68k.h. I think the
paragraph it is used in is obsolete.
--joel
On Mon, Mar 26, 2018 at 8:33 AM, Sebastian Huber wrote:
> Module:rtems
> Branch:master
> Commit:1e23c47911bb4fec5a2c6fb9c1a4355721f76acb
> Changeset: http://git.rtems.org/rtem
Hello,
I finished the libcpu removal today.
https://devel.rtems.org/ticket/3285
Now, all BSP-specific objects for librtemsbsp.a are defined by the BSP's
Makefile.am without the need for *.rel objects. Please test your
favourite BSP if it still works.
--
Sebastian Huber, embedded brains GmbH
Hello Chris,
I took the liberty to rebase the patches to the latest master. See the
two following v3 mails. I'll take a look at the configuration based on
these patches.
I think that you wanted to make i386 tests. After that it might would be
a good idea to commit them. What do you think?
Best r
Hello Developers
This is link to my proposal
https://docs.google.com/document/d/15aUQShwRzIOQQoNAGV9jjeJ1Q2CHLcv_icamEqrTORE/edit?ts=5ab23139
As deadline is tomorrow so can you please review it for the last time and
if needed suggest me the changes.
Thanks & regards,
Salil Sirotia,
_
Am 26.03.2018 um 13:45 schrieb Chris Johns:
> On 26/3/18 9:08 pm, Christian Mauderer wrote:
>> Hello Chris,
>>
>> thanks for that great support for #3351. Like I already said there, I
>> started to work on something similar on Friday. But your solution is
>> quite a bit advanced compared to mine on
hi!
> I think we should define some basic functionality which should be
available ready to use during mid term evaluation. I want to avoid a last
minute delivery during the project end with no time to fix problems after a
review. This likely results in some half-finished work which nobody can use.
On 26/3/18 9:08 pm, Christian Mauderer wrote:
Hello Chris,
thanks for that great support for #3351. Like I already said there, I
started to work on something similar on Friday. But your solution is
quite a bit advanced compared to mine one. I haven't started to move any
configuration yet.
I ho
Hello Chris,
thanks for that great support for #3351. Like I already said there, I
started to work on something similar on Friday. But your solution is
quite a bit advanced compared to mine one. I haven't started to move any
configuration yet.
This patches will make it a lot easier to understand
Brilliant, I think that resolves it all. Let me know if you have any other
questions I may have missed or anything is unclear, though!
My next steps are:
- Get my QEMU environment setup with OVMF and document it on the wiki
- Continue to read Intel's manual on system programming (volume 3)
- Read
13 matches
Mail list logo
