Re: [PATCH 2/6] Modify the support for multiple memory resources.
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, July 12, 2017 14:42 To: Sichen Zhao; devel@rtems.org Cc: punitv...@gmail.com; christian.maude...@embedded-brains.de Subject: Re: [PATCH 2/6] Modify the support for multiple memory resources. 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 : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 2/7] rtems: Add rtems_scheduler_ident_by_processor_set
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 >>> +); >>> + >> >> Also needs doc. I wonder if "identify" or "id" may be better. "ident" >> seems a bit unusual. >> > > All the object identification by name operations use rtems_class_ident(). > So, I made it rtems_class_ident_by_x(). > You're right, that is good. > -- > 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 geschäftliche Mitteilung im Sinne des EHUG. > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 2/2] Add dts file to generate dtb binary file for Beaglebone black.
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 > --- > c/src/lib/libbsp/arm/beagle/README | 11 + > c/src/lib/libbsp/arm/beagle/simscripts/LICENSE |2 + > .../arm/beagle/simscripts/am335x-bone-common.dtsi | 417 > .../beagle/simscripts/am335x-boneblack-common.dtsi | 163 > .../arm/beagle/simscripts/am335x-boneblack.dts | 28 + > .../arm/beagle/simscripts/am33xx-clocks.dtsi | 646 + > c/src/lib/libbsp/arm/beagle/simscripts/am33xx.dtsi | 1011 > > .../simscripts/dt-bindings/display/tda998x.h |7 + > .../arm/beagle/simscripts/dt-bindings/gpio/gpio.h | 31 + > .../beagle/simscripts/dt-bindings/pinctrl/am33xx.h | 43 + > .../beagle/simscripts/dt-bindings/pinctrl/omap.h | 90 ++ > c/src/lib/libbsp/arm/beagle/simscripts/sdcard.sh | 10 +- > .../lib/libbsp/arm/beagle/simscripts/tps65217.dtsi | 68 ++ > 13 files changed, 2525 insertions(+), 2 deletions(-) > create mode 100644 c/src/lib/libbsp/arm/beagle/simscripts/LICENSE > create mode 100644 > c/src/lib/libbsp/arm/beagle/simscripts/am335x-bone-common.dtsi > create mode 100644 > c/src/lib/libbsp/arm/beagle/simscripts/am335x-boneblack-common.dtsi > create mode 100644 > c/src/lib/libbsp/arm/beagle/simscripts/am335x-boneblack.dts > create mode 100644 c/src/lib/libbsp/arm/beagle/simscripts/am33xx-clocks.dtsi > create mode 100644 c/src/lib/libbsp/arm/beagle/simscripts/am33xx.dtsi > create mode 100644 > c/src/lib/libbsp/arm/beagle/simscripts/dt-bindings/display/tda998x.h > create mode 100644 > c/src/lib/libbsp/arm/beagle/simscripts/dt-bindings/gpio/gpio.h > create mode 100644 > c/src/lib/libbsp/arm/beagle/simscripts/dt-bindings/pinctrl/am33xx.h > create mode 100644 > c/src/lib/libbsp/arm/beagle/simscripts/dt-bindings/pinctrl/omap.h > create mode 100644 c/src/lib/libbsp/arm/beagle/simscripts/tps65217.dtsi > > diff --git a/c/src/lib/libbsp/arm/beagle/README > b/c/src/lib/libbsp/arm/beagle/README > index e558287..2ed9393 100644 > --- a/c/src/lib/libbsp/arm/beagle/README > +++ b/c/src/lib/libbsp/arm/beagle/README > @@ -93,6 +93,17 @@ uboot# bootm 0x8080 > There is a script here that automatically writes an SD card for any of > the beagle targets. > > +Before using the script, you need DTC(device tree compiler) tool to > +compile dts to dtb file. So you need add this tool in RSB bset file. > + > +These dts and dtsi files are licensed under the terms of the GNU > +General Public License * version 2. > + > +For example, to add dtc tool in rtems-arm.bset, you need include > +dtc.bset in rtems-arm.bset. > + > +%include devel/dtc.bset > + > Let's write one for the Beaglebone Black. Assuming your source tree is > at $HOME/development/rtems/rtems-src and your bsp is built and linked > with examples and installed at $HOME/development/rtems/4.11. > diff --git a/c/src/lib/libbsp/arm/beagle/simscripts/LICENSE > b/c/src/lib/libbsp/arm/beagle/simscripts/LICENSE > new file mode 100644 > index 000..587a3dd > --- /dev/null > +++ b/c/src/lib/libbsp/arm/beagle/simscripts/LICENSE > @@ -0,0 +1,2 @@ > +These files are imported from FreeBSD. > +These files is licensed under the terms of the GNU General Public License * > version 2. We should not pollute the RTEMS sources with GPL2 code. Is there an alternative approach to use? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Trace Block Inconsistent with Coverage Map
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.
*** Trace block is inconsistent with coverage map
*** Trace block (0x4000c2cc - 0x4000c2ec) for 36 bytes
*** Coverage map /home/cpod/coverage_test/leon3/coverage/base_sp.exe.cov
-
The coverage map is 24 bytes:
(gdb) p/x *entry
$2 = {pc = 0x4000c2cc, size = 0x24, op = 0x12}
-
The disassembly block in question is:
4000c2cc <_Objects_Get_information_id>:
4000c2cc: 83 32 20 18 srl %o0, 0x18, %g1
Objects_Information *_Objects_Get_information_id(
Objects_Id id
)
{
return _Objects_Get_information(
4000c2d0: 93 32 20 1b srl %o0, 0x1b, %o1
4000c2d4: 90 08 60 07 and %g1, 7, %o0
4000c2d8: 82 13 c0 00 mov %o7, %g1
4000c2dc: 40 00 00 02 call 4000c2e4 <_Objects_Get_information>
4000c2e0: 9e 10 40 00 mov %g1, %o7
4000c2e4 <_Objects_Get_information>:
Objects_Information *_Objects_Get_information(
Objects_APIs the_api,
uint16_t the_class
)
{
4000c2e4: 9d e3 bf a0 save %sp, -96, %sp
Objects_Information *info;
int the_class_api_maximum;
if ( !the_class )
4000c2e8: 80 a6 60 00 cmp %i1, 0
4000c2ec: 02 80 00 19 be 4000c350 <_Objects_Get_information+0x6c>
4000c2f0: 01 00 00 00 nop
I have checked this out on base_sp.exe and ticker.exe where the same
inconsistency appears in both. Couverture-QEMU decides the trace block
encompasses that entire block
Whereas from the covoar side the objdump is always processed line by
line and a regex is checked to determine what kind of line it is.
408 items = sscanf(
409 inputBuffer,
410 "%x <%[^>]>%c",
411 &offset, symbol, &terminator1
412 );
If there is a match for all 3 items then this is a new function
415 if ((items == 3) && (terminator1 == ':')) {
416
417 endAddress = executableInformation->getLoadAddress() + offset - 1;
So the objdump above is always processed as 2 seperate sections.
One for:
4000c2cc <_Objects_Get_information_id>:
And one for:
4000c2e4 <_Objects_Get_information>:
The size from Objects_Get_information_id to Objects_Get_information is
24 bytes which is the coverage map.
The size of both functions combined is 36 bytes which is the
Couverture trace block.
Couverture could possibly be doing something more sophisticated to
determine the end of the block or it could just be wrong. So the next
thing I'm doing is figuring out exactly how Couverture is processing
this.
For both cases the trace op code is 0x12 which means 'Branch fully
executed' and 'Branch not taken'. I'm trying to find one with op code
0x11 which would mean the 'branch is taken' and possibly it might be
processed differently in this case. The only place both these
functions appear in the source is libtests/dl04 and dl05. I'm checking
those out at the moment.
Thanks,
Cillian.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Trace Block Inconsistent with Coverage Map
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 there is a successful covoar run, it will generate a report
> but also finish with this message.
>
> *** Trace block is inconsistent with coverage map
> *** Trace block (0x4000c2cc - 0x4000c2ec) for 36 bytes
> *** Coverage map /home/cpod/coverage_test/leon3/coverage/base_sp.exe.cov
>
> -
>
> The coverage map is 24 bytes:
>
> (gdb) p/x *entry
> $2 = {pc = 0x4000c2cc, size = 0x24, op = 0x12}
>
> -
>
> The disassembly block in question is:
>
> 4000c2cc <_Objects_Get_information_id>:
> 4000c2cc: 83 32 20 18 srl %o0, 0x18, %g1
>
> Objects_Information *_Objects_Get_information_id(
> Objects_Id id
> )
> {
> return _Objects_Get_information(
> 4000c2d0: 93 32 20 1b srl %o0, 0x1b, %o1
> 4000c2d4: 90 08 60 07 and %g1, 7, %o0
> 4000c2d8: 82 13 c0 00 mov %o7, %g1
> 4000c2dc: 40 00 00 02 call 4000c2e4 <_Objects_Get_information>
> 4000c2e0: 9e 10 40 00 mov %g1, %o7
>
> 4000c2e4 <_Objects_Get_information>:
>
> Objects_Information *_Objects_Get_information(
> Objects_APIs the_api,
> uint16_t the_class
> )
> {
> 4000c2e4: 9d e3 bf a0 save %sp, -96, %sp
> Objects_Information *info;
> int the_class_api_maximum;
>
> if ( !the_class )
> 4000c2e8: 80 a6 60 00 cmp %i1, 0
> 4000c2ec: 02 80 00 19 be 4000c350 <_Objects_Get_information+0x6c>
> 4000c2f0: 01 00 00 00 nop
>
>
>
> I have checked this out on base_sp.exe and ticker.exe where the same
> inconsistency appears in both. Couverture-QEMU decides the trace block
> encompasses that entire block
>
> Whereas from the covoar side the objdump is always processed line by
> line and a regex is checked to determine what kind of line it is.
>
> 408 items = sscanf(
> 409 inputBuffer,
> 410 "%x <%[^>]>%c",
> 411 &offset, symbol, &terminator1
> 412 );
>
> If there is a match for all 3 items then this is a new function
>
> 415 if ((items == 3) && (terminator1 == ':')) {
> 416
> 417 endAddress = executableInformation->getLoadAddress() + offset
> - 1;
>
>
> So the objdump above is always processed as 2 seperate sections.
>
> One for:
> 4000c2cc <_Objects_Get_information_id>:
>
>
> And one for:
> 4000c2e4 <_Objects_Get_information>:
>
> The size from Objects_Get_information_id to Objects_Get_information is
> 24 bytes which is the coverage map.
> The size of both functions combined is 36 bytes which is the
> Couverture trace block.
>
OK. I think I finally understand enough to believe that covoar is at fault
here.
It is complicated because of the multiple pieces in action but you have
given plenty of information. Let's see if I can explain how the different
sources of data are (incorrectly) being thought to not match up.
First, it is not about having a varying amount of padding at the end
of a method so the next method is on a cache-aligned boundary.
Qemu traces reflect that qemu executes "translation blocks" of code.
Each block is up to a point of potential change of execution flow. This
means they should always end with a call, return from subroutine,
branch, trap, etc.
Internally, covoar processes methods which have C statements and
assembly statements. Each method can have "ranges" of covered and
uncovered code. That's the basis for the reports at the end.
The trace reader for qemu is getting confused trying to interpret
the branch information. It is assuming that the branch is the
last instruction in the range in aCoverageMap.
For some unknown reason, the trace reader class appears to be
checking that the couverture trace record precisely matches the
size of the associated uncovered range. I don't think it always can.
It probably is always <= size of the code in aCoverageMap.
CoverageMapBase.cc has a "dump()" method to assist in debugging.
I think the math for associating the branch information is wrong.
It should compute the address of the branch instruction, verify
it is the start of an instruction, that it is a branch, and then set
was taken or was not taken.
Well..crap.. the output variables offset_t and offset_e from the calls
being checked on the if:
are not even being used.
if ((aCoverageMap->determineOffset( a, &offset_a ) != true) ||
(aCoverageMap->determineOffset( entry->pc, &offset_e ) !=
true))
{
Disable the if and check if things look better.
In other words, just assume that it is consistent. We have already looped
through the "aCoverageMap" and set was executed in the loop around
135.
>
> Couverture could possibly be doing something more sophisticated to
> determine the end of the block or it could just be wrong. So the next
> t
Re: [PATCH v2 2/2] Add dts file to generate dtb binary file for Beaglebone black.
在 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 >> --- >> c/src/lib/libbsp/arm/beagle/README | 11 + >> c/src/lib/libbsp/arm/beagle/simscripts/LICENSE |2 + >> .../arm/beagle/simscripts/am335x-bone-common.dtsi | 417 >> .../beagle/simscripts/am335x-boneblack-common.dtsi | 163 >> .../arm/beagle/simscripts/am335x-boneblack.dts | 28 + >> .../arm/beagle/simscripts/am33xx-clocks.dtsi | 646 + >> c/src/lib/libbsp/arm/beagle/simscripts/am33xx.dtsi | 1011 >> >> .../simscripts/dt-bindings/display/tda998x.h |7 + >> .../arm/beagle/simscripts/dt-bindings/gpio/gpio.h | 31 + >> .../beagle/simscripts/dt-bindings/pinctrl/am33xx.h | 43 + >> .../beagle/simscripts/dt-bindings/pinctrl/omap.h | 90 ++ >> c/src/lib/libbsp/arm/beagle/simscripts/sdcard.sh | 10 +- >> .../lib/libbsp/arm/beagle/simscripts/tps65217.dtsi | 68 ++ >> 13 files changed, 2525 insertions(+), 2 deletions(-) >> create mode 100644 c/src/lib/libbsp/arm/beagle/simscripts/LICENSE >> create mode 100644 >> c/src/lib/libbsp/arm/beagle/simscripts/am335x-bone-common.dtsi >> create mode 100644 >> c/src/lib/libbsp/arm/beagle/simscripts/am335x-boneblack-common.dtsi >> create mode 100644 >> c/src/lib/libbsp/arm/beagle/simscripts/am335x-boneblack.dts >> create mode 100644 >> c/src/lib/libbsp/arm/beagle/simscripts/am33xx-clocks.dtsi >> create mode 100644 c/src/lib/libbsp/arm/beagle/simscripts/am33xx.dtsi >> create mode 100644 >> c/src/lib/libbsp/arm/beagle/simscripts/dt-bindings/display/tda998x.h >> create mode 100644 >> c/src/lib/libbsp/arm/beagle/simscripts/dt-bindings/gpio/gpio.h >> create mode 100644 >> c/src/lib/libbsp/arm/beagle/simscripts/dt-bindings/pinctrl/am33xx.h >> create mode 100644 >> c/src/lib/libbsp/arm/beagle/simscripts/dt-bindings/pinctrl/omap.h >> create mode 100644 c/src/lib/libbsp/arm/beagle/simscripts/tps65217.dtsi >> >> diff --git a/c/src/lib/libbsp/arm/beagle/README >> b/c/src/lib/libbsp/arm/beagle/README >> index e558287..2ed9393 100644 >> --- a/c/src/lib/libbsp/arm/beagle/README >> +++ b/c/src/lib/libbsp/arm/beagle/README >> @@ -93,6 +93,17 @@ uboot# bootm 0x8080 >> There is a script here that automatically writes an SD card for any of >> the beagle targets. >> >> +Before using the script, you need DTC(device tree compiler) tool to >> +compile dts to dtb file. So you need add this tool in RSB bset file. >> + >> +These dts and dtsi files are licensed under the terms of the GNU >> +General Public License * version 2. >> + >> +For example, to add dtc tool in rtems-arm.bset, you need include >> +dtc.bset in rtems-arm.bset. >> + >> +%include devel/dtc.bset >> + >> Let's write one for the Beaglebone Black. Assuming your source tree is >> at $HOME/development/rtems/rtems-src and your bsp is built and linked >> with examples and installed at $HOME/development/rtems/4.11. >> diff --git a/c/src/lib/libbsp/arm/beagle/simscripts/LICENSE >> b/c/src/lib/libbsp/arm/beagle/simscripts/LICENSE >> new file mode 100644 >> index 000..587a3dd >> --- /dev/null >> +++ b/c/src/lib/libbsp/arm/beagle/simscripts/LICENSE >> @@ -0,0 +1,2 @@ >> +These files are imported from FreeBSD. >> +These files is licensed under the terms of the GNU General Public License * >> version 2. > We should not pollute the RTEMS sources with GPL2 code. Is there an > alternative approach to use? The another way is to directly use dtb binary file, but bin file also has a gpl2 license. So this way is not acceptable. Gedare said the scripts directory may be appropriate for rtems-tools.git or something. So i can provide a default one that can be used, it may be downloadable from somewhere e.g. in rtems-tools or from a FTP. And this is the way to keep GPL code from RTEMS sources. What do you think about? > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2 2/2] Port am335x usb driver to RTEMS.
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 +++
libbsd_waf.py | 6
rtemsbsd/include/bsp/nexus-devices.h | 14 ++
rtemsbsd/include/machine/intr.h | 0
rtemsbsd/include/rtems/bsd/local/fdt_pinctrl_if.h | 0
7 files changed, 75 insertions(+)
create mode 100644 rtemsbsd/include/machine/intr.h
create mode 100644 rtemsbsd/include/rtems/bsd/local/fdt_pinctrl_if.h
diff --git a/freebsd/sys/arm/ti/am335x/am335x_prcm.c
b/freebsd/sys/arm/ti/am335x/am335x_prcm.c
index 1d10f7f..a05647d 100644
--- a/freebsd/sys/arm/ti/am335x/am335x_prcm.c
+++ b/freebsd/sys/arm/ti/am335x/am335x_prcm.c
@@ -438,7 +438,9 @@ am335x_prcm_attach(device_t dev)
sc->bsh = rman_get_bushandle(sc->res[0]);
am335x_prcm_sc = sc;
+#ifndef __rtems__
ti_cpu_reset = am335x_prcm_reset;
+#endif /* __rtems__ */
if (am335x_clk_get_sysclk_freq(NULL, &sysclk) != 0)
sysclk = 0;
diff --git a/freebsd/sys/arm/ti/ti_cpuid.h b/freebsd/sys/arm/ti/ti_cpuid.h
index 715f080..213714b 100644
--- a/freebsd/sys/arm/ti/ti_cpuid.h
+++ b/freebsd/sys/arm/ti/ti_cpuid.h
@@ -29,6 +29,9 @@
#ifndef _TI_CPUID_H_
#define_TI_CPUID_H_
+#ifdef __rtems__
+#include
+#endif /* __rtems__ */
#defineOMAP_MAKEREV(d, a, b, c) \
(uint32_t)(((d) << 16) | (((a) & 0xf) << 8) | (((b) & 0xf) << 4) | ((c)
& 0xf))
@@ -70,7 +73,23 @@
#defineCHIP_OMAP_4 0
#defineCHIP_AM335X 1
+#ifdef __rtems__
+#ifdef IS_AM335X
+#define SOC_TI_AM335X
+#else
+#warning Unknown SOC.
+#endif
+
+#if defined(SOC_TI_AM335X)
+#define _ti_chip CHIP_AM335X
+#elif defined(SOC_OMAP4)
+#define _ti_chip CHIP_OMAP_4
+#else
+#define _ti_chip -1
+#endif
+#else /* __rtems__ */
extern int _ti_chip;
+#endif /* __rtems__ */
static __inline int ti_chip(void)
{
diff --git a/libbsd.py b/libbsd.py
index e171a9d..18dfe8a 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -890,6 +890,39 @@ def dev_usb_storage_add_on(mm):
return mod
#
+# BBB USB
+#
+def dev_usb_controller_bbb(mm):
+mod = builder.Module('dev_usb_controller_bbb')
+mod.addDependency(mm['dev_usb'])
+mod.addKernelSpaceHeaderFiles(
+[
+'sys/arm/ti/ti_cpuid.h',
+'sys/arm/ti/ti_prcm.h',
+'sys/arm/ti/ti_scm.h',
+'sys/arm/ti/tivar.h',
+'sys/arm/ti/am335x/am335x_scm.h',
+'sys/dev/usb/controller/musb_otg.h',
+'sys/sys/timeet.h',
+'sys/sys/watchdog.h',
+'sys/dev/fdt/fdt_pinctrl.h',
+
+]
+)
+mod.addKernelSpaceSourceFiles(
+[
+'sys/arm/ti/ti_scm.c',
+'sys/arm/ti/am335x/am335x_prcm.c',
+'sys/arm/ti/am335x/am335x_usbss.c',
+'sys/arm/ti/ti_prcm.c',
+'sys/arm/ti/am335x/am335x_musb.c',
+'sys/dev/usb/controller/musb_otg.c',
+],
+mm.generator['source']()
+)
+return mod
+
+#
# USB Template
#
def dev_usb_template(mm):
@@ -3195,6 +3228,7 @@ def sources(mm):
mm.addModule(cam(mm))
mm.addModule(dev_usb_storage(mm))
#mm.addModule(dev_usb_storage_add_on(mm))
+mm.addModule(dev_usb_controller_bbb(mm))
#mm.addModule(dev_usb_template(mm))
diff --git a/libbsd_waf.py b/libbsd_waf.py
index 30765de..5d0d5d0 100644
--- a/libbsd_waf.py
+++ b/libbsd_waf.py
@@ -731,6 +731,11 @@ def build(bld):
source = ['freebsd/sys/arm/lpc/if_lpe.c',
'freebsd/sys/arm/lpc/lpc_pwr.c',
+ 'freebsd/sys/arm/ti/am335x/am335x_musb.c',
+ 'freebsd/sys/arm/ti/am335x/am335x_prcm.c',
+ 'freebsd/sys/arm/ti/am335x/am335x_usbss.c',
+ 'freebsd/sys/arm/ti/ti_prcm.c',
+ 'freebsd/sys/arm/ti/ti_scm.c',
'freebsd/sys/arm/xilinx/zy7_slcr.c',
'freebsd/sys/cam/cam.c',
'freebsd/sys/cam/scsi/scsi_all.c',
@@ -896,6 +901,7 @@ def build(bld):
'freebsd/sys/dev/tsec/if_tsec_fdt.c',
'freebsd/sys/dev/usb/controller/dwc_otg.c',
'freebsd/sys/dev/usb/controller/ehci.c',
+ 'freebsd/sys/dev/usb/controller/musb_otg.c',
'freebsd/sys/dev/usb/controller/ohci.c',
'freebsd/sys/dev/usb/controller/usb_controller.c',
'freebsd/sys/dev/usb/input/atp.c',
diff --git a/rtemsbsd/include/bsp/nexus-devices.h
b/rtemsbsd/include/bsp/nexus-devices.h
index 1fbf756..09a4cc3 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -46,6 +46,20 @@
RTEMS_BSD_DRIVER_SMC0(0x4e00, RVPBXA9_IRQ_ETHERNET);
+#elif defined(LIBBSP_ARM_BEAGLE_BSP_H)
+
+#include
+
+RTEMS_BSD_DEFINE_NEXUS_DEVICE(ofwbus, 0, 0, NUL
Re: [PATCH v2 2/2] Add dts file to generate dtb binary file for Beaglebone black.
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. >> We should not pollute the RTEMS sources with GPL2 code. Is there an >> alternative approach to use? > The another way is to directly use dtb binary file, but bin file also > has a gpl2 license. So this way is not acceptable. > Gedare said the scripts directory may be appropriate for rtems-tools.git > or something. So i can provide a default one that can be used, it may be > downloadable from somewhere e.g. in rtems-tools or from a FTP. > And this is the way to keep GPL code from RTEMS sources. > What do you think about? The ftp site is ok but please make sure you have the source with any binary file and all copyright details are valid. We should keep the rtems-tools.git repo as free of GPL as possible. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 1/2] Import am335x usb driver file from FreeBSD.
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. .git/rebase-apply/patch:1769: trailing whitespace. * ti_*_clk_devmap - Array of clock devices, should be defined one per SoC .git/rebase-apply/patch:1783: trailing whitespace. * to the clock device if found. .git/rebase-apply/patch:1795: trailing whitespace. error: corrupt patch at line 7336 Patch failed at 0001 Import am335x usb driver file from FreeBSD. The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". -- 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 geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 2/2] Add dts file to generate dtb binary file for Beaglebone black.
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 GNU General Public License * version 2. >>> We should not pollute the RTEMS sources with GPL2 code. Is there an >>> alternative approach to use? >> The another way is to directly use dtb binary file, but bin file also >> has a gpl2 license. So this way is not acceptable. >> Gedare said the scripts directory may be appropriate for rtems-tools.git >> or something. So i can provide a default one that can be used, it may be >> downloadable from somewhere e.g. in rtems-tools or from a FTP. >> And this is the way to keep GPL code from RTEMS sources. >> What do you think about? > > The ftp site is ok but please make sure you have the source with any binary > file > and all copyright details are valid. > > We should keep the rtems-tools.git repo as free of GPL as possible. > > Chris > Seems like no one wants the device tree files in any rtems repo. Do we need an extra rtems-devicetree repository for all BSPs that support device trees (currently two)? Maybe one that just takes over the scripts from FreeBSD to import the device tree sources from Linux? Kind regards Christian -- embedded brains GmbH Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 1/2] Import am335x usb driver file from FreeBSD.
On 13/07/17 07:07, Sebastian Huber wrote: The patches are all right, but I was not able to apply them: It was probably a problem on my side. Christian was able to apply the changes although we both use openSUSE 42.2. I fixed one white space change in the imported files. It is very important to not modify the imported files. -- 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 geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 1/2] Import am335x usb driver file from FreeBSD.
Ok, thank you. Best Regards Sichen Zhao From: devel on behalf of Sebastian Huber Sent: Thursday, July 13, 2017 13:35 To: Sichen Zhao; devel@rtems.org Cc: punitv...@gmail.com; christian.maude...@embedded-brains.de Subject: Re: [PATCH v2 1/2] Import am335x usb driver file from FreeBSD. On 13/07/17 07:07, Sebastian Huber wrote: > The patches are all right, but I was not able to apply them: It was probably a problem on my side. Christian was able to apply the changes although we both use openSUSE 42.2. I fixed one white space change in the imported files. It is very important to not modify the imported files. -- 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 geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 2/2] Add dts file to generate dtb binary file for Beaglebone black.
On 13/07/2017 15:09, Christian Mauderer wrote: > 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 GNU General Public > License * version 2. We should not pollute the RTEMS sources with GPL2 code. Is there an alternative approach to use? >>> The another way is to directly use dtb binary file, but bin file also >>> has a gpl2 license. So this way is not acceptable. >>> Gedare said the scripts directory may be appropriate for rtems-tools.git >>> or something. So i can provide a default one that can be used, it may be >>> downloadable from somewhere e.g. in rtems-tools or from a FTP. >>> And this is the way to keep GPL code from RTEMS sources. >>> What do you think about? >> >> The ftp site is ok but please make sure you have the source with any binary >> file >> and all copyright details are valid. >> >> We should keep the rtems-tools.git repo as free of GPL as possible. >> >> Chris >> > > Seems like no one wants the device tree files in any rtems repo. Do we > need an extra rtems-devicetree repository for all BSPs that support > device trees (currently two)? Yeah, I do not really know. It is a sort of gray area and not only for the licenses but how we integrate it. It is sort of like boot loaders and how they fit in. I hope this discussion can finding a way we can make this work. My concern with rtems-tool.git is the license for it 2-clause BSD and then we place some GPL code in it and users do not know and are caught out with compliance issues. For example I have some GPL code in the rtemstoolkit which is from libiberty [1]. I included as a way to get something working on all hosts quickly. I would like to change this but need the time to do that. At the moment rtems-tools is only on hosts so a bit simpler for users to manage. > Maybe one that just takes over the scripts > from FreeBSD to import the device tree sources from Linux? Does FreeBSD import the files into it's source tree from Linux? Can I assume loading a GPL DTB does not pollute the application? Chris [1] https://git.rtems.org/rtems-tools/tree/rtemstoolkit/libiberty/pex-common.c ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 2/2] Add dts file to generate dtb binary file for Beaglebone black.
Am 13.07.2017 um 08:05 schrieb Chris Johns: > On 13/07/2017 15:09, Christian Mauderer wrote: >> 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 GNU General Public >> License * version 2. > We should not pollute the RTEMS sources with GPL2 code. Is there an > alternative approach to use? The another way is to directly use dtb binary file, but bin file also has a gpl2 license. So this way is not acceptable. Gedare said the scripts directory may be appropriate for rtems-tools.git or something. So i can provide a default one that can be used, it may be downloadable from somewhere e.g. in rtems-tools or from a FTP. And this is the way to keep GPL code from RTEMS sources. What do you think about? >>> >>> The ftp site is ok but please make sure you have the source with any binary >>> file >>> and all copyright details are valid. >>> >>> We should keep the rtems-tools.git repo as free of GPL as possible. >>> >>> Chris >>> >> >> Seems like no one wants the device tree files in any rtems repo. Do we >> need an extra rtems-devicetree repository for all BSPs that support >> device trees (currently two)? > > Yeah, I do not really know. It is a sort of gray area and not only for the > licenses but how we integrate it. It is sort of like boot loaders and how they > fit in. I hope this discussion can finding a way we can make this work. > > My concern with rtems-tool.git is the license for it 2-clause BSD and then we > place some GPL code in it and users do not know and are caught out with > compliance issues. For example I have some GPL code in the rtemstoolkit which > is > from libiberty [1]. I included as a way to get something working on all hosts > quickly. I would like to change this but need the time to do that. At the > moment > rtems-tools is only on hosts so a bit simpler for users to manage. > >> Maybe one that just takes over the scripts >> from FreeBSD to import the device tree sources from Linux? > > Does FreeBSD import the files into it's source tree from Linux? > Yes. See https://github.com/freebsd/freebsd/blob/master/sys/gnu/dts/FreeBSD-upgrade > Can I assume loading a GPL DTB does not pollute the application? > I can't say that for sure. But I'm quite sure there should be some discussion regarding that on the FreeBSD mailing list. They should have had the same problem when they initially imported the files. @Sichen Zhao: Maybe you can find something on the FreeBSD mailing list? > Chris > > [1] https://git.rtems.org/rtems-tools/tree/rtemstoolkit/libiberty/pex-common.c > -- embedded brains GmbH Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 2/2] Add dts file to generate dtb binary file for Beaglebone black.
在 2017年07月13日 14:10, Christian Mauderer 写道: > > Am 13.07.2017 um 08:05 schrieb Chris Johns: >> On 13/07/2017 15:09, Christian Mauderer wrote: >>> 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 GNU General Public >>> License * version 2. >> We should not pollute the RTEMS sources with GPL2 code. Is there an >> alternative approach to use? > The another way is to directly use dtb binary file, but bin file also > has a gpl2 license. So this way is not acceptable. > Gedare said the scripts directory may be appropriate for rtems-tools.git > or something. So i can provide a default one that can be used, it may be > downloadable from somewhere e.g. in rtems-tools or from a FTP. > And this is the way to keep GPL code from RTEMS sources. > What do you think about? The ftp site is ok but please make sure you have the source with any binary file and all copyright details are valid. We should keep the rtems-tools.git repo as free of GPL as possible. Chris >>> Seems like no one wants the device tree files in any rtems repo. Do we >>> need an extra rtems-devicetree repository for all BSPs that support >>> device trees (currently two)? >> Yeah, I do not really know. It is a sort of gray area and not only for the >> licenses but how we integrate it. It is sort of like boot loaders and how >> they >> fit in. I hope this discussion can finding a way we can make this work. >> >> My concern with rtems-tool.git is the license for it 2-clause BSD and then we >> place some GPL code in it and users do not know and are caught out with >> compliance issues. For example I have some GPL code in the rtemstoolkit >> which is >> from libiberty [1]. I included as a way to get something working on all hosts >> quickly. I would like to change this but need the time to do that. At the >> moment >> rtems-tools is only on hosts so a bit simpler for users to manage. >> >>> Maybe one that just takes over the scripts >>> from FreeBSD to import the device tree sources from Linux? >> Does FreeBSD import the files into it's source tree from Linux? >> > Yes. See > https://github.com/freebsd/freebsd/blob/master/sys/gnu/dts/FreeBSD-upgrade > >> Can I assume loading a GPL DTB does not pollute the application? >> > I can't say that for sure. But I'm quite sure there should be some > discussion regarding that on the FreeBSD mailing list. They should have > had the same problem when they initially imported the files. > > @Sichen Zhao: Maybe you can find something on the FreeBSD mailing list? Yes, i will look at on FreeBSD ml about this topic. > >> Chris >> >> [1] >> https://git.rtems.org/rtems-tools/tree/rtemstoolkit/libiberty/pex-common.c >> ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
