Am 13.07.2017 um 04:33 schrieb Chris Johns:
> On 13/07/2017 12:22, Sichen Zhao wrote:
>> 在 2017年07月12日 21:52, Gedare Bloom 写道:
>>> On Tue, Jul 11, 2017 at 6:51 AM, Sichen Zhao <1473996...@qq.com> wrote:
+These files are imported from FreeBSD.
+These files is licensed under the terms of
The patches are all right, but I was not able to apply them:
Applying: Import am335x usb driver file from FreeBSD.
.git/rebase-apply/patch:1266: trailing whitespace.
* For now set frequency to 2*VGA_PIXEL_CLOCK
.git/rebase-apply/patch:1510: trailing whitespace.
On 13/07/2017 12:22, Sichen Zhao wrote:
> 在 2017年07月12日 21:52, Gedare Bloom 写道:
>> On Tue, Jul 11, 2017 at 6:51 AM, Sichen Zhao <1473996...@qq.com> wrote:
>>> +These files are imported from FreeBSD.
>>> +These files is licensed under the terms of the GNU General Public License
>>> * version 2.
>>
Add FDT and umass support for am335x USB driver.
Now RTEMS can mount and open USB disk.
---
freebsd/sys/arm/ti/am335x/am335x_prcm.c | 2 ++
freebsd/sys/arm/ti/ti_cpuid.h | 19 +
libbsd.py | 34
在 2017年07月12日 21:52, Gedare Bloom 写道:
> On Tue, Jul 11, 2017 at 6:51 AM, Sichen Zhao <1473996...@qq.com> wrote:
>> These dts files import from FreeBSD, git link:
>> https://github.com/freebsd/freebsd/tree/master/sys/gnu/dts
>>
>> The license for these files in beagle/simscripts
>> ---
>>
On Wed, Jul 12, 2017 at 12:13 PM, Cillian O'Donnell
wrote:
> I just want to give an update to my understanding of this problem as
> I'm not sure I was clear enough in the IRC meeting. We ended up
> talking about nops but I think the problem is something else.
>
> So when
I just want to give an update to my understanding of this problem as
I'm not sure I was clear enough in the IRC meeting. We ended up
talking about nops but I think the problem is something else.
So when there is a successful covoar run, it will generate a report
but also finish with this message.
On Wed, Jul 12, 2017 at 1:36 AM, Sebastian Huber
wrote:
> On 11/07/17 16:59, Gedare Bloom wrote:
>
>>> +rtems_status_code rtems_scheduler_ident_by_processor_set(
>>> + size_t cpusetsize,
>>> + const cpu_set_t *cpuset,
>>> + rtems_id*id
>>>
Patch1 and 2 is not needed, but it fix a bug about the multiple resource. So
they can be useful anyway.
Best Regards
Sichen Zhao
From: devel on behalf of Sebastian Huber
Sent: Wednesday,
Ok, thanks.
Best Regards
Sichen Zhao
From: devel on behalf of Sebastian Huber
Sent: Wednesday, July 12, 2017 2:40:28 PM
To: Sichen Zhao; devel@rtems.org
Cc: punitv...@gmail.com;
Please merge with patch 4.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine
On 11/07/17 12:53, Sichen Zhao wrote:
+#ifndef __rtems__
#include
+#endif /* __rtems__ */
https://github.com/RTEMS/rtems-libbsd/blob/master/CONTRIBUTING.md
"In general, provide empty header files and do not guard includes."
Each #if __rtems__ makes it harder to stay in synchronization
Is patch 1 and 2 still needed for the later patches? If not, then please
drop them.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP :
Please merge with patch 5.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine
I checked in a slightly modified version:
http://git.rtems.org/rtems/commit/?id=f6115d7cd2d1551a05cd257ac9f00476c61e5e0d
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail :
On 12/07/17 08:06, Chris Johns wrote:
On 12/07/2017 15:35, Sebastian Huber wrote:
On 11/07/17 17:06, Gedare Bloom wrote:
Is there a reason someone might have to not want one server per core
when using SMP? That is, should this be configurable?
Yes, this should be configurable. One option is
On 12/07/2017 15:35, Sebastian Huber wrote:
> On 11/07/17 17:06, Gedare Bloom wrote:
>
>> Is there a reason someone might have to not want one server per core
>> when using SMP? That is, should this be configurable?
>
> Yes, this should be configurable. One option is to add an alternative
>
17 matches
Mail list logo