Re: [PATCH 1/2] GPIO Driver

[Ketul Shah]

Hi Steve,

Yep I saw your code on user-ml. And yes It would be nice to see GPIO_IRQ to
be included in the patch.

And ya it would be great if you can help to modify the patch anyhow I will
also work on it (thanks for pulling our attention). And you can find the
sent patch working on my GitHub
 repository.

Thanks.

Best Regards,
Ketul

On 1 July 2015 at 08:50, Steve B  wrote:

> After this is sorted into the right place it would be great to see GPIO
> IRQs included. I got an IRQ working by just writing to the correct memory
> locations from application code (posted the source to users list last
> week), but I think Andre's API does have some hooks for that (seemed that
> way when I last looked). So it should not be too challenging to add that
> feature. If you don't have time to get to it then I will volunteer to do it
> once there is a patch that Gedare is happy with.
>
> Steve
>
>
> On Tue, Jun 30, 2015 at 9:53 AM, Gedare Bloom  wrote:
>
>> I don't think we want the shared code in cpukit but rather in
>> libbsp/shared.. Also, I think Andre shall commit the shared code, so
>> perhaps you should focus on just getting a localized solution working
>> in the beagleboard BSP
>>
>> On Tue, Jun 30, 2015 at 5:46 AM, Ketul Shah 
>> wrote:
>> > diff --git a/cpukit/include/rtems/gpio.h b/cpukit/include/rtems/gpio.h
>> > new file mode 100644
>> > index 000..3d68c39
>> > --- /dev/null
>> > +++ b/cpukit/include/rtems/gpio.h
>> > @@ -0,0 +1,64 @@
>> > +/**
>> > + * @file rtems/gpio.h
>> > + *
>> > + * @brief Global GPIO definitions.
>> > + *
>> > + * This include the generalized definitions for GPIO
>> > + */
>> > +
>> > +/**
>> > + * Copyright (c) 2015 Ketul Shah 
>> > + *
>> > + * The license and distribution terms for this file may be
>> > + * found in the file LICENSE in this distribution or at
>> > + * http://www.rtems.org/license/LICENSE.
>> > + */
>> > +
>> > +#ifndef _RTEMS_GPIO_H
>> > +#define _RTEMS_GPIO_H
>> > +
>> > +#ifdef __cplusplus
>> > +extern "C" {
>> > +#endif /* __cplusplus */
>> > +
>> > +/* Returned Error Codes by function */
>> > +#define GPIO_SUCCESSFUL0 /* operation is OK */
>> > +#define GPIO_UNKNOWN_PIN   1 /* pin not known by bsp */
>> > +#define GPIO_UNCONFIGURED_PIN  2 /* pin unable to configure */
>> > +#define GPIO_MISCONFIGURED_PIN 3 /* pin configuration can't match
>> operation */
>> > +
>> > +/* Possible GPIO Pin States */
>> > +#define GPIO_PIN_STATE_UNCONFIGURED 0
>> > +#define GPIO_PIN_STATE_DIGITAL_OUT  1
>> > +#define GPIO_PIN_STATE_DIGITAL_IN   2
>> > +
>> > +/**
>> > + * @brief Structure contains all the required members for GPIO access.
>> > + */
>> > +typedef struct
>> > +{
>> > +  int   pin_number;/* The pin number. */
>> > +  void* platform;  /* Opaque hardware specific set up details. */
>> > +} gpio_pin_handle;
>> > +
>> > +/**
>> > + * @brief Initializes the GPIO API.
>> > + */
>> > +extern void rtems_gpio_initialize(void);
>> > +/**
>> > + * @brief Selects a GPIO pin for a digital output.
>> > + */
>> > +extern int rtems_gpio_configure_pin_digital_out(
>> > +   gpio_pin_handle *, unsigned int );
>> > +/**
>> > + * @brief Turns on the given pin.
>> > + */
>> > +extern int rtems_gpio_digital_set(gpio_pin_handle *);
>> > +/**
>> > + * @brief Turns off the given pin.
>> > + */
>> > +extern int rtems_gpio_digital_clear(gpio_pin_handle *);
>> > +/**
>> > + * @brief currently configured pin is released and made UNCONFIGURED.
>> > + */
>> > +extern int rtems_gpio_release_pin(gpio_pin_handle *);
>> > \ No newline at end of file
>> >
>> > diff --git a/c/src/lib/libbsp/arm/beagle/gpio/gpio.c
>> b/c/src/lib/libbsp/arm/beagle/gpio/gpio.c
>> > new file mode 100644
>> > index 000..541d456
>> > --- /dev/null
>> > +++ b/c/src/lib/libbsp/arm/beagle/gpio/gpio.c
>> > @@ -0,0 +1,210 @@
>> > +/**
>> > + * @file
>> > + *
>> > + * @ingroup arm_beagle
>> > + *
>> > + * @brief Global BSP definitions.
>> > + */
>> > +
>> > +/**
>> > + * Copyright (c) 2015 Ketul Shah 
>> > + *
>> > + * The license and distribution terms for this file may be
>> > + * found in the file LICENSE in this distribution or at
>> > + * http://www.rtems.org/license/LICENSE.
>> > + */
>> > +
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +
>> > +/**
>> > + * @brief GPIO API mutex atributes.
>> > + */
>> > +#define MUTEX_ATRIBUTES \
>> > +  ( RTEMS_LOCAL \
>> > +| RTEMS_PRIORITY\
>> > +| RTEMS_BINARY_SEMAPHORE\
>> > +| RTEMS_INHERIT_PRIORITY\
>> > +| RTEMS_NO_PRIORITY_CEILING \
>> > +)
>> > +
>> > +#define OBTAIN_LOCK(s)  if(rtems_semaphore_obtain(s,
>>\
>> > +  RTEMS_WAIT,
>>   \
>> > +  RTEMS_NO_TIM

[PATCH] libmisc: Use SMP application by default on SMP

[Sebastian Huber]

---
 cpukit/libmisc/dummy/default-configuration.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/cpukit/libmisc/dummy/default-configuration.c 
b/cpukit/libmisc/dummy/default-configuration.c
index fc00406..c1898d3 100644
--- a/cpukit/libmisc/dummy/default-configuration.c
+++ b/cpukit/libmisc/dummy/default-configuration.c
@@ -102,6 +102,10 @@ static void Init( rtems_task_argument arg )
 #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
 #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
 
+#define CONFIGURE_SMP_APPLICATION
+
+#define CONFIGURE_SMP_MAXIMUM_PROCESSORS 32
+
 #define CONFIGURE_DISABLE_BSP_SETTINGS
 
 #define CONFIGURE_INIT
-- 
1.8.4.5

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

SMP support for Raspberry Pi 2

[Rohini Kulkarni]

Hi all,

I wish to know where the maximum number of processors for a variant are
configured. I took a look at some configure scripts. I could see the
processor count defined for xilinx-zynq in its configuration file as
ZYNQ_CPUS=2.

rtems_configuration_get_maximum_processors() called in gets this configured
number. But I don't know from where.

Also where is RTEMS_SMP defined for a bsp?

Thanks.

-- 
Rohini Kulkarni
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] libmisc: Use SMP application by default on SMP

[Joel Sherrill]

Should those be conditional on SMP being enabled?

On July 1, 2015 4:14:56 AM CDT, Sebastian Huber 
 wrote:
>---
> cpukit/libmisc/dummy/default-configuration.c | 4 
> 1 file changed, 4 insertions(+)
>
>diff --git a/cpukit/libmisc/dummy/default-configuration.c
>b/cpukit/libmisc/dummy/default-configuration.c
>index fc00406..c1898d3 100644
>--- a/cpukit/libmisc/dummy/default-configuration.c
>+++ b/cpukit/libmisc/dummy/default-configuration.c
>@@ -102,6 +102,10 @@ static void Init( rtems_task_argument arg )
> #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
> #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> 
>+#define CONFIGURE_SMP_APPLICATION
>+
>+#define CONFIGURE_SMP_MAXIMUM_PROCESSORS 32
>+
> #define CONFIGURE_DISABLE_BSP_SETTINGS
> 
> #define CONFIGURE_INIT

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] libmisc: Use SMP application by default on SMP

[Sebastian Huber]

confdefs.h will only look at these defines in case RTEMS_SMP is defined.

On 01/07/15 15:04, Joel Sherrill wrote:

Should those be conditional on SMP being enabled?

On July 1, 2015 4:14:56 AM CDT, Sebastian Huber 
 wrote:

---
cpukit/libmisc/dummy/default-configuration.c | 4 
1 file changed, 4 insertions(+)

diff --git a/cpukit/libmisc/dummy/default-configuration.c
b/cpukit/libmisc/dummy/default-configuration.c
index fc00406..c1898d3 100644
--- a/cpukit/libmisc/dummy/default-configuration.c
+++ b/cpukit/libmisc/dummy/default-configuration.c
@@ -102,6 +102,10 @@ static void Init( rtems_task_argument arg )
#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER

+#define CONFIGURE_SMP_APPLICATION
+
+#define CONFIGURE_SMP_MAXIMUM_PROCESSORS 32
+
#define CONFIGURE_DISABLE_BSP_SETTINGS

#define CONFIGURE_INIT

--joel


--
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] libmisc: Use SMP application by default on SMP

[Joel Sherrill]

On July 1, 2015 8:18:08 AM CDT, Sebastian Huber 
 wrote:
>confdefs.h will only look at these defines in case RTEMS_SMP is
>defined.

I know. Just wondered if it would be clearer for a reader. Maybe a comment that 
they have no impact if SMP is disabled.

>On 01/07/15 15:04, Joel Sherrill wrote:
>> Should those be conditional on SMP being enabled?
>>
>> On July 1, 2015 4:14:56 AM CDT, Sebastian Huber
> wrote:
>>> ---
>>> cpukit/libmisc/dummy/default-configuration.c | 4 
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/cpukit/libmisc/dummy/default-configuration.c
>>> b/cpukit/libmisc/dummy/default-configuration.c
>>> index fc00406..c1898d3 100644
>>> --- a/cpukit/libmisc/dummy/default-configuration.c
>>> +++ b/cpukit/libmisc/dummy/default-configuration.c
>>> @@ -102,6 +102,10 @@ static void Init( rtems_task_argument arg )
>>> #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
>>> #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
>>>
>>> +#define CONFIGURE_SMP_APPLICATION
>>> +
>>> +#define CONFIGURE_SMP_MAXIMUM_PROCESSORS 32
>>> +
>>> #define CONFIGURE_DISABLE_BSP_SETTINGS
>>>
>>> #define CONFIGURE_INIT
>> --joel

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2015 RPi USB Support

[Yurii Shevtsov]

Any news?

2015-06-29 19:50 GMT+03:00 Yurii Shevtsov :
> So, it is empty.
>
>  .rtemsroset.bsd.nexus.begin
> 0x001104bc0x0 ./libbsd.a(rtems-bsd-nexus.c.16.o)
> 0x001104bc_bsd__start_set_nexus
>  .rtemsroset.bsd.nexus.end
> 0x001104bc0x0 ./libbsd.a(rtems-bsd-nexus.c.16.o)
> 0x001104bc_bsd__stop_set_nexus
>
> What will be next step? My repo:
> https://github.com/gtament/rtems-libbsd/commit/cf3f0fcafef3bcb9b0ec80d8c57e1304689ebace
>
> 2015-06-29 9:43 GMT+03:00 Sebastian Huber 
> :
>> You can debug this issue on Qemu. The Nexus childes are registered in a
>> linker set, so I would consult the linker map file.  It should look like
>> this:
>>
>>  .rtemsroset.bsd.nexus.begin
>> 0x0052ef7c0x0 libbsd.a(rtems-bsd-nexus.o)
>> 0x0052ef7c _bsd__start_set_nexus
>>  .rtemsroset.bsd.nexus.content
>> 0x0052ef7c   0x28
>> testsuite/telnetd01/test_main.o
>>  .rtemsroset.bsd.nexus.end
>> 0x0052efa40x0 libbsd.a(rtems-bsd-nexus.o)
>> 0x0052efa4 _bsd__stop_set_nexus
>>
>> The  .rtemsroset.bsd.nexus.content section must be non-empty.
>>
>>
>> On 27/06/15 16:39, Yurii Shevtsov wrote:
>>>
>>> Any ideas? Maybe I did some typo? Maybe you can compile and try it in
>>> qemu?
>>>
>>> 2015-06-26 17:05 GMT+03:00 Yurii Shevtsov :

 2015-06-25 16:00 GMT+03:00 Sebastian Huber
 :
>
> I would set a break point to nexus_probe(). In this loop
>
>  SET_FOREACH(nd, nexus) {
>  device_add_child(dev, nd->name, nd->unit);
>  }
>
> your device must get added. I would also set break points to the probe
> and
> attach functions of your device.

 Added printfs()

  printf("before setforeach\n");

  SET_FOREACH(nd, nexus) {
  printf("setforeach: %s\n", nd->name);
  device_add_child(dev, nd->name, nd->unit);
  }

 Got only 'before setforeach' in console. So it doesn't step into loop.
 Any ideas? Also I already had printfs in my driver's probe and attach,
 also got no output.

> On 25/06/15 14:50, Yurii Shevtsov wrote:
>>
>> This is ping message, with small update: the problem is not on the
>> linking stage, driver is linked to testsuite (checked with objdump)
>>
>> 2015-06-21 17:57 GMT+03:00 Yurii Shevtsov :
>>>
>>> Hello)
>>> Now I have apps from libbsd testsuite running. But DWC OTG driver
>>> doesn't
>>> loads.
>>> I added this lines to init01/test_main.c:
>>>
>>> +SYSINIT_NEED_USB_CORE;
>>> +SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus);
>>>
>>> (I know it's bad hardcode)
>>>
>>> If I run it. I get only this:
>>> nexus0: 
>>> devctl: +nexus0 at   on root0
>>> devctl: !system=IFNET subsystem=lo0 type=ATTACH
>>>
>>> Of course, I modified rtemsbsd/include/machine/rtems-bsd-sysinit.h and
>>> rtemsbsd/include/bsp/nexus-devices.h (took vlues from working DTS) and
>>> did other nexus-related changes to drivers. You can find changes in my
>>> repo https://github.com/gtament/rtems-libbsd/
>>> So I need some kind of code review, please.
>>> P.S. All testsuites (netshell01, usb01) with shell hangs without any
>>> output.
>>>
>>> Thanks in advance!
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
> --
> 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.
>
>>
>> --
>> 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

BSP Driver not initialized

[Inderjit Singh]

Hi,

I'm trying to initialize (get up) my driver for a or1k target. I reused the the 
hello sample program to see if the driver ckicks in but nothing in th console 
(except the hello msg in Init fiunction. Does anyone know why?

I updated the file as shown below. At this point I am only interested in to see 
the initialization kicking in but I don't seems to get anything.

rtems/c/src/lib/libbsp/or1k/or1k-bsp/mydriver/mydriver.c:
---
rtems_device_driver rtems_mydriver_initialize(rtems_device_major_number major,

rtems_device_major_number unused,
  void *arg)
{
  printk("INIT\r\n");

  // rtems_io_register_driver
  // rtems_io_register_name (/dev/mydriver) with major

  return RTEMS_SUCCESSFUL;
}

... (Empty functions for read write etc.) ...


rtems/c/src/lib/libbsp/or1k/or1k-bsp/include/mydriver.h:
---
#include 

static rtems_device_driver rtems_mydriver_initialize(rtems_device_major_number 
major,
 rtems_device_minor_number 
unused,
 void *);

... (Other definitions for read write etc.) ...

#define AAC_MYDRIVER_DRIVER {   \
  rtems_mydriver_initialize,\
  rtems_mydriver_open,  \
  rtems_mydriver_close, \
  rtems_mydriver_read,  \
  rtems_mydriver_write, \
  rtems_mydriver_control }

static rtems_driver_address_table mydriver = AAC_MYDRIVER_DRIVER;

Makefile.am file rtems/c/src/lib/libbsp/or1k/or1k-bsp/Makefile.am:
---
...
include_bsp_HEADERS += include/mydriver.h
...
libbsp_a_SOURCES += mydriver/mydriver.c

Any help is appreciated.
Thanks,
Indy
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: BSP Driver not initialized

[Joel Sherrill]

On July 1, 2015 10:47:16 AM CDT, Inderjit Singh 
 wrote:
>Hi,
>
>I'm trying to initialize (get up) my driver for a or1k target. I reused
>the the hello sample program to see if the driver ckicks in but nothing
>in th console (except the hello msg in Init fiunction. Does anyone know
>why?
>
>I updated the file as shown below. At this point I am only interested
>in to see the initialization kicking in but I don't seems to get
>anything.

Each application configures its own set of drivers, maximums, etc by specifying 
the CONFIGURE_ macros like at the bottom of hello and then including 
confdefs.h. 

You need to add your driver to the set. From memory since on phone, this is via 
CONFIGURE_APPLICATION_DRIVERS or something similar.

This is in the users guide in the configuring a system chapter.

>rtems/c/src/lib/libbsp/or1k/or1k-bsp/mydriver/mydriver.c:
>---
>rtems_device_driver rtems_mydriver_initialize(rtems_device_major_number
>major,
>  rtems_device_major_number unused,
>  void *arg)
>{   
>  printk("INIT\r\n");
>
>  // rtems_io_register_driver
>  // rtems_io_register_name (/dev/mydriver) with major
>
>  return RTEMS_SUCCESSFUL;
>}
>
>... (Empty functions for read write etc.) ...
>
>
>rtems/c/src/lib/libbsp/or1k/or1k-bsp/include/mydriver.h:
>---
>#include 
>
>static rtems_device_driver
>rtems_mydriver_initialize(rtems_device_major_number major,
>  rtems_device_minor_number unused,
> void *);
>
>... (Other definitions for read write etc.) ...
>
>#define AAC_MYDRIVER_DRIVER {   \
>  rtems_mydriver_initialize,\
>  rtems_mydriver_open,  \
>  rtems_mydriver_close, \
>  rtems_mydriver_read,  \
>  rtems_mydriver_write, \
>  rtems_mydriver_control }
>
>static rtems_driver_address_table mydriver = AAC_MYDRIVER_DRIVER;
>
>Makefile.am file rtems/c/src/lib/libbsp/or1k/or1k-bsp/Makefile.am:
>---
>...
>include_bsp_HEADERS += include/mydriver.h
>...
>libbsp_a_SOURCES += mydriver/mydriver.c
>
>Any help is appreciated.
>Thanks,
>Indy

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Cache issue with BBB networking

[ragu nath]

Hi Marcos,

As far as I know, cache is enabled in Freebsd.

Thanks,
Ragunath

On Tue, Jun 30, 2015 at 7:14 PM, Marcos Díaz <
marcos.d...@tallertechnologies.com> wrote:

> I have a question about this, the frebsd driver, was prepared to be used
> with cache enabled?
> I mean, in freeBSD OS the cache is enabled?
>
> On Tue, Jun 30, 2015 at 12:46 AM, Daniel Gutson <
> daniel.gut...@tallertechnologies.com> wrote:
>
>> Ragu,
>>
>>Please ensure that you are getting cache coherence right. That is,
>> there are no packets crossing the cache lines.
>> FWIW, in a life ago, i got a problem with an eth driver where the
>> descriptors ring was not properly sized (ie no modulus cache line).
>> El 29/6/2015 17:23, "ragu nath"  escribió:
>>
>>> Thanks Marcos. I will let you know if there is any progress.
>>>
>>> Regards,
>>> Ragunath
>>>
>>> On Tue, Jun 30, 2015 at 12:50 AM, Marcos Díaz <
>>> marcos.d...@tallertechnologies.com> wrote:
>>>
 Hi,
 I'm sorry but in the development of the porting of LWIP i couldn't give
 any more time to the task, so when I reached that stage I just disabled the
 cache.
 I will try to give some time to that to see if i can help you, and of
 course, let me know if you find something.
 Sorry again

 On Mon, Jun 29, 2015 at 3:16 PM, ragu nath 
 wrote:

> Hi Marcos,
>
> I am working on porting ethernet driver for Beaglebone black from
> FreeBSD to rtems-libbsd as part of GSOC 2015. I ported the driver and
> got it working.
>
> But there was one issue I faced, similar to the one you mentioned in
> our earlier correspondence (regarding lwIP). You mentioned that the
> system crashes if cache is enabled.
>
> In my case, the Address Lookup Engine (ALE) is getting corrupted if
> cache is enabled. Because of this packet transmission failed sending
> out random junk packets. With cache disabled, networking is working.
>
> I am looking for options other than disabling cache as a whole. Is
> there any other option available?  Can you share the details of any of
> the things you tried and found not working?
>
>
> Thanks,
> Ragunath
>



 --

 __

 


 Marcos Díaz

 Software Engineer


 San Lorenzo 47, 3rd Floor, Office 5

 Córdoba, Argentina


 Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452

 Skype: markdiaz22


>>>
>>>
>>> --
>>> ragu
>>>
>>
>
>
> --
>
> __
>
> 
>
>
> Marcos Díaz
>
> Software Engineer
>
>
> San Lorenzo 47, 3rd Floor, Office 5
>
> Córdoba, Argentina
>
>
> Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452
>
> Skype: markdiaz22
>
>


-- 
ragu
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

FAT32 filesystem on an USB flash drive

[Martin Galvan]

Hi everyone! I'm currently working on a simple logger app which will
write into an USB flash drive. It'll create a text file on a FAT32
filesystem to store data to.

Since libusb doesn't offer the drivers needed by my device, I'm
compiling a vendor-provided baremetal USB stack as a stand-alone
application. So far it's doing a good job of detecting the drive. I'd
like to know how could I use the MSDOS interface provided by RTEMS to
manage the flash drive as a block device. Specifically, I'd like to
know what's the relationship between libfs and libblock, and where
should I place the USB stack primitives. Any concrete examples (other
than testsuites/samples/fileio, which doesn't use flash disks) would
be more than welcome.

I've already read the RTEMS wiki, the filesystem design guide and the
comments in flashdisk.h, and still didn't find anything useful.

-- 

Martin Galvan

Software Engineer

Taller Technologies Argentina

San Lorenzo 47, 3rd Floor, Office 5

Córdoba, Argentina

Phone: 54 351 4217888 / +54 351 4218211
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: FAT32 filesystem on an USB flash drive

[Martin Galvan]

My mistake: the application is meant to use JFFS2 instead of FAT32.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Testing of the Raspberry Pi graphic support

[QIAO YANG]

On Jun 30, 2015, at 12:41 PM, Pavel Pisa  wrote:


Hello Qiao Yang,

I have prepared testing on RPi B+ hardware last days
I have got to test your RTEMS branch

https://github.com/yangqiao/rtems

I have tried

e89884b add memory table entry for frame buffer (try to cover all possibility, 
may be larger afterward if it's not enough)

and then

b560cb2 refactor outch scratch


Both should work, I've tested before push. BTW, because I've found the way I 
refactor outch is not as clean as I imagined so I quickly reset and forced 
updated. Sorry for the conflict, but the problem is not here.




which has been left in my local copy from the previous fetch.

I have been able to build RTEMS as well as graphic libraries.
I have tried to build my standard shell test code and some graphic
test.

My setup

host system Debian Linux amd64

-

tools - local build

arm-rtems4.11-gcc (GCC) 4.9.2 with newlib newlib-2.2.0.20150423, binutils 2.24

I'm using exactly the same version



Configured
with: ../../../src/gcc-4.9/configure --target=arm-rtems4.11 --prefix=/usr 
--build=x86_64-pc-linux-gnu --enable-languages=c,c++ --disable-libstdcxx-pch 
--with-gnu-ld --with-gnu-as --enable-threads --enable-target-optspace 
--with-system-zlib --verbose --disable-nls --without-included-gettext 
--disable-win32-registry --with-newlib --enable-plugin 
--enable-newlib-io-c99-formats --enable-version-specific-runtime-libs 
--enable-newlib-iconv --disable-lto

Sorry that I'm not sure if these parameters would affect the result while I think 
probably not. I just use rsb (commit e9dfd95dd Revert "add basic support for 
OpenBSD ) to build the bset  4.11/rtems-arm  with default configuration.  The rsb 
fork on my github is the one I used.




used successfully for LPC4078 and LPC1778 RTEMS

-

RTEMS configured

../../../git/rtems-yangqiao/configure --target=arm-rtems4.11 
--prefix=/opt/rtems4.11 \
--enable-rtems-inlines --disable-multiprocessing --enable-cxx \
--enable-rdbg --enable-maintainer-mode --enable-tests=samples \
--enable-networking --enable-posix --disable-itron --disable-ada \
--disable-expada --disable-multilib --disable-docs \
--enable-rtemsbsp="raspberrypi"

I tried these configurations to rebuild, it works.
My configuration is:
../rtems-git/configure --target=arm-rtems4.11 \
   --enable-rtemsbsp=raspberrypi \
   --enable-tests=samples \
   --enable-networking \
   --enable-posix \
   --prefix=$HOME/development/rtems/bsps/4.11'
So I don't think the problem comes from here.



-

Raspberry Pi direct boot by config.txt options

kernel=appfoo.bin

I just leave the config empty and videocore will use the default arguments. It 
does no harm.





generated by

arm-rtems4.11-objcopy -R -S -O binary "$EXE_NAME" "$EXE_NAME.bin"

I used 'arm-rtems4.11-objcopy -O binary --strip-unneeded '.  -R -S should not 
do harm.




-

Raspberry Pi boot over U-boot and extlinux/extlinux.conf

TIMEOUT 100
DEFAULT default
MENU TITLE Boot menu

LABEL RTEMS appfoo
MENU LABEL RTEMS appfoo
LINUX appfoo.img
FDTDIR .

Sorry that I've got no idea about extlinux..





Image generated by

arm-rtems4.11-objcopy -R -S -O binary "$EXE_NAME" "$EXE_NAME.bin" || exit 1
cat "$EXE_NAME.bin" | gzip -9 >"$EXE_NAME.gz"
mkimage \
-A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n "RTEMS" \
-d "$EXE_NAME.gz" "$EXE_NAME.img"

mkimage -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n "RTEMS" -C 
none -d
I didn't use compression but should not do harm




-

The monitor resolution has been correctly obtained and printed for all 
combinations
but then there has been no progress/output on serial port even on HDMI output

Startup log for U-boot case

-
U-Boot 2015.04-rc2-gc5ec3a2 (Mar 05 2015 - 21:46:11)

DRAM: 448 MiB
WARNING: Caches not enabled
RPI Model B+
MMC: bcm2835_sdhci: 0
reading uboot.env
In: serial
Out: lcd
Err: lcd
Net: Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
reading /extlinux/extlinux.conf
2176 bytes read in 20 ms (105.5 KiB/s)
Boot menu
1: Linux 3.18.8-rt2+ with Overlay
2: Linux 3.18.8-rt2+ with Aufs
3: Linux 3.18.8-rt2+ RW root
4: Linux 3.18.8-rt2+ NFS BusyBox
5: Linux 3.18.8-rt2+ NFS Overlay
6: Linux 3.18.8-rt2+ NFS RW
7: RTEMS appfoo
8: RTEMS demo_suitk
9: Boot by localcmd
Enter choice: 8
8: RTEMS demo_suitk
Retrieving file: /extlinux/demo_suitk.img
reading /extlinux/demo_suitk.img
375420 bytes read in 89 ms (4 MiB/s)
Retrieving file: /extlinux/./bcm2835-rpi-b-plus.dtb
reading /e

Re: Testing of the Raspberry Pi graphic support

[QIAO YANG]

If you don’t have that much time to debug, you may try this bcm2835 qemu
https://github.com/Torlus/qemu/tree/rpi 


you can use it to run the kernel elf directly.

> On Jul 1, 2015, at 11:53 PM, QIAO YANG  wrote:
> 
> On Jun 30, 2015, at 12:41 PM, Pavel Pisa  > wrote:
> 
>> Hello Qiao Yang,
>> 
>> I have prepared testing on RPi B+ hardware last days
>> I have got to test your RTEMS branch
>> 
>> https://github.com/yangqiao/rtems 
>> 
>> I have tried
>> 
>> e89884b add memory table entry for frame buffer (try to cover all 
>> possibility, may be larger afterward if it's not enough)
>> 
>> and then
>> 
>> b560cb2 refactor outch scratch
>  
> Both should work, I've tested before push. BTW, because I've found the way I 
> refactor outch is not as clean as I imagined so I quickly reset and forced 
> updated. Sorry for the conflict, but the problem is not here.
> 
>> 
>> 
>> which has been left in my local copy from the previous fetch.
>> 
>> I have been able to build RTEMS as well as graphic libraries.
>> I have tried to build my standard shell test code and some graphic
>> test.
>> 
>> My setup
>> 
>> host system Debian Linux amd64
>> 
>> -
>> 
>> tools - local build
>> 
>> arm-rtems4.11-gcc (GCC) 4.9.2 with newlib newlib-2.2.0.20150423, binutils 
>> 2.24
> I'm using exactly the same version 
> 
>> 
>> Configured 
>> with: ../../../src/gcc-4.9/configure --target=arm-rtems4.11 --prefix=/usr 
>> --build=x86_64-pc-linux-gnu --enable-languages=c,c++ --disable-libstdcxx-pch 
>> --with-gnu-ld --with-gnu-as --enable-threads --enable-target-optspace 
>> --with-system-zlib --verbose --disable-nls --without-included-gettext 
>> --disable-win32-registry --with-newlib --enable-plugin 
>> --enable-newlib-io-c99-formats --enable-version-specific-runtime-libs 
>> --enable-newlib-iconv --disable-lto
> Sorry that I'm not sure if these parameters would affect the result while I 
> think probably not. I just use rsb (commit e9dfd95dd Revert "add basic 
> support for OpenBSD ) to build the bset  4.11/rtems-arm  with default 
> configuration.  The rsb fork on my github is the one I used.
> 
> 
>> 
>> used successfully for LPC4078 and LPC1778 RTEMS
>> 
>> -
>> 
>> RTEMS configured
>> 
>> ../../../git/rtems-yangqiao/configure --target=arm-rtems4.11 
>> --prefix=/opt/rtems4.11 \
>> --enable-rtems-inlines --disable-multiprocessing --enable-cxx \
>> --enable-rdbg --enable-maintainer-mode --enable-tests=samples \
>> --enable-networking --enable-posix --disable-itron --disable-ada \
>> --disable-expada --disable-multilib --disable-docs \
>> --enable-rtemsbsp="raspberrypi"
> I tried these configurations to rebuild, it works.
> My configuration is: 
> ../rtems-git/configure --target=arm-rtems4.11 \
> --enable-rtemsbsp=raspberrypi \
> --enable-tests=samples \
> --enable-networking \
> --enable-posix \
> --prefix=$HOME/development/rtems/bsps/4.11' 
> So I don't think the problem comes from here.
> 
>> 
>> -
>> 
>> Raspberry Pi direct boot by config.txt options
>> 
>> kernel=appfoo.bin
> I just leave the config empty and videocore will use the default arguments. 
> It does no harm. 
> 
> 
>> 
>> 
>> generated by
>> 
>> arm-rtems4.11-objcopy -R -S -O binary "$EXE_NAME" "$EXE_NAME.bin"
> I used 'arm-rtems4.11-objcopy -O binary --strip-unneeded '.  -R -S should not 
> do harm. 
> 
>> 
>> 
>> -
>> 
>> Raspberry Pi boot over U-boot and extlinux/extlinux.conf
>> 
>> TIMEOUT 100
>> DEFAULT default
>> MENU TITLE Boot menu
>> 
>> LABEL RTEMS appfoo
>> MENU LABEL RTEMS appfoo
>> LINUX appfoo.img
>> FDTDIR .
> Sorry that I've got no idea about extlinux..
> 
> 
>> 
>> 
>> Image generated by
>> 
>> arm-rtems4.11-objcopy -R -S -O binary "$EXE_NAME" "$EXE_NAME.bin" || exit 1
>> cat "$EXE_NAME.bin" | gzip -9 >"$EXE_NAME.gz"
>> mkimage \
>> -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n "RTEMS" \
>> -d "$EXE_NAME.gz" "$EXE_NAME.img"
> mkimage -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n "RTEMS" -C 
> none -d
> I didn't use compression but should not do harm 
> 
>> 
>> 
>> -
>> 
>> The monitor resolution has been correctly obtained and printed for all 
>> combinations
>> but then there has been no progress/output on serial port even on HDMI output
>> 
>> Startup log for U-boot case
>> 
>> -
>> U-Boot 2015.04-rc2-gc5ec3a2 (Mar 05 2015 - 21:46:11)
>> 
>> DRAM: 448 MiB
>> WARNING: Caches not enabled
>> RPI Model B+
>> MMC: bcm2835_sdhci: 0
>> reading uboot.env
>> In: serial
>> Out: lcd
>> Err: lcd
>> Net: Net Initialization S

Re: Testing of the Raspberry Pi graphic support

[Pavel Pisa]

Hello Qiao Yang,

thanks for status report.

On Wednesday 01 of July 2015 23:53:51 QIAO YANG wrote:
> On Jun 30, 2015, at 12:41 PM, Pavel Pisa  wrote:
>
> Both should work, I've tested before push. BTW, because I've found the way
> I refactor outch is not as clean as I imagined so I quickly reset and
> forced updated. Sorry for the conflict, but the problem is not here.

really no problem, because I am fully aware that work is in the
active development I have tried to test more versions which I have spotted.
I archived dead end branch after forced update and reset to main course.

> > arm-rtems4.11-gcc (GCC) 4.9.2 with newlib newlib-2.2.0.20150423, binutils
> > 2.24

OK

> I'm using exactly the same version
>
> > Configured
> > with: ../../../src/gcc-4.9/configure --target=arm-rtems4.11 --prefix=/usr
> > --build=x86_64-pc-linux-gnu --enable-languages=c,c++
> > --disable-libstdcxx-pch --with-gnu-ld --with-gnu-as --enable-threads
> > --enable-target-optspace --with-system-zlib --verbose --disable-nls
> > --without-included-gettext --disable-win32-registry --with-newlib
> > --enable-plugin --enable-newlib-io-c99-formats
> > --enable-version-specific-runtime-libs --enable-newlib-iconv
> > --disable-lto
>
> Sorry that I'm not sure if these parameters would affect the result while I
> think probably not. I just use rsb (commit e9dfd95dd Revert "add basic
> support for OpenBSD ) to build the bset  4.11/rtems-arm  with default
> configuration.  The rsb fork on my github is the one I used.

I do not expect problem from there too. This is mainly to document state.

> > RTEMS configured
> >
> > ../../../git/rtems-yangqiao/configure --target=arm-rtems4.11
> > --prefix=/opt/rtems4.11 \
> > --enable-rtems-inlines \ 
> > --disable-multiprocessing --enable-cxx \
> > --enable-rdbg --enable-maintainer-mode --enable-tests=samples \
> > --enable-networking --enable-posix --disable-itron --disable-ada \
> > --disable-expada --disable-multilib --disable-docs \
> > --enable-rtemsbsp="raspberrypi"
>
> I tried these configurations to rebuild, it works.
> My configuration is:
> ../rtems-git/configure --target=arm-rtems4.11 \
> --enable-rtemsbsp=raspberrypi \
> --enable-tests=samples \
> --enable-networking \
> --enable-posix \
> --prefix=$HOME/development/rtems/bsps/4.11'


Seem same and more straightforward, some of mine options
are accumulated over years with RTEMS on more targets
and some can be superfluous on actual version.

> So I don't think the problem comes from here.
>
> > -
> >
> > Raspberry Pi direct boot by config.txt options
> >
> > kernel=appfoo.bin
>
> I just leave the config empty and videocore will use the default arguments.
> It does no harm.
>
> > generated by
> >
> > arm-rtems4.11-objcopy -R -S -O binary "$EXE_NAME" "$EXE_NAME.bin"
>
> I used 'arm-rtems4.11-objcopy -O binary --strip-unneeded '.  -R -S should
> not do harm.

I have added "--strip-debug" to be sure but binary is exactly the same.

> > -
> >
> > Raspberry Pi boot over U-boot and extlinux/extlinux.conf
> >
> > TIMEOUT 100
> > DEFAULT default
> > MENU TITLE Boot menu
> >
> > LABEL RTEMS appfoo
> > MENU LABEL RTEMS appfoo
> > LINUX appfoo.img
> > FDTDIR .
>
> Sorry that I've got no idea about extlinux..

No problem, this is some addon layer to unite Linux configs over different
loaders. It allows to search for kernel images even over TFTP on RPi,
but I stayed wit local SD card boot. It is more or less that it can be
interesting for somebody.

> > Image generated by
> >
> > arm-rtems4.11-objcopy -R -S -O binary "$EXE_NAME" "$EXE_NAME.bin" || exit
> > 1 cat "$EXE_NAME.bin" | gzip -9 >"$EXE_NAME.gz"
> > mkimage \
> > -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n "RTEMS" \
> > -d "$EXE_NAME.gz" "$EXE_NAME.img"
>
> mkimage -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n "RTEMS" -C
> none -d I didn't use compression but should not do harm

Image seems to extract and start correctly.

> > ## Booting kernel from Legacy Image at 0100 ...
> > Image Name: RTEMS
> > Image Type: ARM RTEMS Kernel Image (gzip compressed)
> > Data Size: 375356 Bytes = 366.6 KiB
> > Load Address: 8000
> > Entry Point: 8000
> > Verifying Checksum ... OK
> > Uncompressing Kernel Image ... OK
> > ## Transferring control to RTEMS (at address 8000) ...
>
> It seems that the kernel boot successfully with uboot. I've these lines for
> uboot startup script but I passed nothing from uboot to kernel.:
> mmc dev 0 
> fatload mmc 0:1 ${kernel_addr_r} hello.img
> bootm ${kernel_addr_r}
> #0x8000
>
> > [+] framebuffer initialize
> > width:1680 height:1050
> > [+] framebuffer use display resolution 1680*1050
>
> We havn't passed any parameter of resolution from config.txt and It
> retrieves resolution correctly. So the mailbox videocore property channel
> works.

Yes that seems to work 

Re: Testing of the Raspberry Pi graphic support

[桥 杨]

---

Qiao YANG

Université de Technologie de Compiègne 
Génie Informatique

> 在 2015年7月2日，00:58，Pavel Pisa  写道：
> 
> Hello Qiao Yang,
> 
> thanks for status report.
> 
>> On Wednesday 01 of July 2015 23:53:51 QIAO YANG wrote:
>> On Jun 30, 2015, at 12:41 PM, Pavel Pisa  wrote:
>> 
>> Both should work, I've tested before push. BTW, because I've found the way
>> I refactor outch is not as clean as I imagined so I quickly reset and
>> forced updated. Sorry for the conflict, but the problem is not here.
> 
> really no problem, because I am fully aware that work is in the
> active development I have tried to test more versions which I have spotted.
> I archived dead end branch after forced update and reset to main course.
> 
>>> arm-rtems4.11-gcc (GCC) 4.9.2 with newlib newlib-2.2.0.20150423, binutils
>>> 2.24
> 
> OK
> 
>> I'm using exactly the same version
>> 
>>> Configured
>>> with: ../../../src/gcc-4.9/configure --target=arm-rtems4.11 --prefix=/usr
>>> --build=x86_64-pc-linux-gnu --enable-languages=c,c++
>>> --disable-libstdcxx-pch --with-gnu-ld --with-gnu-as --enable-threads
>>> --enable-target-optspace --with-system-zlib --verbose --disable-nls
>>> --without-included-gettext --disable-win32-registry --with-newlib
>>> --enable-plugin --enable-newlib-io-c99-formats
>>> --enable-version-specific-runtime-libs --enable-newlib-iconv
>>> --disable-lto
>> 
>> Sorry that I'm not sure if these parameters would affect the result while I
>> think probably not. I just use rsb (commit e9dfd95dd Revert "add basic
>> support for OpenBSD ) to build the bset  4.11/rtems-arm  with default
>> configuration.  The rsb fork on my github is the one I used.
> 
> I do not expect problem from there too. This is mainly to document state.
> 
>>> RTEMS configured
>>> 
>>> ../../../git/rtems-yangqiao/configure --target=arm-rtems4.11
>>> --prefix=/opt/rtems4.11 \
>>> --enable-rtems-inlines \ 
>>> --disable-multiprocessing --enable-cxx \
>>> --enable-rdbg --enable-maintainer-mode --enable-tests=samples \
>>> --enable-networking --enable-posix --disable-itron --disable-ada \
>>> --disable-expada --disable-multilib --disable-docs \
>>> --enable-rtemsbsp="raspberrypi"
>> 
>> I tried these configurations to rebuild, it works.
>> My configuration is:
>> ../rtems-git/configure --target=arm-rtems4.11 \
>>--enable-rtemsbsp=raspberrypi \
>>--enable-tests=samples \
>>--enable-networking \
>>--enable-posix \
>>--prefix=$HOME/development/rtems/bsps/4.11'
> 
> 
> Seem same and more straightforward, some of mine options
> are accumulated over years with RTEMS on more targets
> and some can be superfluous on actual version.
> 
>> So I don't think the problem comes from here.
>> 
>>> -
>>> 
>>> Raspberry Pi direct boot by config.txt options
>>> 
>>> kernel=appfoo.bin
>> 
>> I just leave the config empty and videocore will use the default arguments.
>> It does no harm.
>> 
>>> generated by
>>> 
>>> arm-rtems4.11-objcopy -R -S -O binary "$EXE_NAME" "$EXE_NAME.bin"
>> 
>> I used 'arm-rtems4.11-objcopy -O binary --strip-unneeded '.  -R -S should
>> not do harm.
> 
> I have added "--strip-debug" to be sure but binary is exactly the same.
> 
>>> -
>>> 
>>> Raspberry Pi boot over U-boot and extlinux/extlinux.conf
>>> 
>>> TIMEOUT 100
>>> DEFAULT default
>>> MENU TITLE Boot menu
>>> 
>>> LABEL RTEMS appfoo
>>> MENU LABEL RTEMS appfoo
>>> LINUX appfoo.img
>>> FDTDIR .
>> 
>> Sorry that I've got no idea about extlinux..
> 
> No problem, this is some addon layer to unite Linux configs over different
> loaders. It allows to search for kernel images even over TFTP on RPi,
> but I stayed wit local SD card boot. It is more or less that it can be
> interesting for somebody.
> 
>>> Image generated by
>>> 
>>> arm-rtems4.11-objcopy -R -S -O binary "$EXE_NAME" "$EXE_NAME.bin" || exit
>>> 1 cat "$EXE_NAME.bin" | gzip -9 >"$EXE_NAME.gz"
>>> mkimage \
>>> -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n "RTEMS" \
>>> -d "$EXE_NAME.gz" "$EXE_NAME.img"
>> 
>> mkimage -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n "RTEMS" -C
>> none -d I didn't use compression but should not do harm
> 
> Image seems to extract and start correctly.
> 
>>> ## Booting kernel from Legacy Image at 0100 ...
>>> Image Name: RTEMS
>>> Image Type: ARM RTEMS Kernel Image (gzip compressed)
>>> Data Size: 375356 Bytes = 366.6 KiB
>>> Load Address: 8000
>>> Entry Point: 8000
>>> Verifying Checksum ... OK
>>> Uncompressing Kernel Image ... OK
>>> ## Transferring control to RTEMS (at address 8000) ...
>> 
>> It seems that the kernel boot successfully with uboot. I've these lines for
>> uboot startup script but I passed nothing from uboot to kernel.:
>> mmc dev 0 
>> fatload mmc 0:1 ${kernel_addr_r} hello.img
>> bootm ${kernel_addr_r}
>> #0x8000
>> 
>>> [+] framebuffer initialize
>>> w

Re: Testing of the Raspberry Pi graphic support

[Pavel Pisa]

Hello Qiao Yang,

On Thursday 02 of July 2015 01:23:24 桥 杨 wrote:
> >
> > The final - RTEMS-4.11 intended option for i386 is named video
> >
> >  --video=auto|off|1024x768-32
> >
> > console selection is controlled by option
> >
> >  --console=com1
>
>  I tried to retrieve ATAG cmdline by mailbox property tag  channel, but
> failed as it cannot asure the string is terminated by certain
> character('/0') and I didn't fix the implementation of tag structure at
> that moment. It reminds me that I should take some time back to it, and
> maybe the freebsd, rasbian's source code can do help. I've just found some
> posts on arm atags . I'll look into the detail and try to implement it this
> weekend.

The access to ATAGs should be solved directly from RTEMS.
ATAGs. The structure is directly pointed by r2 register
when loader jumps to RTEMS for legacy boot. FDT address
is passed to the kernel in r2 for device tree case and command
line is filled to FDT in this case.

So r2 value should be preserved after enter to RTEMS
binary and pinted memory analyzed later.

See

4a. Setup the kernel tagged list

https://www.kernel.org/doc/Documentation/arm/Booting

Linux kernel ATAGs cmdline parsing is implemented in

http://lxr.free-electrons.com/source/arch/arm/include/uapi/asm/setup.h
http://lxr.free-electrons.com/source/arch/avr32/kernel/setup.c#L381

If r2 points to 0xd00dfeed (FDT_MAGIC) then FDT data are pointed by r2.
Format 

http://lxr.free-electrons.com/source/scripts/dtc/libfdt/fdt.h#L44

parsing

http://lxr.free-electrons.com/source/scripts/dtc/libfdt/fdt.c#L60

Best wishes,

 Pavel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel