Update of libbsd to close to FreeBSD 12 release planned

[Sebastian Huber]

Hello,

the FreeBSD project is about to prepare the FreeBSD 12 release soon:

https://www.freebsd.org/releases/12.0R/schedule.html

I would like to use this time frame to update the libbsd stepwise to a 
FreeBSD trunk version close to the FreeBSD 12 release. If someone has 
libbsd patches, please submit them as soon as possible.


See also:

https://devel.rtems.org/ticket/3472

--
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: Gcov support in Covoar

[Vijay Kumar Banerjee]

Hello,

I have made the changes and also got the confusion with
structure of gcno, cleared to some extent after some
careful reading and experiments.

I'm attaching the txt file generated. So far it is complete up to
function record, next is the basic block records. I will start with
the block records after finalizing the wrapup of the non-gcov
coverage reports to make sure that everything works properly there.

-- vijay

On 18 July 2018 at 17:17, Vijay Kumar Banerjee 
wrote:

> On 18 July 2018 at 02:30, Joel Sherrill  wrote:
>
>> This definitely looks like the right direction. If we don't understand
>> the file formats, we will never be able to process and correlate them.
>>
>> Please put 0x in front of hex numbers. It does help.
>>
>> Can you explain the fields in gcno_dump.txt? The Version field
>> looks like hex for R37A which doesn't make sense to me. Reading the
>> header in gcov-io.h, I wonder how it matches this pattern?
>>
>> it should be A73R, I have corrected it.
> I have tried to give some description in the code itself.
> I'll write a detailed description of each field once it's complete.
> Maybe a blog post will be nice.
>
>> 
>> Although the ident and version are formally 32 bit numbers, they
>>are derived from 4 character ASCII strings.  The version number
>>consists of a two character major version number
>>(first digit starts from 'A' letter to not to clash with the older
>>numbering scheme), the single character minor version number,
>>and a single character indicating the status of the release.
>>That will be 'e' experimental, 'p' prerelease and 'r' for release.
>>Because, by good fortune, these are in alphabetical order, string
>>collating can be used to compare version strings.  Be aware that
>>the 'e' designation will (naturally) be unstable and might be
>>incompatible with itself.  For gcc 17.0 experimental, it would be
>>'B70e' (0x42373065).  As we currently do not release more than 5 minor
>>releases, the single character should be always fine.  Major number
>>is currently changed roughly every year, which gives us space
>>for next 250 years (maximum allowed number would be 259.9).
>> 
>>
>>
>> The timestamp field also doesn't make sense to me. Assuming that
>> is a hex number, it has a LOT of digits and
>> https://www.epochconverter.com/
>> tells me that it is sometime in 2741
>>
>> There was some issue with it because I was taking signed int.
> I fixed it.
>
>> Maybe you have the endianness of some of the fields wrong.
>>
>> Yes the endianness was wrong.
> I have uploaded the code to a github repository so that it can be
> visible and progress can be trackable.
>
> https://github.com/thelunatic/gcno_dumper.git
>
> I am working on figuring out how the file is organised, I'll
> post the generated txt file soon.
>
>> But this is what it takes to understand it. :)
>>
>> --joel
>>
>>
>> On Sat, Jul 14, 2018 at 4:29 PM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> As suggested by Joel, I have tried to figure out the structure of
>>> the gcno files and written a gcno dumper.
>>> This is not complete yet, I'm still working on it and I'll keep adding
>>> to it as I "decode" the gcno files.
>>>
>>> I'm attaching the c++ code, the gcno file I'm testing on and the txt
>>> file generated from it.
>>>
>>> please have a look. Is it moving in the right direction ?
>>>
>>> On 12 July 2018 at 03:56, Vijay Kumar Banerjee >> > wrote:
>>>
 I have filed a ticket for gcov, as suggested by Joel.

 https://devel.rtems.org/ticket/3468

 -- vijay

 On 8 July 2018 at 01:43, Chris Johns  wrote:

> On 8/7/18 7:51 am, Vijay Kumar Banerjee wrote:
> > On 8 July 2018 at 01:08, Joel Sherrill  j...@rtems.org>>
> > wrote:
> >
> > On Sat, Jul 7, 2018, 2:33 PM Chris Johns <
> ch...@contemporary.net.au
> > > wrote:
> >
> > On 5 Jul 2018, at 3:07 am, Joel Sherrill  > 
> > >> wrote:
> > > On Wed, Jul 4, 2018, 3:06 AM Chris Johns  
> > > >>
> wrote:
> > >
> > > How does this fit into the RTEMS Tester tool?
> > >
> > >
> > > If you want to run gcov or lcov on uninstrumented
> executables, then covoar has
> > > to read gcno and write gcda files. And we have to then run
> gcov or lcov as
> > > normal.
> >
> >
> > This is just a description of how it works. Not a particular
> change.
> >
> > >
> > > It is the path to another report format.
> >
> > I am not sure I understand how we make this work 

Re: [PATCH 1/1] user: Add x86_64 BSP chapter

[Joel Sherrill]

Thanks Gedare. It is pushed now. Just had to find it.

On Wed, Jul 18, 2018 at 12:40 PM, Gedare Bloom  wrote:

> Ping -- joel
>
> On Fri, Jul 13, 2018 at 9:19 AM, Gedare Bloom  wrote:
> > This looks fine to push
> >
> > On Fri, Jul 13, 2018 at 3:32 AM, Amaan Cheval 
> wrote:
> >> ---
> >>  user/bsps/bsps-x86_64.rst | 143 ++
> +++-
> >>  1 file changed, 142 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/user/bsps/bsps-x86_64.rst b/user/bsps/bsps-x86_64.rst
> >> index 18f80d2..19c4461 100644
> >> --- a/user/bsps/bsps-x86_64.rst
> >> +++ b/user/bsps/bsps-x86_64.rst
> >> @@ -1,7 +1,148 @@
> >>  .. comment SPDX-License-Identifier: CC-BY-SA-4.0
> >> +.. comment Copyright (c) 2018 Amaan Cheval 
> >>  .. comment Copyright (c) 2018 embedded brains GmbH
> >>
> >>  x86_64
> >>  **
> >>
> >> -There are no x86_64 BSPs yet.
> >> +amd64
> >> +=
> >> +
> >> +This BSP offers only one variant, ``amd64``. The BSP can run on
> UEFI-capable
> >> +systems by using FreeBSD's bootloader, which then loads the RTEMS
> executable (an
> >> +ELF image).
> >> +
> >> +Currently only the console driver and context initialization and
> switching are
> >> +functional (to a bare minimum), but this is enough to run the
> ``hello.exe`` sample
> >> +in the RTEMS testsuite.
> >> +
> >> +Build Configuration Options
> >> +---
> >> +
> >> +There are no options available to ``configure`` at build time, at the
> moment.
> >> +
> >> +Testing with QEMU
> >> +-
> >> +
> >> +To test with QEMU, we need to:
> >> +
> >> +- Build / install QEMU (most distributions should have it available on
> the
> >> +  package manager).
> >> +- Build UEFI firmware that QEMU can use to simulate an x86-64 system
> capable of
> >> +  booting a UEFI-aware kernel, through the ``--bios`` flag.
> >> +
> >> +Building TianoCore's UEFI firmware, OVMF
> >> +
> >> +
> >> +Complete detailed instructions are available at `TianoCore's Github's
> wiki
> >> + wiki/How-to-build-OVMF>`_.
> >> +
> >> +Quick instructions (which may fall out of date) are:
> >> +
> >> +.. code-block:: shell
> >> +
> >> +$ git clone git://github.com/tianocore/edk2.git
> >> +$ cd edk2
> >> +$ make -C BaseTools
> >> +$ . edksetup.sh
> >> +
> >> +Then edit ``Conf/target.txt`` to set:
> >> +
> >> +::
> >> +
> >> +ACTIVE_PLATFORM   = OvmfPkg/OvmfPkgX64.dsc
> >> +TARGET= DEBUG
> >> +TARGET_ARCH   = X64
> >> +# You can use GCC46 as well, if you'd prefer
> >> +TOOL_CHAIN_TAG= GCC5
> >> +
> >> +Then run ``build`` in the ``edk2`` directory - the output should list
> the
> >> +location of the ``OVMF.fd`` file, which can be used with QEMU to boot
> into a UEFI
> >> +shell.
> >> +
> >> +You can find the ``OVMF.fd`` file like this as well in the edk2
> directory:
> >> +
> >> +.. code-block:: shell
> >> +
> >> +$ find . -name "*.fd"
> >> +./Build/OvmfX64/DEBUG_GCC5/FV/MEMFD.fd
> >> +./Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd <-- the file we're looking
> for
> >> +./Build/OvmfX64/DEBUG_GCC5/FV/OVMF_CODE.fd
> >> +./Build/OvmfX64/DEBUG_GCC5/FV/OVMF_VARS.fd
> >> +
> >> +Boot RTEMS via FreeBSD's bootloader
> >> +---
> >> +
> >> +The RTEMS executable produced (an ELF file) needs to be placed in the
> FreeBSD's
> >> +``/boot/kernel/kernel``'s place.
> >> +
> >> +To do that, we first need a hard-disk image with FreeBSD installed on
> >> +it. `Download FreeBSD's installer "memstick" image for amd64
> >> +`_ and then run the following
> commands,
> >> +replacing paths as appropriate.
> >> +
> >> +.. code-block:: shell
> >> +
> >> +   $ qemu-img create freebsd.img 8G
> >> +   $ OVMF_LOCATION=/path/to/ovmf/OVMF.fd
> >> +   $ FREEBSD_MEMSTICK=/path/to/FreeBSD-11.2-amd64-memstick.img
> >> +   $ qemu-system-x86_64 -m 1024 -serial stdio --bios $OVMF_LOCATION \
> >> +   -drive format=raw,file=freebsd.img \
> >> +   -drive format=raw,file=$FREEBSD_MEMSTICK
> >> +
> >> +The first time you do this, continue through and install FreeBSD.
> `FreeBSD's
> >> +installation guide may prove useful
> >> +`_ if
> required.
> >> +
> >> +Once installed, build your RTEMS executable (an ELF file), for
> >> +eg. ``hello.exe``. We need to transfer this executable into
> ``freebsd.img``'s
> >> +filesystem, at either ``/boot/kernel/kernel`` or
> ``/boot/kernel.old/kernel`` (or
> >> +elsewhere, if you don't mind user FreeBSD's ``loader``'s prompt to
> boot your
> >> +custom kernel).
> >> +
> >> +If your host system supports mounting UFS filesystems as read-write
> >> +(eg. FreeBSD), go ahead and:
> >> +
> >> +1. Mount ``freebsd.img`` as read-write
> >> +2. Within the filesystem, back the existing FreeBSD kernel up (i.e.
> effectively
> >> +   ``cp -r /boot/kernel 

Re: [PATCH 1/1] user: Add x86_64 BSP chapter

[Gedare Bloom]

Ping -- joel

On Fri, Jul 13, 2018 at 9:19 AM, Gedare Bloom  wrote:
> This looks fine to push
>
> On Fri, Jul 13, 2018 at 3:32 AM, Amaan Cheval  wrote:
>> ---
>>  user/bsps/bsps-x86_64.rst | 143 
>> +-
>>  1 file changed, 142 insertions(+), 1 deletion(-)
>>
>> diff --git a/user/bsps/bsps-x86_64.rst b/user/bsps/bsps-x86_64.rst
>> index 18f80d2..19c4461 100644
>> --- a/user/bsps/bsps-x86_64.rst
>> +++ b/user/bsps/bsps-x86_64.rst
>> @@ -1,7 +1,148 @@
>>  .. comment SPDX-License-Identifier: CC-BY-SA-4.0
>> +.. comment Copyright (c) 2018 Amaan Cheval 
>>  .. comment Copyright (c) 2018 embedded brains GmbH
>>
>>  x86_64
>>  **
>>
>> -There are no x86_64 BSPs yet.
>> +amd64
>> +=
>> +
>> +This BSP offers only one variant, ``amd64``. The BSP can run on UEFI-capable
>> +systems by using FreeBSD's bootloader, which then loads the RTEMS 
>> executable (an
>> +ELF image).
>> +
>> +Currently only the console driver and context initialization and switching 
>> are
>> +functional (to a bare minimum), but this is enough to run the ``hello.exe`` 
>> sample
>> +in the RTEMS testsuite.
>> +
>> +Build Configuration Options
>> +---
>> +
>> +There are no options available to ``configure`` at build time, at the 
>> moment.
>> +
>> +Testing with QEMU
>> +-
>> +
>> +To test with QEMU, we need to:
>> +
>> +- Build / install QEMU (most distributions should have it available on the
>> +  package manager).
>> +- Build UEFI firmware that QEMU can use to simulate an x86-64 system 
>> capable of
>> +  booting a UEFI-aware kernel, through the ``--bios`` flag.
>> +
>> +Building TianoCore's UEFI firmware, OVMF
>> +
>> +
>> +Complete detailed instructions are available at `TianoCore's Github's wiki
>> +`_.
>> +
>> +Quick instructions (which may fall out of date) are:
>> +
>> +.. code-block:: shell
>> +
>> +$ git clone git://github.com/tianocore/edk2.git
>> +$ cd edk2
>> +$ make -C BaseTools
>> +$ . edksetup.sh
>> +
>> +Then edit ``Conf/target.txt`` to set:
>> +
>> +::
>> +
>> +ACTIVE_PLATFORM   = OvmfPkg/OvmfPkgX64.dsc
>> +TARGET= DEBUG
>> +TARGET_ARCH   = X64
>> +# You can use GCC46 as well, if you'd prefer
>> +TOOL_CHAIN_TAG= GCC5
>> +
>> +Then run ``build`` in the ``edk2`` directory - the output should list the
>> +location of the ``OVMF.fd`` file, which can be used with QEMU to boot into 
>> a UEFI
>> +shell.
>> +
>> +You can find the ``OVMF.fd`` file like this as well in the edk2 directory:
>> +
>> +.. code-block:: shell
>> +
>> +$ find . -name "*.fd"
>> +./Build/OvmfX64/DEBUG_GCC5/FV/MEMFD.fd
>> +./Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd <-- the file we're looking for
>> +./Build/OvmfX64/DEBUG_GCC5/FV/OVMF_CODE.fd
>> +./Build/OvmfX64/DEBUG_GCC5/FV/OVMF_VARS.fd
>> +
>> +Boot RTEMS via FreeBSD's bootloader
>> +---
>> +
>> +The RTEMS executable produced (an ELF file) needs to be placed in the 
>> FreeBSD's
>> +``/boot/kernel/kernel``'s place.
>> +
>> +To do that, we first need a hard-disk image with FreeBSD installed on
>> +it. `Download FreeBSD's installer "memstick" image for amd64
>> +`_ and then run the following commands,
>> +replacing paths as appropriate.
>> +
>> +.. code-block:: shell
>> +
>> +   $ qemu-img create freebsd.img 8G
>> +   $ OVMF_LOCATION=/path/to/ovmf/OVMF.fd
>> +   $ FREEBSD_MEMSTICK=/path/to/FreeBSD-11.2-amd64-memstick.img
>> +   $ qemu-system-x86_64 -m 1024 -serial stdio --bios $OVMF_LOCATION \
>> +   -drive format=raw,file=freebsd.img \
>> +   -drive format=raw,file=$FREEBSD_MEMSTICK
>> +
>> +The first time you do this, continue through and install FreeBSD. `FreeBSD's
>> +installation guide may prove useful
>> +`_ if required.
>> +
>> +Once installed, build your RTEMS executable (an ELF file), for
>> +eg. ``hello.exe``. We need to transfer this executable into 
>> ``freebsd.img``'s
>> +filesystem, at either ``/boot/kernel/kernel`` or 
>> ``/boot/kernel.old/kernel`` (or
>> +elsewhere, if you don't mind user FreeBSD's ``loader``'s prompt to boot your
>> +custom kernel).
>> +
>> +If your host system supports mounting UFS filesystems as read-write
>> +(eg. FreeBSD), go ahead and:
>> +
>> +1. Mount ``freebsd.img`` as read-write
>> +2. Within the filesystem, back the existing FreeBSD kernel up (i.e. 
>> effectively
>> +   ``cp -r /boot/kernel /boot/kernel.old``).
>> +3. Place your RTEMS executable at ``/boot/kernel/kernel``
>> +
>> +If your host doesn't support mounting UFS filesystems (eg. most Linux 
>> kernels),
>> +do something to the effect of the following.
>> +
>> +On the host
>> +
>> +.. code-block:: shell
>> +
>> +   # Upload hello.exe anywhere accessible within the host
>> +   $ curl 

Re: [PATCH 01/45] libfdt: check for potential overrun in _fdt_splice()

[Joel Sherrill]

On Wed, Jul 18, 2018 at 2:38 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Sorry, I forgot the cover letter.
>
> This patch series update the libfdt to the latest upstream version, see
> also
>

If all the patches are from the upstream, just push them. They have already
been reviewed
by libfdt. If they cause problems on our side, we need to deal with that as
a change to
the current libfdt.



>
> https://devel.rtems.org/ticket/3471
>
> --
> 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: [GSoC - x86_64] Clock driver - which hardware source to support primarily?

[Gedare Bloom]

On Wed, Jul 18, 2018 at 10:17 AM, Joel Sherrill  wrote:
>
>
> On Wed, Jul 18, 2018 at 12:31 AM, Sebastian Huber
>  wrote:
>>
>> Hello Amaan,
>>
>> On 17/07/18 19:18, Amaan Cheval wrote:
>>>
>>> Hi!
>>>
>>> Now that I'm working on the clock driver, we need to pick what we
>>> support first. Our options in brief are:
>>
>>
>> The clock driver needs an interrupt. What is the status of the interrupt
>> controller support in the BSP?
>>
>> For timekeeping we use a port of the FreeBSD timecounter in RTEMS. You may
>> have a look at the FreeBSD timecounter for this architecture, e.g.
>> sys/x86/x86/tsc.c. I looks quite complicated. I would not take to much care
>> about legacy support, e.g. ignore hardware which is older than five years?.
>
>
> That's not a good rule for PCs at all. The APIC was first introduced as an
> external controller with the i486,
> Based on your rule, we wouldn't support it even though it is the most likely
> choice.
>

I believe he meant ignore hardware that is not available from products
in the last five years.


> Avoid things that are deemed legacy. The starting point for this is the old
> PC
> System Design Guide.
>
> https://en.wikipedia.org/wiki/PC_System_Design_Guide
>
> If it was deemed obsolete in PC2001, then you definitely want to avoid it.
> Those
> things are just now really disappearing.
>

This is consistent with my interpretation.

> --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: [GSoC - x86_64] Clock driver - which hardware source to support primarily?

[Joel Sherrill]

On Wed, Jul 18, 2018 at 12:31 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Amaan,
>
> On 17/07/18 19:18, Amaan Cheval wrote:
>
>> Hi!
>>
>> Now that I'm working on the clock driver, we need to pick what we
>> support first. Our options in brief are:
>>
>
> The clock driver needs an interrupt. What is the status of the interrupt
> controller support in the BSP?
>
> For timekeeping we use a port of the FreeBSD timecounter in RTEMS. You may
> have a look at the FreeBSD timecounter for this architecture, e.g.
> sys/x86/x86/tsc.c. I looks quite complicated. I would not take to much care
> about legacy support, e.g. ignore hardware which is older than five years?.


That's not a good rule for PCs at all. The APIC was first introduced as an
external controller with the i486,
Based on your rule, we wouldn't support it even though it is the most
likely choice.

Avoid things that are deemed legacy. The starting point for this is the old
PC
System Design Guide.

https://en.wikipedia.org/wiki/PC_System_Design_Guide

If it was deemed obsolete in PC2001, then you definitely want to avoid it.
Those
things are just now really disappearing.

--joel


>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, G
> 
> ermany
> 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 0/1] [GSoC - x86_64] User documentation for BSP

[Amaan Cheval]

On Wed, Jul 18, 2018 at 6:56 PM, Gedare Bloom  wrote:
> On Wed, Jul 18, 2018 at 9:09 AM, Amaan Cheval  wrote:
>> Hi!
>>
>> On Fri, Jul 13, 2018 at 7:32 PM, Joel Sherrill  wrote:
>>>
>>>
>>> On Fri, Jul 13, 2018 at 8:25 AM, Gedare Bloom  wrote:

 Hello Amaan,


 On Fri, Jul 13, 2018 at 3:32 AM, Amaan Cheval 
 wrote:
 > The built documentation can more easily be viewed here:
 > http://whatthedude.com/rtems/user/html/bsps/bsps-x86_64.html
 >
 > It feels a bit convoluted to me at the moment. I'd appreciate feedback
 > on how
 > the documentation may be made more understandable, and on whether the
 > current
 > approach even seems sustainable - specifically, using FreeBSD's
 > bootloader ties
 > us into using the UFS filesystem and can slow down the
 > iterative-development
 > process.
 >
 I agree. It looks like you have to build FreeBSD at least one time to
 use this? Alternatives should be again considered for iterative
 improvement.
>>
>> That's right, and I agree. The only question is, at what point should
>> we consider alternatives? After interrupts and the clock driver work
>> is completed, if there's time left, or before (i.e. right now)?
>>
>> Is this too large a barrier to entry, and we'd rather make it easier
>> for future contributors to enter, than to have a more complete BSP
>> that users and contributors find to be too much effort to practically
>> use?
>>
>> (I'm asking about priorities assuming that there isn't time to do
>> _all_ the work, which may or may not be true.)
>>
>
> It is better to have a working basic BSP, even if it is a bit
> complicated to build from scratch, and have a roadmap for how to make
> it simpler to use.
>

Gotcha, thanks.

>>>
>>>
>>> Reducing what has to be built is an important goal. But an alternative is
>>> to host a pre-built binary of what is required to boot. I did that for a
>>> boot
>>> floppy for the pc386. There were instructions for making one and they
>>> worked but, in practice, just grabbing the floppy image was easier.
>>
>> Since we likely need the entire FreeBSD hard disk image, not just its
>> loader.efi file, this may be a file that's a GB or more. (I've been
>> using 8GB just to be safe, so I don't know how small we can make
>> this.)
>>
>> We need the entire FreeBSD image because their kernel is one of the
>> few that lets us mount a UFS/ZFS filesystem as read-write (which are
>> the only filesystems their loader supports loading the kernel from).
>>
>> IMO, looking for an alternate solution may well be for the best, but I
>> also think it can wait until after we have interrupts and the clock
>> driver.
>>
>> Roughly in the order listed here:
>> https://blog.whatthedude.com/post/gsoc-phase-2-status/#upcoming
>>
>>>
>>> Note; you didn't need to use a real floppy. Telling qemu what file
>>> was the 1.44 MB image was all that was needed. Combine that with
>>> vfat for c: and it worked find.
>>>
>>> So I think we need both -- RSB for building from source and a pre-built
>>> binary.
>>>


 > In my opinion, this system is good _enough_ for now - we can explore
 > other
 > options later if time permits, but I'd love to hear differing opinions.
 >
 > P.S. - Joel asked earlier if the QEMU that the RSB builds will suffice -
 > for me,
 > it didn't because in it "SDL support is disabled" (and so are all other
 > graphics
 > options). It's likely possible to install FreeBSD without graphics, it
 > may not
 > be worth the effort of setting up - it's likely easier to update the
 > RSB's QEMU
 > to also build graphics support.
 >
 I was going to recommend this. You can make it an option of the qemu
 configuration in RSB to enable the support needed. I suggest you talk
 to Vijay as he has some experience now with RSB, and also this will
 require Chris Johns approval.
>>>
>>>
>>> Everything that wasn't needed was disabled to make it easier to build
>>> on multiple hosts. Too many projects are Linux monoculture and
>>> getting things built on multiple hosts can be a pain.
>>>
>>> But I think SDL support needs to be enabled since otherwise we have
>>> no way to test graphics at all.
>>>


 Relatedly, does it make sense for you to look at creating an RSB
 "recipe" for building the UEFI firmware?
>>>
>>>
>>> See above. I think we need RSB recipes for everything required that
>>> we expect to be put together by a user. And we should host binaries
>>> along with matching sources for some pre-built versions. I don't want
>>> this BSP to be an order of magnitude harder to get started with than
>>> any of the others.
>>
>> +1.
>>


 > P.P.S. - Some of the documentation is double-spaced, but this patch
 > isn't. Let me
 > know if it ought to be (the README didn't say anything of the sort, and
 > it isn't
 > consistent throughout).
 >

 Stick to one 

Re: [PATCH 0/1] [GSoC - x86_64] User documentation for BSP

[Gedare Bloom]

On Wed, Jul 18, 2018 at 9:09 AM, Amaan Cheval  wrote:
> Hi!
>
> On Fri, Jul 13, 2018 at 7:32 PM, Joel Sherrill  wrote:
>>
>>
>> On Fri, Jul 13, 2018 at 8:25 AM, Gedare Bloom  wrote:
>>>
>>> Hello Amaan,
>>>
>>>
>>> On Fri, Jul 13, 2018 at 3:32 AM, Amaan Cheval 
>>> wrote:
>>> > The built documentation can more easily be viewed here:
>>> > http://whatthedude.com/rtems/user/html/bsps/bsps-x86_64.html
>>> >
>>> > It feels a bit convoluted to me at the moment. I'd appreciate feedback
>>> > on how
>>> > the documentation may be made more understandable, and on whether the
>>> > current
>>> > approach even seems sustainable - specifically, using FreeBSD's
>>> > bootloader ties
>>> > us into using the UFS filesystem and can slow down the
>>> > iterative-development
>>> > process.
>>> >
>>> I agree. It looks like you have to build FreeBSD at least one time to
>>> use this? Alternatives should be again considered for iterative
>>> improvement.
>
> That's right, and I agree. The only question is, at what point should
> we consider alternatives? After interrupts and the clock driver work
> is completed, if there's time left, or before (i.e. right now)?
>
> Is this too large a barrier to entry, and we'd rather make it easier
> for future contributors to enter, than to have a more complete BSP
> that users and contributors find to be too much effort to practically
> use?
>
> (I'm asking about priorities assuming that there isn't time to do
> _all_ the work, which may or may not be true.)
>

It is better to have a working basic BSP, even if it is a bit
complicated to build from scratch, and have a roadmap for how to make
it simpler to use.

>>
>>
>> Reducing what has to be built is an important goal. But an alternative is
>> to host a pre-built binary of what is required to boot. I did that for a
>> boot
>> floppy for the pc386. There were instructions for making one and they
>> worked but, in practice, just grabbing the floppy image was easier.
>
> Since we likely need the entire FreeBSD hard disk image, not just its
> loader.efi file, this may be a file that's a GB or more. (I've been
> using 8GB just to be safe, so I don't know how small we can make
> this.)
>
> We need the entire FreeBSD image because their kernel is one of the
> few that lets us mount a UFS/ZFS filesystem as read-write (which are
> the only filesystems their loader supports loading the kernel from).
>
> IMO, looking for an alternate solution may well be for the best, but I
> also think it can wait until after we have interrupts and the clock
> driver.
>
> Roughly in the order listed here:
> https://blog.whatthedude.com/post/gsoc-phase-2-status/#upcoming
>
>>
>> Note; you didn't need to use a real floppy. Telling qemu what file
>> was the 1.44 MB image was all that was needed. Combine that with
>> vfat for c: and it worked find.
>>
>> So I think we need both -- RSB for building from source and a pre-built
>> binary.
>>
>>>
>>>
>>> > In my opinion, this system is good _enough_ for now - we can explore
>>> > other
>>> > options later if time permits, but I'd love to hear differing opinions.
>>> >
>>> > P.S. - Joel asked earlier if the QEMU that the RSB builds will suffice -
>>> > for me,
>>> > it didn't because in it "SDL support is disabled" (and so are all other
>>> > graphics
>>> > options). It's likely possible to install FreeBSD without graphics, it
>>> > may not
>>> > be worth the effort of setting up - it's likely easier to update the
>>> > RSB's QEMU
>>> > to also build graphics support.
>>> >
>>> I was going to recommend this. You can make it an option of the qemu
>>> configuration in RSB to enable the support needed. I suggest you talk
>>> to Vijay as he has some experience now with RSB, and also this will
>>> require Chris Johns approval.
>>
>>
>> Everything that wasn't needed was disabled to make it easier to build
>> on multiple hosts. Too many projects are Linux monoculture and
>> getting things built on multiple hosts can be a pain.
>>
>> But I think SDL support needs to be enabled since otherwise we have
>> no way to test graphics at all.
>>
>>>
>>>
>>> Relatedly, does it make sense for you to look at creating an RSB
>>> "recipe" for building the UEFI firmware?
>>
>>
>> See above. I think we need RSB recipes for everything required that
>> we expect to be put together by a user. And we should host binaries
>> along with matching sources for some pre-built versions. I don't want
>> this BSP to be an order of magnitude harder to get started with than
>> any of the others.
>
> +1.
>
>>>
>>>
>>> > P.P.S. - Some of the documentation is double-spaced, but this patch
>>> > isn't. Let me
>>> > know if it ought to be (the README didn't say anything of the sort, and
>>> > it isn't
>>> > consistent throughout).
>>> >
>>>
>>> Stick to one consistent approach within your chapters. If consistency
>>> needs to be dealt with across chapters in a manual or across the set
>>> of manuals, that can be done later and simpler if each chapter is
>>> 

Re: [PATCH 0/1] [GSoC - x86_64] User documentation for BSP

[Amaan Cheval]

Hi!

On Fri, Jul 13, 2018 at 7:32 PM, Joel Sherrill  wrote:
>
>
> On Fri, Jul 13, 2018 at 8:25 AM, Gedare Bloom  wrote:
>>
>> Hello Amaan,
>>
>>
>> On Fri, Jul 13, 2018 at 3:32 AM, Amaan Cheval 
>> wrote:
>> > The built documentation can more easily be viewed here:
>> > http://whatthedude.com/rtems/user/html/bsps/bsps-x86_64.html
>> >
>> > It feels a bit convoluted to me at the moment. I'd appreciate feedback
>> > on how
>> > the documentation may be made more understandable, and on whether the
>> > current
>> > approach even seems sustainable - specifically, using FreeBSD's
>> > bootloader ties
>> > us into using the UFS filesystem and can slow down the
>> > iterative-development
>> > process.
>> >
>> I agree. It looks like you have to build FreeBSD at least one time to
>> use this? Alternatives should be again considered for iterative
>> improvement.

That's right, and I agree. The only question is, at what point should
we consider alternatives? After interrupts and the clock driver work
is completed, if there's time left, or before (i.e. right now)?

Is this too large a barrier to entry, and we'd rather make it easier
for future contributors to enter, than to have a more complete BSP
that users and contributors find to be too much effort to practically
use?

(I'm asking about priorities assuming that there isn't time to do
_all_ the work, which may or may not be true.)

>
>
> Reducing what has to be built is an important goal. But an alternative is
> to host a pre-built binary of what is required to boot. I did that for a
> boot
> floppy for the pc386. There were instructions for making one and they
> worked but, in practice, just grabbing the floppy image was easier.

Since we likely need the entire FreeBSD hard disk image, not just its
loader.efi file, this may be a file that's a GB or more. (I've been
using 8GB just to be safe, so I don't know how small we can make
this.)

We need the entire FreeBSD image because their kernel is one of the
few that lets us mount a UFS/ZFS filesystem as read-write (which are
the only filesystems their loader supports loading the kernel from).

IMO, looking for an alternate solution may well be for the best, but I
also think it can wait until after we have interrupts and the clock
driver.

Roughly in the order listed here:
https://blog.whatthedude.com/post/gsoc-phase-2-status/#upcoming

>
> Note; you didn't need to use a real floppy. Telling qemu what file
> was the 1.44 MB image was all that was needed. Combine that with
> vfat for c: and it worked find.
>
> So I think we need both -- RSB for building from source and a pre-built
> binary.
>
>>
>>
>> > In my opinion, this system is good _enough_ for now - we can explore
>> > other
>> > options later if time permits, but I'd love to hear differing opinions.
>> >
>> > P.S. - Joel asked earlier if the QEMU that the RSB builds will suffice -
>> > for me,
>> > it didn't because in it "SDL support is disabled" (and so are all other
>> > graphics
>> > options). It's likely possible to install FreeBSD without graphics, it
>> > may not
>> > be worth the effort of setting up - it's likely easier to update the
>> > RSB's QEMU
>> > to also build graphics support.
>> >
>> I was going to recommend this. You can make it an option of the qemu
>> configuration in RSB to enable the support needed. I suggest you talk
>> to Vijay as he has some experience now with RSB, and also this will
>> require Chris Johns approval.
>
>
> Everything that wasn't needed was disabled to make it easier to build
> on multiple hosts. Too many projects are Linux monoculture and
> getting things built on multiple hosts can be a pain.
>
> But I think SDL support needs to be enabled since otherwise we have
> no way to test graphics at all.
>
>>
>>
>> Relatedly, does it make sense for you to look at creating an RSB
>> "recipe" for building the UEFI firmware?
>
>
> See above. I think we need RSB recipes for everything required that
> we expect to be put together by a user. And we should host binaries
> along with matching sources for some pre-built versions. I don't want
> this BSP to be an order of magnitude harder to get started with than
> any of the others.

+1.

>>
>>
>> > P.P.S. - Some of the documentation is double-spaced, but this patch
>> > isn't. Let me
>> > know if it ought to be (the README didn't say anything of the sort, and
>> > it isn't
>> > consistent throughout).
>> >
>>
>> Stick to one consistent approach within your chapters. If consistency
>> needs to be dealt with across chapters in a manual or across the set
>> of manuals, that can be done later and simpler if each chapter is
>> internally consistent.
>
>
> How did some documentation get to be double-spaced? I thought we
> had a consistent style of single space or something like 1.5. I have
> never even thought of changing the line spacing and don't know how. :)
>
> Sounds like we need to look at fixing the inconsistent places.

I meant that the source file has 2 spaces after punctuation 

Re: Gcov support in Covoar

[Vijay Kumar Banerjee]

On 18 July 2018 at 02:30, Joel Sherrill  wrote:

> This definitely looks like the right direction. If we don't understand
> the file formats, we will never be able to process and correlate them.
>
> Please put 0x in front of hex numbers. It does help.
>
> Can you explain the fields in gcno_dump.txt? The Version field
> looks like hex for R37A which doesn't make sense to me. Reading the
> header in gcov-io.h, I wonder how it matches this pattern?
>
> it should be A73R, I have corrected it.
I have tried to give some description in the code itself.
I'll write a detailed description of each field once it's complete.
Maybe a blog post will be nice.

> 
> Although the ident and version are formally 32 bit numbers, they
>are derived from 4 character ASCII strings.  The version number
>consists of a two character major version number
>(first digit starts from 'A' letter to not to clash with the older
>numbering scheme), the single character minor version number,
>and a single character indicating the status of the release.
>That will be 'e' experimental, 'p' prerelease and 'r' for release.
>Because, by good fortune, these are in alphabetical order, string
>collating can be used to compare version strings.  Be aware that
>the 'e' designation will (naturally) be unstable and might be
>incompatible with itself.  For gcc 17.0 experimental, it would be
>'B70e' (0x42373065).  As we currently do not release more than 5 minor
>releases, the single character should be always fine.  Major number
>is currently changed roughly every year, which gives us space
>for next 250 years (maximum allowed number would be 259.9).
> 
>
>
> The timestamp field also doesn't make sense to me. Assuming that
> is a hex number, it has a LOT of digits and https://www.epochconverter.
> com/
> tells me that it is sometime in 2741
>
> There was some issue with it because I was taking signed int.
I fixed it.

> Maybe you have the endianness of some of the fields wrong.
>
> Yes the endianness was wrong.
I have uploaded the code to a github repository so that it can be
visible and progress can be trackable.

https://github.com/thelunatic/gcno_dumper.git

I am working on figuring out how the file is organised, I'll
post the generated txt file soon.

> But this is what it takes to understand it. :)
>
> --joel
>
>
> On Sat, Jul 14, 2018 at 4:29 PM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> Hello,
>>
>> As suggested by Joel, I have tried to figure out the structure of
>> the gcno files and written a gcno dumper.
>> This is not complete yet, I'm still working on it and I'll keep adding
>> to it as I "decode" the gcno files.
>>
>> I'm attaching the c++ code, the gcno file I'm testing on and the txt
>> file generated from it.
>>
>> please have a look. Is it moving in the right direction ?
>>
>> On 12 July 2018 at 03:56, Vijay Kumar Banerjee 
>> wrote:
>>
>>> I have filed a ticket for gcov, as suggested by Joel.
>>>
>>> https://devel.rtems.org/ticket/3468
>>>
>>> -- vijay
>>>
>>> On 8 July 2018 at 01:43, Chris Johns  wrote:
>>>
 On 8/7/18 7:51 am, Vijay Kumar Banerjee wrote:
 > On 8 July 2018 at 01:08, Joel Sherrill >>> j...@rtems.org>>
 > wrote:
 >
 > On Sat, Jul 7, 2018, 2:33 PM Chris Johns <
 ch...@contemporary.net.au
 > > wrote:
 >
 > On 5 Jul 2018, at 3:07 am, Joel Sherrill >>> > 
 > >> wrote:
 > > On Wed, Jul 4, 2018, 3:06 AM Chris Johns >>> 
 > > >> wrote:
 > >
 > > How does this fit into the RTEMS Tester tool?
 > >
 > >
 > > If you want to run gcov or lcov on uninstrumented
 executables, then covoar has
 > > to read gcno and write gcda files. And we have to then run
 gcov or lcov as
 > > normal.
 >
 >
 > This is just a description of how it works. Not a particular
 change.
 >
 > >
 > > It is the path to another report format.
 >
 > I am not sure I understand how we make this work and how we
 support the
 > user. Is
 > this an option to 'rtems-test'?
 >
 > The aim of the 'rtems-test' command is to provide a
 documented user
 > interface.
 > Providing direct access to covoar adds more documentation and
 > complication to
 > the test tool. For example how does the user wanting gcov
 output get to the
 > trace files? The user would need to step into how we
 implement coverage
 > and that
 > is an interface we will not document and change.
 >
 >

Re: [GSoC - x86_64] Clock driver - which hardware source to support primarily?

[Amaan Cheval]

Hey!

On Wed, Jul 18, 2018 at 11:01 AM, Sebastian Huber
 wrote:
> Hello Amaan,
>
> On 17/07/18 19:18, Amaan Cheval wrote:
>>
>> Hi!
>>
>> Now that I'm working on the clock driver, we need to pick what we
>> support first. Our options in brief are:
>
>
> The clock driver needs an interrupt. What is the status of the interrupt
> controller support in the BSP?

TL;DR: There is none. We've been using the idle-thread simulation and
left interrupts disabled from the get-go.

>
> For timekeeping we use a port of the FreeBSD timecounter in RTEMS. You may
> have a look at the FreeBSD timecounter for this architecture, e.g.
> sys/x86/x86/tsc.c. I looks quite complicated.

Right, it goes to show the flaw with the TSC - it needs calibration
(FreeBSD seems to try to use CPUID and model names, etc. to detect the
frequency instead of using the PIT), and synchronization across
different cores in SMP configurations.

The APIC timers are local to each core, but are also synchronized
because they are based on a common bus signal.

(See this for more pros/cons of each timer:
https://www.halobates.de/timers2.pdf)

> I would not take to much care
> about legacy support, e.g. ignore hardware which is older than five years?.

That's a fair guideline, thanks!

>
> --
> 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

[PATCH 44/45] libfdt: Add necessary header padding in fdt_create()

[Sebastian Huber]

From: David Gibson 

At present fdt_create() will succeed if there is exactly enough space to
put in the fdt header.  However, it sets the off_mem_rsvmap field, a few
bytes past that in order to align the memory reservation block.

Having block pointers pointing past the end of the fdt is pretty ugly, even
if it is just a transient state.  Worse, if fdt_resize() is called at
exactly the wrong time, it can end up accessing data past the blob's
allocated space because of this.

So, correct fdt_create() to ensure that there is sufficient space for the
alignment padding as well as the plain header.  For paranoia, also add a
check in fdt_resize() to make sure we don't copy data from outside the
blob's bounds.

Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_sw.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt_sw.c b/cpukit/dtc/libfdt/fdt_sw.c
index 024f4d85de..9fa4a94d83 100644
--- a/cpukit/dtc/libfdt/fdt_sw.c
+++ b/cpukit/dtc/libfdt/fdt_sw.c
@@ -143,9 +143,11 @@ static void *fdt_grab_space_(void *fdt, size_t len)
 
 int fdt_create(void *buf, int bufsize)
 {
+   const size_t hdrsize = FDT_ALIGN(sizeof(struct fdt_header),
+sizeof(struct fdt_reserve_entry));
void *fdt = buf;
 
-   if (bufsize < sizeof(struct fdt_header))
+   if (bufsize < hdrsize)
return -FDT_ERR_NOSPACE;
 
memset(buf, 0, bufsize);
@@ -155,8 +157,7 @@ int fdt_create(void *buf, int bufsize)
fdt_set_last_comp_version(fdt, FDT_FIRST_SUPPORTED_VERSION);
fdt_set_totalsize(fdt,  bufsize);
 
-   fdt_set_off_mem_rsvmap(fdt, FDT_ALIGN(sizeof(struct fdt_header),
- sizeof(struct 
fdt_reserve_entry)));
+   fdt_set_off_mem_rsvmap(fdt, hdrsize);
fdt_set_off_dt_struct(fdt, fdt_off_mem_rsvmap(fdt));
fdt_set_off_dt_strings(fdt, 0);
 
@@ -173,6 +174,9 @@ int fdt_resize(void *fdt, void *buf, int bufsize)
headsize = fdt_off_dt_struct(fdt) + fdt_size_dt_struct(fdt);
tailsize = fdt_size_dt_strings(fdt);
 
+   if ((headsize + tailsize) > fdt_totalsize(fdt))
+   return -FDT_ERR_INTERNAL;
+
if ((headsize + tailsize) > bufsize)
return -FDT_ERR_NOSPACE;
 
-- 
2.13.7

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

[PATCH 43/45] libfdt: Copy the struct region in fdt_resize()

[Sebastian Huber]

From: Simon Glass 

At present this function appears to copy only the data before the struct
region and the data in the string region. It does not seem to copy the
struct region itself.

>From the arguments of this function it seems that it should support fdt
and buf being different. This patch attempts to fix this problem.

Signed-off-by: Simon Glass 
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_sw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/dtc/libfdt/fdt_sw.c b/cpukit/dtc/libfdt/fdt_sw.c
index 178b3657b0..024f4d85de 100644
--- a/cpukit/dtc/libfdt/fdt_sw.c
+++ b/cpukit/dtc/libfdt/fdt_sw.c
@@ -170,7 +170,7 @@ int fdt_resize(void *fdt, void *buf, int bufsize)
 
FDT_SW_PROBE(fdt);
 
-   headsize = fdt_off_dt_struct(fdt);
+   headsize = fdt_off_dt_struct(fdt) + fdt_size_dt_struct(fdt);
tailsize = fdt_size_dt_strings(fdt);
 
if ((headsize + tailsize) > bufsize)
-- 
2.13.7

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

[PATCH 39/45] libfdt: Add fdt_header_size()

[Sebastian Huber]

From: David Gibson 

We have a couple of places within libfdt and its tests where we need to
find the size of the header, based on the version.  Add a helper function
for it.

Signed-off-by: David Gibson 
Reviewed-by: Simon Glass 
Tested-by: Alexey Kardashevskiy 
Reviewed-by: Alexey Kardashevskiy 
---
 cpukit/dtc/libfdt/fdt.c | 20 
 cpukit/include/libfdt.h | 11 +++
 2 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt.c b/cpukit/dtc/libfdt/fdt.c
index 5f1e57a5bd..ae03b11129 100644
--- a/cpukit/dtc/libfdt/fdt.c
+++ b/cpukit/dtc/libfdt/fdt.c
@@ -96,21 +96,33 @@ static int check_block_(uint32_t hdrsize, uint32_t 
totalsize,
return 1;
 }
 
+size_t fdt_header_size_(uint32_t version)
+{
+   if (version <= 1)
+   return FDT_V1_SIZE;
+   else if (version <= 2)
+   return FDT_V2_SIZE;
+   else if (version <= 3)
+   return FDT_V3_SIZE;
+   else if (version <= 16)
+   return FDT_V16_SIZE;
+   else
+   return FDT_V17_SIZE;
+}
+
 int fdt_check_header(const void *fdt)
 {
-   size_t hdrsize = FDT_V16_SIZE;
+   size_t hdrsize;
 
if (fdt_magic(fdt) != FDT_MAGIC)
return -FDT_ERR_BADMAGIC;
+   hdrsize = fdt_header_size(fdt);
if ((fdt_version(fdt) < FDT_FIRST_SUPPORTED_VERSION)
|| (fdt_last_comp_version(fdt) > FDT_LAST_SUPPORTED_VERSION))
return -FDT_ERR_BADVERSION;
if (fdt_version(fdt) < fdt_last_comp_version(fdt))
return -FDT_ERR_BADVERSION;
 
-   if (fdt_version(fdt) >= 17)
-   hdrsize = FDT_V17_SIZE;
-
if ((fdt_totalsize(fdt) < hdrsize)
|| (fdt_totalsize(fdt) > INT_MAX))
return -FDT_ERR_TRUNCATED;
diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index b50af54296..b81d046e54 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -245,7 +245,18 @@ fdt_set_hdr_(size_dt_struct);
 #undef fdt_set_hdr_
 
 /**
+ * fdt_header_size - return the size of the tree's header
+ * @fdt: pointer to a flattened device tree
+ */
+size_t fdt_header_size_(uint32_t version);
+static inline size_t fdt_header_size(const void *fdt)
+{
+   return fdt_header_size_(fdt_version(fdt));
+}
+
+/**
  * fdt_check_header - sanity check a device tree header
+
  * @fdt: pointer to data which might be a flattened device tree
  *
  * fdt_check_header() checks that the given buffer contains what
-- 
2.13.7

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

[PATCH 33/45] libfdt: Clean up header checking functions

[Sebastian Huber]

From: David Gibson 

Many of the libfdt entry points call some sort of sanity check function
before doing anything else.  These need to do slightly different things for
the various classes of functions.

The read-only version is shared with the exported fdt_check_header(), which
limits us a bit in how we can improve it.  For that reason split the two
functions apart (though the exported one just calls the ro one for now).

We also rename the functions for more consistency - they're all named
fdt_XX_probe_() where the XX indicates which class of functions they're
for.  "probe" is a better "term" than the previous check, since they really
only do minimal validation.

Signed-off-by: David Gibson 
Tested-by: Alexey Kardashevskiy 
Reviewed-by: Alexey Kardashevskiy 
---
 cpukit/dtc/libfdt/fdt.c | 14 --
 cpukit/dtc/libfdt/fdt_ro.c  | 18 +-
 cpukit/dtc/libfdt/fdt_rw.c  | 28 ++--
 cpukit/dtc/libfdt/fdt_sw.c  | 18 +-
 cpukit/dtc/libfdt/libfdt_internal.h |  5 +++--
 5 files changed, 47 insertions(+), 36 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt.c b/cpukit/dtc/libfdt/fdt.c
index 7855a17877..8bbf2dc894 100644
--- a/cpukit/dtc/libfdt/fdt.c
+++ b/cpukit/dtc/libfdt/fdt.c
@@ -55,7 +55,12 @@
 
 #include "libfdt_internal.h"
 
-int fdt_check_header(const void *fdt)
+/*
+ * Minimal sanity check for a read-only tree. fdt_ro_probe_() checks
+ * that the given buffer contains what appears to be a flattened
+ * device tree with sane information in its header.
+ */
+int fdt_ro_probe_(const void *fdt)
 {
if (fdt_magic(fdt) == FDT_MAGIC) {
/* Complete tree */
@@ -74,6 +79,11 @@ int fdt_check_header(const void *fdt)
return 0;
 }
 
+int fdt_check_header(const void *fdt)
+{
+   return fdt_ro_probe_(fdt);
+}
+
 const void *fdt_offset_ptr(const void *fdt, int offset, unsigned int len)
 {
unsigned absoffset = offset + fdt_off_dt_struct(fdt);
@@ -244,7 +254,7 @@ const char *fdt_find_string_(const char *strtab, int 
tabsize, const char *s)
 
 int fdt_move(const void *fdt, void *buf, int bufsize)
 {
-   FDT_CHECK_HEADER(fdt);
+   FDT_RO_PROBE(fdt);
 
if (fdt_totalsize(fdt) > bufsize)
return -FDT_ERR_NOSPACE;
diff --git a/cpukit/dtc/libfdt/fdt_ro.c b/cpukit/dtc/libfdt/fdt_ro.c
index dfb3236da3..4f4ef44a3a 100644
--- a/cpukit/dtc/libfdt/fdt_ro.c
+++ b/cpukit/dtc/libfdt/fdt_ro.c
@@ -117,7 +117,7 @@ uint32_t fdt_get_max_phandle(const void *fdt)
 
 int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size)
 {
-   FDT_CHECK_HEADER(fdt);
+   FDT_RO_PROBE(fdt);
*address = fdt64_to_cpu(fdt_mem_rsv_(fdt, n)->address);
*size = fdt64_to_cpu(fdt_mem_rsv_(fdt, n)->size);
return 0;
@@ -161,7 +161,7 @@ int fdt_subnode_offset_namelen(const void *fdt, int offset,
 {
int depth;
 
-   FDT_CHECK_HEADER(fdt);
+   FDT_RO_PROBE(fdt);
 
for (depth = 0;
 (offset >= 0) && (depth >= 0);
@@ -187,7 +187,7 @@ int fdt_path_offset_namelen(const void *fdt, const char 
*path, int namelen)
const char *p = path;
int offset = 0;
 
-   FDT_CHECK_HEADER(fdt);
+   FDT_RO_PROBE(fdt);
 
/* see if we have an alias */
if (*path != '/') {
@@ -237,7 +237,7 @@ const char *fdt_get_name(const void *fdt, int nodeoffset, 
int *len)
const char *nameptr;
int err;
 
-   if (((err = fdt_check_header(fdt)) != 0)
+   if (((err = fdt_ro_probe_(fdt)) != 0)
|| ((err = fdt_check_node_offset_(fdt, nodeoffset)) < 0))
goto fail;
 
@@ -462,7 +462,7 @@ int fdt_get_path(const void *fdt, int nodeoffset, char 
*buf, int buflen)
int offset, depth, namelen;
const char *name;
 
-   FDT_CHECK_HEADER(fdt);
+   FDT_RO_PROBE(fdt);
 
if (buflen < 2)
return -FDT_ERR_NOSPACE;
@@ -514,7 +514,7 @@ int fdt_supernode_atdepth_offset(const void *fdt, int 
nodeoffset,
int offset, depth;
int supernodeoffset = -FDT_ERR_INTERNAL;
 
-   FDT_CHECK_HEADER(fdt);
+   FDT_RO_PROBE(fdt);
 
if (supernodedepth < 0)
return -FDT_ERR_NOTFOUND;
@@ -573,7 +573,7 @@ int fdt_node_offset_by_prop_value(const void *fdt, int 
startoffset,
const void *val;
int len;
 
-   FDT_CHECK_HEADER(fdt);
+   FDT_RO_PROBE(fdt);
 
/* FIXME: The algorithm here is pretty horrible: we scan each
 * property of a node in fdt_getprop(), then if that didn't
@@ -599,7 +599,7 @@ int fdt_node_offset_by_phandle(const void *fdt, uint32_t 
phandle)
if ((phandle == 0) || (phandle == -1))
return -FDT_ERR_BADPHANDLE;
 
-   FDT_CHECK_HEADER(fdt);
+   FDT_RO_PROBE(fdt);
 
/* FIXME: The algorithm here is pretty horrible: we
 * potentially scan each property of a node in
@@ -752,7 +752,7 @@ int fdt_node_offset_by_compatible(const void 

[PATCH 36/45] libfdt: Safer access to strings section

[Sebastian Huber]

From: David Gibson 

fdt_string() is used to retrieve strings from a DT blob's strings section.
It's rarely used directly, but is widely used internally.

However, it doesn't do any bounds checking, which means in the case of a
corrupted blob it could access bad memory, which libfdt is supposed to
avoid.

This write a safe alternative to fdt_string, fdt_get_string().  It checks
both that the given offset is within the string section and that the string
it points to is properly \0 terminated within the section.  It also returns
the string's length as a convenience (since it needs to determine to do the
checks anyway).

fdt_string() is rewritten in terms of fdt_get_string() for compatibility.

Most of the diff here is actually testing infrastructure.

Signed-off-by: David Gibson 
Tested-by: Alexey Kardashevskiy 
Reviewed-by: Alexey Kardashevskiy 
---
 cpukit/dtc/libfdt/fdt_ro.c | 61 +++---
 cpukit/include/libfdt.h| 18 +-
 2 files changed, 75 insertions(+), 4 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt_ro.c b/cpukit/dtc/libfdt/fdt_ro.c
index 4f4ef44a3a..347aa7bc8d 100644
--- a/cpukit/dtc/libfdt/fdt_ro.c
+++ b/cpukit/dtc/libfdt/fdt_ro.c
@@ -76,17 +76,72 @@ static int fdt_nodename_eq_(const void *fdt, int offset,
return 0;
 }
 
+const char *fdt_get_string(const void *fdt, int stroffset, int *lenp)
+{
+   uint32_t absoffset = stroffset + fdt_off_dt_strings(fdt);
+   size_t len;
+   int err;
+   const char *s, *n;
+
+   err = fdt_ro_probe_(fdt);
+   if (err != 0)
+   goto fail;
+
+   err = -FDT_ERR_BADOFFSET;
+   if (absoffset >= fdt_totalsize(fdt))
+   goto fail;
+   len = fdt_totalsize(fdt) - absoffset;
+
+   if (fdt_magic(fdt) == FDT_MAGIC) {
+   if (stroffset < 0)
+   goto fail;
+   if (fdt_version(fdt) >= 17) {
+   if (stroffset >= fdt_size_dt_strings(fdt))
+   goto fail;
+   if ((fdt_size_dt_strings(fdt) - stroffset) < len)
+   len = fdt_size_dt_strings(fdt) - stroffset;
+   }
+   } else if (fdt_magic(fdt) == FDT_SW_MAGIC) {
+   if ((stroffset >= 0)
+   || (stroffset < -fdt_size_dt_strings(fdt)))
+   goto fail;
+   if ((-stroffset) < len)
+   len = -stroffset;
+   } else {
+   err = -FDT_ERR_INTERNAL;
+   goto fail;
+   }
+
+   s = (const char *)fdt + absoffset;
+   n = memchr(s, '\0', len);
+   if (!n) {
+   /* missing terminating NULL */
+   err = -FDT_ERR_TRUNCATED;
+   goto fail;
+   }
+
+   if (lenp)
+   *lenp = n - s;
+   return s;
+
+fail:
+   if (lenp)
+   *lenp = err;
+   return NULL;
+}
+
 const char *fdt_string(const void *fdt, int stroffset)
 {
-   return (const char *)fdt + fdt_off_dt_strings(fdt) + stroffset;
+   return fdt_get_string(fdt, stroffset, NULL);
 }
 
 static int fdt_string_eq_(const void *fdt, int stroffset,
  const char *s, int len)
 {
-   const char *p = fdt_string(fdt, stroffset);
+   int slen;
+   const char *p = fdt_get_string(fdt, stroffset, );
 
-   return (strlen(p) == len) && (memcmp(p, s, len) == 0);
+   return p && (slen == len) && (memcmp(p, s, len) == 0);
 }
 
 uint32_t fdt_get_max_phandle(const void *fdt)
diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index 837c5e27ee..b50af54296 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -288,6 +288,22 @@ int fdt_move(const void *fdt, void *buf, int bufsize);
 /**/
 
 /**
+ * fdt_get_string - retrieve a string from the strings block of a device tree
+ * @fdt: pointer to the device tree blob
+ * @stroffset: offset of the string within the strings block (native endian)
+ * @lenp: optional pointer to return the string's length
+ *
+ * fdt_get_string() retrieves a pointer to a single string from the
+ * strings block of the device tree blob at fdt, and optionally also
+ * returns the string's length in *lenp.
+ *
+ * returns:
+ * a pointer to the string, on success
+ * NULL, if stroffset is out of bounds, or doesn't point to a valid string
+ */
+const char *fdt_get_string(const void *fdt, int stroffset, int *lenp);
+
+/**
  * fdt_string - retrieve a string from the strings block of a device tree
  * @fdt: pointer to the device tree blob
  * @stroffset: offset of the string within the strings block (native endian)
@@ -297,7 +313,7 @@ int fdt_move(const void *fdt, void *buf, int bufsize);
  *
  * returns:
  * a pointer to the string, on success
- * NULL, if stroffset is out of bounds
+ * NULL, if stroffset is out of bounds, or doesn't point to a valid string
  */
 

[PATCH 34/45] libfdt: Improve sequential write state checking

[Sebastian Huber]

From: David Gibson 

When creating a tree with the sequential write functions, certain things
have to be done in a certain order.  You must create the memory reserve map
and only then can you create the actual tree structure.

The -FDT_ERR_BADSTATE return code is for if you try to do things out of
order.  However, we weren't checking that very thoroughly, so it was
possible to generate a corrupted blob if, for example, you started calling
fdt_begin_node() etc. before calling fdt_finish_reservemap().

This makes the state checking more thorough disallow that.

Signed-off-by: David Gibson 
Tested-by: Alexey Kardashevskiy 
Reviewed-by: Alexey Kardashevskiy 
Reviewed-by: Simon Glass 
---
 cpukit/dtc/libfdt/fdt_sw.c | 89 ++
 1 file changed, 75 insertions(+), 14 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt_sw.c b/cpukit/dtc/libfdt/fdt_sw.c
index 9f6fe2085d..178b3657b0 100644
--- a/cpukit/dtc/libfdt/fdt_sw.c
+++ b/cpukit/dtc/libfdt/fdt_sw.c
@@ -57,9 +57,10 @@
 
 static int fdt_sw_probe_(void *fdt)
 {
-   if (fdt_magic(fdt) != FDT_SW_MAGIC)
+   if (fdt_magic(fdt) == FDT_MAGIC)
+   return -FDT_ERR_BADSTATE;
+   else if (fdt_magic(fdt) != FDT_SW_MAGIC)
return -FDT_ERR_BADMAGIC;
-   /* FIXME: should check more details about the header state */
return 0;
 }
 
@@ -70,6 +71,61 @@ static int fdt_sw_probe_(void *fdt)
return err; \
}
 
+/* 'memrsv' state: Initial state after fdt_create()
+ *
+ * Allowed functions:
+ * fdt_add_reservmap_entry()
+ * fdt_finish_reservemap() [moves to 'struct' state]
+ */
+static int fdt_sw_probe_memrsv_(void *fdt)
+{
+   int err = fdt_sw_probe_(fdt);
+   if (err)
+   return err;
+
+   if (fdt_off_dt_strings(fdt) != 0)
+   return -FDT_ERR_BADSTATE;
+   return 0;
+}
+
+#define FDT_SW_PROBE_MEMRSV(fdt) \
+   { \
+   int err; \
+   if ((err = fdt_sw_probe_memrsv_(fdt)) != 0) \
+   return err; \
+   }
+
+/* 'struct' state: Enter this state after fdt_finish_reservemap()
+ *
+ * Allowed functions:
+ * fdt_begin_node()
+ * fdt_end_node()
+ * fdt_property*()
+ * fdt_finish()[moves to 'complete' state]
+ */
+static int fdt_sw_probe_struct_(void *fdt)
+{
+   int err = fdt_sw_probe_(fdt);
+   if (err)
+   return err;
+
+   if (fdt_off_dt_strings(fdt) != fdt_totalsize(fdt))
+   return -FDT_ERR_BADSTATE;
+   return 0;
+}
+
+#define FDT_SW_PROBE_STRUCT(fdt) \
+   { \
+   int err; \
+   if ((err = fdt_sw_probe_struct_(fdt)) != 0) \
+   return err; \
+   }
+
+/* 'complete' state:   Enter this state after fdt_finish()
+ *
+ * Allowed functions: none
+ */
+
 static void *fdt_grab_space_(void *fdt, size_t len)
 {
int offset = fdt_size_dt_struct(fdt);
@@ -102,7 +158,7 @@ int fdt_create(void *buf, int bufsize)
fdt_set_off_mem_rsvmap(fdt, FDT_ALIGN(sizeof(struct fdt_header),
  sizeof(struct 
fdt_reserve_entry)));
fdt_set_off_dt_struct(fdt, fdt_off_mem_rsvmap(fdt));
-   fdt_set_off_dt_strings(fdt, bufsize);
+   fdt_set_off_dt_strings(fdt, 0);
 
return 0;
 }
@@ -133,8 +189,9 @@ int fdt_resize(void *fdt, void *buf, int bufsize)
memmove(buf, fdt, headsize);
}
 
-   fdt_set_off_dt_strings(buf, bufsize);
fdt_set_totalsize(buf, bufsize);
+   if (fdt_off_dt_strings(buf))
+   fdt_set_off_dt_strings(buf, bufsize);
 
return 0;
 }
@@ -144,10 +201,7 @@ int fdt_add_reservemap_entry(void *fdt, uint64_t addr, 
uint64_t size)
struct fdt_reserve_entry *re;
int offset;
 
-   FDT_SW_PROBE(fdt);
-
-   if (fdt_size_dt_struct(fdt))
-   return -FDT_ERR_BADSTATE;
+   FDT_SW_PROBE_MEMRSV(fdt);
 
offset = fdt_off_dt_struct(fdt);
if ((offset + sizeof(*re)) > fdt_totalsize(fdt))
@@ -164,16 +218,23 @@ int fdt_add_reservemap_entry(void *fdt, uint64_t addr, 
uint64_t size)
 
 int fdt_finish_reservemap(void *fdt)
 {
-   return fdt_add_reservemap_entry(fdt, 0, 0);
+   int err = fdt_add_reservemap_entry(fdt, 0, 0);
+
+   if (err)
+   return err;
+
+   fdt_set_off_dt_strings(fdt, fdt_totalsize(fdt));
+   return 0;
 }
 
 int fdt_begin_node(void *fdt, const char *name)
 {
struct fdt_node_header *nh;
-   int namelen = strlen(name) + 1;
+   int namelen;
 
-   FDT_SW_PROBE(fdt);
+   FDT_SW_PROBE_STRUCT(fdt);
 
+   namelen = strlen(name) + 1;
nh = fdt_grab_space_(fdt, sizeof(*nh) + FDT_TAGALIGN(namelen));
if (! nh)
return -FDT_ERR_NOSPACE;
@@ -187,7 +248,7 @@ int fdt_end_node(void *fdt)
 {
fdt32_t *en;
 
-   FDT_SW_PROBE(fdt);
+   FDT_SW_PROBE_STRUCT(fdt);
 
en = 

[PATCH 20/45] libfdt: fix fdt_stringlist_search()

[Sebastian Huber]

From: Masahiro Yamada 

If fdt_getprop() fails, negative error code should be returned.

Signed-off-by: Masahiro Yamada 
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_ro.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/dtc/libfdt/fdt_ro.c b/cpukit/dtc/libfdt/fdt_ro.c
index db8d10fcd4..3d00d2eee0 100644
--- a/cpukit/dtc/libfdt/fdt_ro.c
+++ b/cpukit/dtc/libfdt/fdt_ro.c
@@ -597,7 +597,7 @@ int fdt_stringlist_search(const void *fdt, int nodeoffset, 
const char *property,
 
list = fdt_getprop(fdt, nodeoffset, property, );
if (!list)
-   return -length;
+   return length;
 
len = strlen(string) + 1;
end = list + length;
-- 
2.13.7

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

Re: [PATCH 01/45] libfdt: check for potential overrun in _fdt_splice()

[Sebastian Huber]

Sorry, I forgot the cover letter.

This patch series update the libfdt to the latest upstream version, see also

https://devel.rtems.org/ticket/3471

--
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

[PATCH 41/45] pylibfdt: Add functions to update properties

[Sebastian Huber]

From: Simon Glass 

Allow updating and creating properties, including special methods for
integers.

Signed-off-by: Simon Glass 
Reviewed-by: David Gibson 
Signed-off-by: David Gibson 
---
 cpukit/include/libfdt.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index 79e4d82619..c99d28fea5 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -1345,10 +1345,13 @@ static inline int fdt_property_u64(void *fdt, const 
char *name, uint64_t val)
fdt64_t tmp = cpu_to_fdt64(val);
return fdt_property(fdt, name, , sizeof(tmp));
 }
+
+#ifndef SWIG /* Not available in Python */
 static inline int fdt_property_cell(void *fdt, const char *name, uint32_t val)
 {
return fdt_property_u32(fdt, name, val);
 }
+#endif
 
 /**
  * fdt_property_placeholder - add a new property and return a ptr to its value
-- 
2.13.7

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

[PATCH 42/45] libfdt: Add helpers for accessing unaligned words

[Sebastian Huber]

From: David Gibson 

This adds some helpers to load (32 or 64 bit) words from an fdt blob, even
if they're unaligned and we're on a platform that doesn't like plain
unaligned loads and stores.  We then use the helpers in a number of places.
There are two purposes for this:

1) This makes libfdt more robust against a blob loaded at an unaligned
   address.  It's usually good practice to load a blob at a 64-bit
   alignment, but it's nice to work even then.

2) Users can use these helpers to load integer values from within property
   values.  These can often be unaligned, even if the blob as a whole is
   aligned, since some property encodings have integers and strings mixed
   together without any alignment gaps.

Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_ro.c | 18 +-
 cpukit/include/libfdt.h| 25 -
 2 files changed, 33 insertions(+), 10 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt_ro.c b/cpukit/dtc/libfdt/fdt_ro.c
index 4ba7c93313..eafc142828 100644
--- a/cpukit/dtc/libfdt/fdt_ro.c
+++ b/cpukit/dtc/libfdt/fdt_ro.c
@@ -191,8 +191,8 @@ int fdt_get_mem_rsv(const void *fdt, int n, uint64_t 
*address, uint64_t *size)
if (!re)
return -FDT_ERR_BADOFFSET;
 
-   *address = fdt64_to_cpu(re->address);
-   *size = fdt64_to_cpu(re->size);
+   *address = fdt64_ld(>address);
+   *size = fdt64_ld(>size);
return 0;
 }
 
@@ -202,7 +202,7 @@ int fdt_num_mem_rsv(const void *fdt)
const struct fdt_reserve_entry *re;
 
for (i = 0; (re = fdt_mem_rsv(fdt, i)) != NULL; i++) {
-   if (fdt64_to_cpu(re->size) == 0)
+   if (fdt64_ld(>size) == 0)
return i;
}
return -FDT_ERR_TRUNCATED;
@@ -379,7 +379,7 @@ static const struct fdt_property 
*fdt_get_property_by_offset_(const void *fdt,
prop = fdt_offset_ptr_(fdt, offset);
 
if (lenp)
-   *lenp = fdt32_to_cpu(prop->len);
+   *lenp = fdt32_ld(>len);
 
return prop;
 }
@@ -416,7 +416,7 @@ static const struct fdt_property 
*fdt_get_property_namelen_(const void *fdt,
offset = -FDT_ERR_INTERNAL;
break;
}
-   if (fdt_string_eq_(fdt, fdt32_to_cpu(prop->nameoff),
+   if (fdt_string_eq_(fdt, fdt32_ld(>nameoff),
   name, namelen)) {
if (poffset)
*poffset = offset;
@@ -469,7 +469,7 @@ const void *fdt_getprop_namelen(const void *fdt, int 
nodeoffset,
 
/* Handle realignment */
if (fdt_version(fdt) < 0x10 && (poffset + sizeof(*prop)) % 8 &&
-   fdt32_to_cpu(prop->len) >= 8)
+   fdt32_ld(>len) >= 8)
return prop->data + 4;
return prop->data;
 }
@@ -485,7 +485,7 @@ const void *fdt_getprop_by_offset(const void *fdt, int 
offset,
if (namep) {
const char *name;
int namelen;
-   name = fdt_get_string(fdt, fdt32_to_cpu(prop->nameoff),
+   name = fdt_get_string(fdt, fdt32_ld(>nameoff),
  );
if (!name) {
if (lenp)
@@ -497,7 +497,7 @@ const void *fdt_getprop_by_offset(const void *fdt, int 
offset,
 
/* Handle realignment */
if (fdt_version(fdt) < 0x10 && (offset + sizeof(*prop)) % 8 &&
-   fdt32_to_cpu(prop->len) >= 8)
+   fdt32_ld(>len) >= 8)
return prop->data + 4;
return prop->data;
 }
@@ -522,7 +522,7 @@ uint32_t fdt_get_phandle(const void *fdt, int nodeoffset)
return 0;
}
 
-   return fdt32_to_cpu(*php);
+   return fdt32_ld(php);
 }
 
 const char *fdt_get_alias_namelen(const void *fdt,
diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index c99d28fea5..38ec313094 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -154,6 +154,29 @@ static inline void *fdt_offset_ptr_w(void *fdt, int 
offset, int checklen)
 
 uint32_t fdt_next_tag(const void *fdt, int offset, int *nextoffset);
 
+/*
+ * Alignment helpers:
+ * These helpers access words from a device tree blob.  They're
+ * built to work even with unaligned pointers on platforms (ike
+ * ARM) that don't like unaligned loads and stores
+ */
+
+static inline uint32_t fdt32_ld(const fdt32_t *p)
+{
+   fdt32_t v;
+
+   memcpy(, p, sizeof(v));
+   return fdt32_to_cpu(v);
+}
+
+static inline uint64_t fdt64_ld(const fdt64_t *p)
+{
+   fdt64_t v;
+
+   memcpy(, p, sizeof(v));
+   return fdt64_to_cpu(v);
+}
+
 /**/
 /* Traversal functions*/
 /**/
@@ -214,7 +237,7 @@ int fdt_next_subnode(const void *fdt, int offset);
 /* General 

[PATCH 16/45] libfdt: Add overlay application function

[Sebastian Huber]

From: Maxime Ripard 

The device tree overlays are a good way to deal with user-modifyable
boards or boards with some kind of an expansion mechanism where we can
easily plug new board in (like the BBB, the Raspberry Pi or the CHIP).

Add a new function to merge overlays with a base device tree.

Signed-off-by: Maxime Ripard 
Signed-off-by: David Gibson 
---
 cpukit/include/libfdt.h | 31 +++
 cpukit/include/libfdt_env.h |  1 +
 2 files changed, 32 insertions(+)

diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index d2e5e031fb..c69e918899 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -1763,6 +1763,37 @@ int fdt_add_subnode(void *fdt, int parentoffset, const 
char *name);
  */
 int fdt_del_node(void *fdt, int nodeoffset);
 
+/**
+ * fdt_overlay_apply - Applies a DT overlay on a base DT
+ * @fdt: pointer to the base device tree blob
+ * @fdto: pointer to the device tree overlay blob
+ *
+ * fdt_overlay_apply() will apply the given device tree overlay on the
+ * given base device tree.
+ *
+ * Expect the base device tree to be modified, even if the function
+ * returns an error.
+ *
+ * returns:
+ * 0, on success
+ * -FDT_ERR_NOSPACE, there's not enough space in the base device tree
+ * -FDT_ERR_NOTFOUND, the overlay points to some inexistant nodes or
+ * properties in the base DT
+ * -FDT_ERR_BADPHANDLE,
+ * -FDT_ERR_BADOVERLAY,
+ * -FDT_ERR_NOPHANDLES,
+ * -FDT_ERR_INTERNAL,
+ * -FDT_ERR_BADLAYOUT,
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADOFFSET,
+ * -FDT_ERR_BADPATH,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTRUCTURE,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_overlay_apply(void *fdt, void *fdto);
+
 /**/
 /* Debugging / informational functions*/
 /**/
diff --git a/cpukit/include/libfdt_env.h b/cpukit/include/libfdt_env.h
index 9dea97dfff..99f936dacc 100644
--- a/cpukit/include/libfdt_env.h
+++ b/cpukit/include/libfdt_env.h
@@ -54,6 +54,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #ifdef __CHECKER__
-- 
2.13.7

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

[PATCH 15/45] libfdt: Extend the reach of FDT_ERR_BADPHANDLE

[Sebastian Huber]

From: Maxime Ripard 

So far, the BADPHANDLE error was only used for incorrect phandle values.
Extend that meaning to an improperly formatted phandle property.

Signed-off-by: Maxime Ripard 
Signed-off-by: David Gibson 
---
 cpukit/include/libfdt.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index 361cc6c719..d2e5e031fb 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -79,8 +79,10 @@
 * (e.g. missing a leading / for a function which requires an
 * absolute path) */
 #define FDT_ERR_BADPHANDLE 6
-   /* FDT_ERR_BADPHANDLE: Function was passed an invalid phandle
-* value.  phandle values of 0 and -1 are not permitted. */
+   /* FDT_ERR_BADPHANDLE: Function was passed an invalid phandle.
+* This can be caused either by an invalid phandle property
+* length, or the phandle value was either 0 or -1, which are
+* not permitted. */
 #define FDT_ERR_BADSTATE   7
/* FDT_ERR_BADSTATE: Function was passed an incomplete device
 * tree created by the sequential-write functions, which is
-- 
2.13.7

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

[PATCH 19/45] libfdt: fix fdt_stringlist_count()

[Sebastian Huber]

From: Masahiro Yamada 

If fdt_getprop() fails, negative error code should be returned.

Signed-off-by: Masahiro Yamada 
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_ro.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/dtc/libfdt/fdt_ro.c b/cpukit/dtc/libfdt/fdt_ro.c
index 04590984bd..db8d10fcd4 100644
--- a/cpukit/dtc/libfdt/fdt_ro.c
+++ b/cpukit/dtc/libfdt/fdt_ro.c
@@ -571,7 +571,7 @@ int fdt_stringlist_count(const void *fdt, int nodeoffset, 
const char *property)
 
list = fdt_getprop(fdt, nodeoffset, property, );
if (!list)
-   return -length;
+   return length;
 
end = list + length;
 
-- 
2.13.7

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

[PATCH 24/45] libfdt: Change names of sparse helper macros

[Sebastian Huber]

From: David Gibson 

The default libfdt_env.h (for POSIXish userland builds) supports sparse
checking.  It has a couple of helper macros, __force and __bitwise which
expand the relevant sparse attributes to enable checking for incorrect
or missing endian conversions.

Those are bad names: for one, leading underscores are supposed to be
reserved for the system libraries, and worse, some systems (including
RHEL7) do define those names already.

So change them to FDT_FORCE and FDT_BITWISE which are far less likely to
have collisions.

Suggested-by: Paolo Bonzini 
Signed-off-by: David Gibson 
---
 cpukit/include/libfdt_env.h | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/cpukit/include/libfdt_env.h b/cpukit/include/libfdt_env.h
index 99f936dacc..952056cddf 100644
--- a/cpukit/include/libfdt_env.h
+++ b/cpukit/include/libfdt_env.h
@@ -58,16 +58,16 @@
 #include 
 
 #ifdef __CHECKER__
-#define __force __attribute__((force))
-#define __bitwise __attribute__((bitwise))
+#define FDT_FORCE __attribute__((force))
+#define FDT_BITWISE __attribute__((bitwise))
 #else
-#define __force
-#define __bitwise
+#define FDT_FORCE
+#define FDT_BITWISE
 #endif
 
-typedef uint16_t __bitwise fdt16_t;
-typedef uint32_t __bitwise fdt32_t;
-typedef uint64_t __bitwise fdt64_t;
+typedef uint16_t FDT_BITWISE fdt16_t;
+typedef uint32_t FDT_BITWISE fdt32_t;
+typedef uint64_t FDT_BITWISE fdt64_t;
 
 #define EXTRACT_BYTE(x, n) ((unsigned long long)((uint8_t *))[n])
 #define CPU_TO_FDT16(x) ((EXTRACT_BYTE(x, 0) << 8) | EXTRACT_BYTE(x, 1))
@@ -80,29 +80,29 @@ typedef uint64_t __bitwise fdt64_t;
 
 static inline uint16_t fdt16_to_cpu(fdt16_t x)
 {
-   return (__force uint16_t)CPU_TO_FDT16(x);
+   return (FDT_FORCE uint16_t)CPU_TO_FDT16(x);
 }
 static inline fdt16_t cpu_to_fdt16(uint16_t x)
 {
-   return (__force fdt16_t)CPU_TO_FDT16(x);
+   return (FDT_FORCE fdt16_t)CPU_TO_FDT16(x);
 }
 
 static inline uint32_t fdt32_to_cpu(fdt32_t x)
 {
-   return (__force uint32_t)CPU_TO_FDT32(x);
+   return (FDT_FORCE uint32_t)CPU_TO_FDT32(x);
 }
 static inline fdt32_t cpu_to_fdt32(uint32_t x)
 {
-   return (__force fdt32_t)CPU_TO_FDT32(x);
+   return (FDT_FORCE fdt32_t)CPU_TO_FDT32(x);
 }
 
 static inline uint64_t fdt64_to_cpu(fdt64_t x)
 {
-   return (__force uint64_t)CPU_TO_FDT64(x);
+   return (FDT_FORCE uint64_t)CPU_TO_FDT64(x);
 }
 static inline fdt64_t cpu_to_fdt64(uint64_t x)
 {
-   return (__force fdt64_t)CPU_TO_FDT64(x);
+   return (FDT_FORCE fdt64_t)CPU_TO_FDT64(x);
 }
 #undef CPU_TO_FDT64
 #undef CPU_TO_FDT32
-- 
2.13.7

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

[PATCH 07/45] libfdt: Add a subnodes iterator macro

[Sebastian Huber]

From: Thierry Reding 

The fdt_for_each_subnode() iterator macro provided by this patch can be
used to iterate over a device tree node's subnodes. At each iteration a
loop variable will be set to the next subnode.

Signed-off-by: Thierry Reding 
Signed-off-by: Maxime Ripard 
Signed-off-by: David Gibson 
---
 cpukit/include/libfdt.h | 28 
 1 file changed, 28 insertions(+)

diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index 36222fd4a6..911e548163 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -168,6 +168,34 @@ int fdt_first_subnode(const void *fdt, int offset);
  */
 int fdt_next_subnode(const void *fdt, int offset);
 
+/**
+ * fdt_for_each_subnode - iterate over all subnodes of a parent
+ *
+ * @node:  child node (int, lvalue)
+ * @fdt:   FDT blob (const void *)
+ * @parent:parent node (int)
+ *
+ * This is actually a wrapper around a for loop and would be used like so:
+ *
+ * fdt_for_each_subnode(node, fdt, parent) {
+ * Use node
+ * ...
+ * }
+ *
+ * if ((node < 0) && (node != -FDT_ERR_NOT_FOUND)) {
+ * Error handling
+ * }
+ *
+ * Note that this is implemented as a macro and @node is used as
+ * iterator in the loop. The parent variable be constant or even a
+ * literal.
+ *
+ */
+#define fdt_for_each_subnode(node, fdt, parent)\
+   for (node = fdt_first_subnode(fdt, parent); \
+node >= 0; \
+node = fdt_next_subnode(fdt, node))
+
 /**/
 /* General functions  */
 /**/
-- 
2.13.7

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

[PATCH 18/45] fdt: strerr: Remove spurious BADOVERLAY

[Sebastian Huber]

From: Maxime Ripard 

There's one FDT_ERR_BADOVERLAY too many in the fdt error table.

Signed-off-by: Maxime Ripard 
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_strerror.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/cpukit/dtc/libfdt/fdt_strerror.c b/cpukit/dtc/libfdt/fdt_strerror.c
index e00fcb19df..4ab3eb70b2 100644
--- a/cpukit/dtc/libfdt/fdt_strerror.c
+++ b/cpukit/dtc/libfdt/fdt_strerror.c
@@ -78,7 +78,6 @@ static struct fdt_errtabent fdt_errtable[] = {
FDT_ERRTABENT(FDT_ERR_BADSTRUCTURE),
FDT_ERRTABENT(FDT_ERR_BADLAYOUT),
FDT_ERRTABENT(FDT_ERR_BADOVERLAY),
-   FDT_ERRTABENT(FDT_ERR_BADOVERLAY),
FDT_ERRTABENT(FDT_ERR_NOPHANDLES),
 };
 #define FDT_ERRTABSIZE (sizeof(fdt_errtable) / sizeof(fdt_errtable[0]))
-- 
2.13.7

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

[PATCH 17/45] libfdt: Add BADPHANDLE error string

[Sebastian Huber]

From: Maxime Ripard 

The BADPHANDLE error was missing a string, leading to an 
string being returned if you were to call fdt_strerror.

Signed-off-by: Maxime Ripard 
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_strerror.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/cpukit/dtc/libfdt/fdt_strerror.c b/cpukit/dtc/libfdt/fdt_strerror.c
index 3cb357f604..e00fcb19df 100644
--- a/cpukit/dtc/libfdt/fdt_strerror.c
+++ b/cpukit/dtc/libfdt/fdt_strerror.c
@@ -69,6 +69,7 @@ static struct fdt_errtabent fdt_errtable[] = {
 
FDT_ERRTABENT(FDT_ERR_BADOFFSET),
FDT_ERRTABENT(FDT_ERR_BADPATH),
+   FDT_ERRTABENT(FDT_ERR_BADPHANDLE),
FDT_ERRTABENT(FDT_ERR_BADSTATE),
 
FDT_ERRTABENT(FDT_ERR_TRUNCATED),
-- 
2.13.7

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

[PATCH 21/45] libfdt: add missing errors to fdt_strerror()

[Sebastian Huber]

From: Benjamin Fair 

Some error values were missing from the table which meant that they could
not be translated by fdt_strerror().

Signed-off-by: Benjamin Fair 
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_strerror.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/cpukit/dtc/libfdt/fdt_strerror.c b/cpukit/dtc/libfdt/fdt_strerror.c
index 4ab3eb70b2..9677a1887e 100644
--- a/cpukit/dtc/libfdt/fdt_strerror.c
+++ b/cpukit/dtc/libfdt/fdt_strerror.c
@@ -77,6 +77,9 @@ static struct fdt_errtabent fdt_errtable[] = {
FDT_ERRTABENT(FDT_ERR_BADVERSION),
FDT_ERRTABENT(FDT_ERR_BADSTRUCTURE),
FDT_ERRTABENT(FDT_ERR_BADLAYOUT),
+   FDT_ERRTABENT(FDT_ERR_INTERNAL),
+   FDT_ERRTABENT(FDT_ERR_BADNCELLS),
+   FDT_ERRTABENT(FDT_ERR_BADVALUE),
FDT_ERRTABENT(FDT_ERR_BADOVERLAY),
FDT_ERRTABENT(FDT_ERR_NOPHANDLES),
 };
-- 
2.13.7

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

[PATCH 22/45] libfdt: Remove undefined behaviour setting empty properties

[Sebastian Huber]

From: David Gibson 

The standard way of setting an empty property using libfdt is:
fdt_setprop(fdt, nodeoffset, propname, NULL, 0);
However, the implementation of this includes an unconditional:
 memcpy(prop->data, NULL, 0);
Which although it will be a no-op (which is what we want) on many platforms
is technically undefined behaviour.  Correct this, so that when passing
a 0 length, passing a NULL pointer as the value to fdt_setprop() is
definitely safe.  This should quiet static checkers which complain about
this.

Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_rw.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/cpukit/dtc/libfdt/fdt_rw.c b/cpukit/dtc/libfdt/fdt_rw.c
index 2eed4f5838..3fd5847377 100644
--- a/cpukit/dtc/libfdt/fdt_rw.c
+++ b/cpukit/dtc/libfdt/fdt_rw.c
@@ -283,7 +283,8 @@ int fdt_setprop(void *fdt, int nodeoffset, const char *name,
if (err)
return err;
 
-   memcpy(prop->data, val, len);
+   if (len)
+   memcpy(prop->data, val, len);
return 0;
 }
 
-- 
2.13.7

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

[PATCH 38/45] libfdt: Safer access to memory reservations

[Sebastian Huber]

From: David Gibson 

fdt_num_mem_rsv() and fdt_get_mem_rsv() currently don't sanity check their
parameters, or the memory reserve section offset in the header.  That means
that on a corrupted blob they could access outside of the range of memory
that they should.

This improves their safety checking, meaning they shouldn't access outside
the blob's bounds, even if its contents are badly corrupted.

Signed-off-by: David Gibson 
Tested-by: Alexey Kardashevskiy 
Reviewed-by: Alexey Kardashevskiy 
Reviewed-by: Simon Glass 
---
 cpukit/dtc/libfdt/fdt_ro.c | 33 +++--
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt_ro.c b/cpukit/dtc/libfdt/fdt_ro.c
index d4cec0efd1..c74b9629af 100644
--- a/cpukit/dtc/libfdt/fdt_ro.c
+++ b/cpukit/dtc/libfdt/fdt_ro.c
@@ -170,21 +170,42 @@ uint32_t fdt_get_max_phandle(const void *fdt)
return 0;
 }
 
+static const struct fdt_reserve_entry *fdt_mem_rsv(const void *fdt, int n)
+{
+   int offset = n * sizeof(struct fdt_reserve_entry);
+   int absoffset = fdt_off_mem_rsvmap(fdt) + offset;
+
+   if (absoffset < fdt_off_mem_rsvmap(fdt))
+   return NULL;
+   if (absoffset > fdt_totalsize(fdt) - sizeof(struct fdt_reserve_entry))
+   return NULL;
+   return fdt_mem_rsv_(fdt, n);
+}
+
 int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size)
 {
+   const struct fdt_reserve_entry *re;
+
FDT_RO_PROBE(fdt);
-   *address = fdt64_to_cpu(fdt_mem_rsv_(fdt, n)->address);
-   *size = fdt64_to_cpu(fdt_mem_rsv_(fdt, n)->size);
+   re = fdt_mem_rsv(fdt, n);
+   if (!re)
+   return -FDT_ERR_BADOFFSET;
+
+   *address = fdt64_to_cpu(re->address);
+   *size = fdt64_to_cpu(re->size);
return 0;
 }
 
 int fdt_num_mem_rsv(const void *fdt)
 {
-   int i = 0;
+   int i;
+   const struct fdt_reserve_entry *re;
 
-   while (fdt64_to_cpu(fdt_mem_rsv_(fdt, i)->size) != 0)
-   i++;
-   return i;
+   for (i = 0; (re = fdt_mem_rsv(fdt, i)) != NULL; i++) {
+   if (fdt64_to_cpu(re->size) == 0)
+   return i;
+   }
+   return -FDT_ERR_TRUNCATED;
 }
 
 static int nextprop_(const void *fdt, int offset)
-- 
2.13.7

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

[PATCH 32/45] Add limited read-only support for older (V2 and V3) device tree to libfdt.

[Sebastian Huber]

From: Nathan Whitehorn 

This can be useful in particular in the kernel when booting on systems
with FDT-emitting firmware that is out of date. Releases of kexec-tools
on ppc64 prior to the end of 2014 are notable examples of such.

Signed-off-by: Nathan Whitehorn 
[dwg: Some whitespace cleanups]
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt.c|   3 ++
 cpukit/dtc/libfdt/fdt_ro.c | 100 ++---
 cpukit/include/libfdt.h|   5 ++-
 3 files changed, 92 insertions(+), 16 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt.c b/cpukit/dtc/libfdt/fdt.c
index fd13236736..7855a17877 100644
--- a/cpukit/dtc/libfdt/fdt.c
+++ b/cpukit/dtc/libfdt/fdt.c
@@ -123,6 +123,9 @@ uint32_t fdt_next_tag(const void *fdt, int startoffset, int 
*nextoffset)
/* skip-name offset, length and value */
offset += sizeof(struct fdt_property) - FDT_TAGSIZE
+ fdt32_to_cpu(*lenp);
+   if (fdt_version(fdt) < 0x10 && fdt32_to_cpu(*lenp) >= 8 &&
+   ((offset - fdt32_to_cpu(*lenp)) % 8) != 0)
+   offset += 4;
break;
 
case FDT_END:
diff --git a/cpukit/dtc/libfdt/fdt_ro.c b/cpukit/dtc/libfdt/fdt_ro.c
index ce17814b2b..dfb3236da3 100644
--- a/cpukit/dtc/libfdt/fdt_ro.c
+++ b/cpukit/dtc/libfdt/fdt_ro.c
@@ -58,9 +58,10 @@
 static int fdt_nodename_eq_(const void *fdt, int offset,
const char *s, int len)
 {
-   const char *p = fdt_offset_ptr(fdt, offset + FDT_TAGSIZE, len+1);
+   int olen;
+   const char *p = fdt_get_name(fdt, offset, );
 
-   if (!p)
+   if (!p || olen < len)
/* short match */
return 0;
 
@@ -233,16 +234,34 @@ int fdt_path_offset(const void *fdt, const char *path)
 const char *fdt_get_name(const void *fdt, int nodeoffset, int *len)
 {
const struct fdt_node_header *nh = fdt_offset_ptr_(fdt, nodeoffset);
+   const char *nameptr;
int err;
 
if (((err = fdt_check_header(fdt)) != 0)
|| ((err = fdt_check_node_offset_(fdt, nodeoffset)) < 0))
goto fail;
 
+   nameptr = nh->name;
+
+   if (fdt_version(fdt) < 0x10) {
+   /*
+* For old FDT versions, match the naming conventions of V16:
+* give only the leaf name (after all /). The actual tree
+* contents are loosely checked.
+*/
+   const char *leaf;
+   leaf = strrchr(nameptr, '/');
+   if (leaf == NULL) {
+   err = -FDT_ERR_BADSTRUCTURE;
+   goto fail;
+   }
+   nameptr = leaf+1;
+   }
+
if (len)
-   *len = strlen(nh->name);
+   *len = strlen(nameptr);
 
-   return nh->name;
+   return nameptr;
 
  fail:
if (len)
@@ -268,9 +287,9 @@ int fdt_next_property_offset(const void *fdt, int offset)
return nextprop_(fdt, offset);
 }
 
-const struct fdt_property *fdt_get_property_by_offset(const void *fdt,
- int offset,
- int *lenp)
+static const struct fdt_property *fdt_get_property_by_offset_(const void *fdt,
+ int offset,
+ int *lenp)
 {
int err;
const struct fdt_property *prop;
@@ -289,23 +308,44 @@ const struct fdt_property 
*fdt_get_property_by_offset(const void *fdt,
return prop;
 }
 
-const struct fdt_property *fdt_get_property_namelen(const void *fdt,
-   int offset,
-   const char *name,
-   int namelen, int *lenp)
+const struct fdt_property *fdt_get_property_by_offset(const void *fdt,
+ int offset,
+ int *lenp)
+{
+   /* Prior to version 16, properties may need realignment
+* and this API does not work. fdt_getprop_*() will, however. */
+
+   if (fdt_version(fdt) < 0x10) {
+   if (lenp)
+   *lenp = -FDT_ERR_BADVERSION;
+   return NULL;
+   }
+
+   return fdt_get_property_by_offset_(fdt, offset, lenp);
+}
+
+static const struct fdt_property *fdt_get_property_namelen_(const void *fdt,
+   int offset,
+   const char *name,
+   int namelen,
+   int *lenp,
+   int *poffset)
 {
for (offset = 

[PATCH 37/45] libfdt: Propagate name errors in fdt_getprop_by_offset()

[Sebastian Huber]

From: David Gibson 

fdt_getprop_by_offset() doesn't check for errors from fdt_string() - after
all, until very recently it couldn't fail.  Now it can, so we need to
propagate errors up to the caller.

Signed-off-by: David Gibson 
Tested-by: Alexey Kardashevskiy 
Reviewed-by: Alexey Kardashevskiy 
Reviewed-by: Simon Glass 
---
 cpukit/dtc/libfdt/fdt_ro.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt_ro.c b/cpukit/dtc/libfdt/fdt_ro.c
index 347aa7bc8d..d4cec0efd1 100644
--- a/cpukit/dtc/libfdt/fdt_ro.c
+++ b/cpukit/dtc/libfdt/fdt_ro.c
@@ -461,8 +461,18 @@ const void *fdt_getprop_by_offset(const void *fdt, int 
offset,
prop = fdt_get_property_by_offset_(fdt, offset, lenp);
if (!prop)
return NULL;
-   if (namep)
-   *namep = fdt_string(fdt, fdt32_to_cpu(prop->nameoff));
+   if (namep) {
+   const char *name;
+   int namelen;
+   name = fdt_get_string(fdt, fdt32_to_cpu(prop->nameoff),
+ );
+   if (!name) {
+   if (lenp)
+   *lenp = namelen;
+   return NULL;
+   }
+   *namep = name;
+   }
 
/* Handle realignment */
if (fdt_version(fdt) < 0x10 && (offset + sizeof(*prop)) % 8 &&
-- 
2.13.7

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

[PATCH 40/45] libfdt: Add fdt_check_full() function

[Sebastian Huber]

From: David Gibson 

This new function implements a complete and thorough check of an fdt blob's
structure.  Given a buffer containing an fdt, it should return 0 only if
the fdt within is structurally sound in all regards.  It doesn't check
anything about the blob's contents (i.e. the actual values of the nodes and
properties), of course.

Signed-off-by: David Gibson 
Tested-by: Alexey Kardashevskiy 
Reviewed-by: Alexey Kardashevskiy 
Reviewed-by: Simon Glass 
---
 cpukit/dtc/libfdt/fdt_ro.c | 63 ++
 cpukit/include/libfdt.h|  2 ++
 2 files changed, 65 insertions(+)

diff --git a/cpukit/dtc/libfdt/fdt_ro.c b/cpukit/dtc/libfdt/fdt_ro.c
index c74b9629af..4ba7c93313 100644
--- a/cpukit/dtc/libfdt/fdt_ro.c
+++ b/cpukit/dtc/libfdt/fdt_ro.c
@@ -857,3 +857,66 @@ int fdt_node_offset_by_compatible(const void *fdt, int 
startoffset,
 
return offset; /* error from fdt_next_node() */
 }
+
+int fdt_check_full(const void *fdt, size_t bufsize)
+{
+   int err;
+   int num_memrsv;
+   int offset, nextoffset = 0;
+   uint32_t tag;
+   unsigned depth = 0;
+   const void *prop;
+   const char *propname;
+
+   if (bufsize < FDT_V1_SIZE)
+   return -FDT_ERR_TRUNCATED;
+   err = fdt_check_header(fdt);
+   if (err != 0)
+   return err;
+   if (bufsize < fdt_totalsize(fdt))
+   return -FDT_ERR_TRUNCATED;
+
+   num_memrsv = fdt_num_mem_rsv(fdt);
+   if (num_memrsv < 0)
+   return num_memrsv;
+
+   while (1) {
+   offset = nextoffset;
+   tag = fdt_next_tag(fdt, offset, );
+
+   if (nextoffset < 0)
+   return nextoffset;
+
+   switch (tag) {
+   case FDT_NOP:
+   break;
+
+   case FDT_END:
+   if (depth != 0)
+   return -FDT_ERR_BADSTRUCTURE;
+   return 0;
+
+   case FDT_BEGIN_NODE:
+   depth++;
+   if (depth > INT_MAX)
+   return -FDT_ERR_BADSTRUCTURE;
+   break;
+
+   case FDT_END_NODE:
+   if (depth == 0)
+   return -FDT_ERR_BADSTRUCTURE;
+   depth--;
+   break;
+
+   case FDT_PROP:
+   prop = fdt_getprop_by_offset(fdt, offset, ,
+);
+   if (!prop)
+   return err;
+   break;
+
+   default:
+   return -FDT_ERR_INTERNAL;
+   }
+   }
+}
diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index b81d046e54..79e4d82619 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -298,6 +298,8 @@ int fdt_move(const void *fdt, void *buf, int bufsize);
 /* Read-only functions*/
 /**/
 
+int fdt_check_full(const void *fdt, size_t bufsize);
+
 /**
  * fdt_get_string - retrieve a string from the strings block of a device tree
  * @fdt: pointer to the device tree blob
-- 
2.13.7

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

[PATCH 35/45] libfdt: Make fdt_check_header() more thorough

[Sebastian Huber]

From: David Gibson 

Currently fdt_check_header() performs only some rudimentary checks, which
is not really what the name suggests.  This strengthens fdt_check_header()
to check as much about the blob as is possible from the header alone:  as
well as checking the magic number and version, it checks that the total
size is sane, and that all the sub-blocks within the blob lie within the
total size.

 * This broadens the meaning of FDT_ERR_TRUNCATED to cover all sorts of
   improperly terminated blocks as well as just a structure block without
   FDT_END.

 * This makes fdt_check_header() only succeed on "complete" blobs, not
   in-progress sequential write blobs.  The only reason this didn't fail
   before was that this function used to be called by many RO functions
   which are supposed to also work on incomplete SW blobs.

Signed-off-by: David Gibson 
Tested-by: Alexey Kardashevskiy 
Reviewed-by: Alexey Kardashevskiy 
Reviewed-by: Simon Glass 
---
 cpukit/dtc/libfdt/fdt.c | 57 -
 cpukit/include/libfdt.h | 15 +++-
 cpukit/include/libfdt_env.h |  1 +
 3 files changed, 66 insertions(+), 7 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt.c b/cpukit/dtc/libfdt/fdt.c
index 8bbf2dc894..5f1e57a5bd 100644
--- a/cpukit/dtc/libfdt/fdt.c
+++ b/cpukit/dtc/libfdt/fdt.c
@@ -79,9 +79,64 @@ int fdt_ro_probe_(const void *fdt)
return 0;
 }
 
+static int check_off_(uint32_t hdrsize, uint32_t totalsize, uint32_t off)
+{
+   return (off >= hdrsize) && (off <= totalsize);
+}
+
+static int check_block_(uint32_t hdrsize, uint32_t totalsize,
+   uint32_t base, uint32_t size)
+{
+   if (!check_off_(hdrsize, totalsize, base))
+   return 0; /* block start out of bounds */
+   if ((base + size) < base)
+   return 0; /* overflow */
+   if (!check_off_(hdrsize, totalsize, base + size))
+   return 0; /* block end out of bounds */
+   return 1;
+}
+
 int fdt_check_header(const void *fdt)
 {
-   return fdt_ro_probe_(fdt);
+   size_t hdrsize = FDT_V16_SIZE;
+
+   if (fdt_magic(fdt) != FDT_MAGIC)
+   return -FDT_ERR_BADMAGIC;
+   if ((fdt_version(fdt) < FDT_FIRST_SUPPORTED_VERSION)
+   || (fdt_last_comp_version(fdt) > FDT_LAST_SUPPORTED_VERSION))
+   return -FDT_ERR_BADVERSION;
+   if (fdt_version(fdt) < fdt_last_comp_version(fdt))
+   return -FDT_ERR_BADVERSION;
+
+   if (fdt_version(fdt) >= 17)
+   hdrsize = FDT_V17_SIZE;
+
+   if ((fdt_totalsize(fdt) < hdrsize)
+   || (fdt_totalsize(fdt) > INT_MAX))
+   return -FDT_ERR_TRUNCATED;
+
+   /* Bounds check memrsv block */
+   if (!check_off_(hdrsize, fdt_totalsize(fdt), fdt_off_mem_rsvmap(fdt)))
+   return -FDT_ERR_TRUNCATED;
+
+   /* Bounds check structure block */
+   if (fdt_version(fdt) < 17) {
+   if (!check_off_(hdrsize, fdt_totalsize(fdt),
+   fdt_off_dt_struct(fdt)))
+   return -FDT_ERR_TRUNCATED;
+   } else {
+   if (!check_block_(hdrsize, fdt_totalsize(fdt),
+ fdt_off_dt_struct(fdt),
+ fdt_size_dt_struct(fdt)))
+   return -FDT_ERR_TRUNCATED;
+   }
+
+   /* Bounds check strings block */
+   if (!check_block_(hdrsize, fdt_totalsize(fdt),
+ fdt_off_dt_strings(fdt), fdt_size_dt_strings(fdt)))
+   return -FDT_ERR_TRUNCATED;
+
+   return 0;
 }
 
 const void *fdt_offset_ptr(const void *fdt, int offset, unsigned int len)
diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index c8c00fa865..837c5e27ee 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -90,8 +90,9 @@
 
 /* Error codes: codes for bad device tree blobs */
 #define FDT_ERR_TRUNCATED  8
-   /* FDT_ERR_TRUNCATED: Structure block of the given device tree
-* ends without an FDT_END tag. */
+   /* FDT_ERR_TRUNCATED: FDT or a sub-block is improperly
+* terminated (overflows, goes outside allowed bounds, or
+* isn't properly terminated).  */
 #define FDT_ERR_BADMAGIC   9
/* FDT_ERR_BADMAGIC: Given "device tree" appears not to be a
 * device tree at all - it is missing the flattened device
@@ -244,18 +245,20 @@ fdt_set_hdr_(size_dt_struct);
 #undef fdt_set_hdr_
 
 /**
- * fdt_check_header - sanity check a device tree or possible device tree
+ * fdt_check_header - sanity check a device tree header
  * @fdt: pointer to data which might be a flattened device tree
  *
  * fdt_check_header() checks that the given buffer contains what
- * appears to be a flattened device tree with sane information in its
- * header.
+ * appears to be a flattened device tree, and that the header contains
+ * valid information (to the extent that can be determined from the
+ * header alone).
  *
  

[PATCH 23/45] libfdt: Add fdt_setprop_empty()

[Sebastian Huber]

From: David Gibson 

Device trees can contain empty (zero length) properties, which are often
used as boolean flags.  These can already be created using fdt_setprop()
passing a length of zero and a pointer which is ignored.  It is safe to
pass NULL, but that may not be obvious from the interface.  To make it
clearer, add an fdt_setprop_empty() helper macro.

Signed-off-by: David Gibson 
---
 cpukit/include/libfdt.h | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index c69e918899..ac42e04595 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -1527,6 +1527,36 @@ static inline int fdt_setprop_cell(void *fdt, int 
nodeoffset, const char *name,
 #define fdt_setprop_string(fdt, nodeoffset, name, str) \
fdt_setprop((fdt), (nodeoffset), (name), (str), strlen(str)+1)
 
+
+/**
+ * fdt_setprop_empty - set a property to an empty value
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ *
+ * fdt_setprop_empty() sets the value of the named property in the
+ * given node to an empty (zero length) value, or creates a new empty
+ * property if it does not already exist.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ * 0, on success
+ * -FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ * contain the new property value
+ * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ * -FDT_ERR_BADLAYOUT,
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE,
+ * -FDT_ERR_BADLAYOUT,
+ * -FDT_ERR_TRUNCATED, standard meanings
+ */
+#define fdt_setprop_empty(fdt, nodeoffset, name) \
+   fdt_setprop((fdt), (nodeoffset), (name), NULL, 0)
+
 /**
  * fdt_appendprop - append to or create a property
  * @fdt: pointer to the device tree blob
-- 
2.13.7

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

[PATCH 31/45] implement strnlen for systems that need it

[Sebastian Huber]

From: John Arbuckle 

Prior the Mac OS 10.7, the function strnlen() was not available. This patch
implements strnlen() on Mac OS X versions that are below 10.7.

Signed-off-by: John Arbuckle 
Signed-off-by: David Gibson 
---
 cpukit/include/libfdt_env.h | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/cpukit/include/libfdt_env.h b/cpukit/include/libfdt_env.h
index 3605d93254..bd24746287 100644
--- a/cpukit/include/libfdt_env.h
+++ b/cpukit/include/libfdt_env.h
@@ -109,4 +109,31 @@ static inline fdt64_t cpu_to_fdt64(uint64_t x)
 #undef CPU_TO_FDT16
 #undef EXTRACT_BYTE
 
+#ifdef __APPLE__
+#include 
+
+/* strnlen() is not available on Mac OS < 10.7 */
+# if !defined(MAC_OS_X_VERSION_10_7) || (MAC_OS_X_VERSION_MAX_ALLOWED < \
+ MAC_OS_X_VERSION_10_7)
+
+#define strnlen fdt_strnlen
+
+/*
+ * fdt_strnlen: returns the length of a string or max_count - which ever is
+ * smallest.
+ * Input 1 string: the string whose size is to be determined
+ * Input 2 max_count: the maximum value returned by this function
+ * Output: length of the string or max_count (the smallest of the two)
+ */
+static inline size_t fdt_strnlen(const char *string, size_t max_count)
+{
+const char *p = memchr(string, 0, max_count);
+return p ? p - string : max_count;
+}
+
+#endif /* !defined(MAC_OS_X_VERSION_10_7) || (MAC_OS_X_VERSION_MAX_ALLOWED <
+  MAC_OS_X_VERSION_10_7) */
+
+#endif /* __APPLE__ */
+
 #endif /* LIBFDT_ENV_H */
-- 
2.13.7

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

[PATCH 30/45] libfdt: Remove leading underscores from identifiers

[Sebastian Huber]

From: David Gibson 

In a lot of places libfdt uses a leading _ character to mark an identifier
as "internal" (not part of the published libfdt API).  This is a bad idea,
because identifiers with a leading _ are generally reserved by the C
library or system.  It's particularly dangerous for libfdt, because it's
designed to be able to be integrated into lots of different environments.

In some cases the leading _ has no purpose, so we simply drop it.  In most
cases we move it to the end, as our new convention for marking internal
identifiers.

Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt.c | 10 ++---
 cpukit/dtc/libfdt/fdt_ro.c  | 32 ++---
 cpukit/dtc/libfdt/fdt_rw.c  | 90 ++---
 cpukit/dtc/libfdt/fdt_sw.c  | 24 +-
 cpukit/dtc/libfdt/fdt_wip.c | 10 ++---
 cpukit/dtc/libfdt/libfdt_internal.h | 32 ++---
 cpukit/include/fdt.h|  6 +--
 cpukit/include/libfdt.h | 30 ++---
 cpukit/include/libfdt_env.h |  6 +--
 9 files changed, 120 insertions(+), 120 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt.c b/cpukit/dtc/libfdt/fdt.c
index 22286a1aae..fd13236736 100644
--- a/cpukit/dtc/libfdt/fdt.c
+++ b/cpukit/dtc/libfdt/fdt.c
@@ -88,7 +88,7 @@ const void *fdt_offset_ptr(const void *fdt, int offset, 
unsigned int len)
|| ((offset + len) > fdt_size_dt_struct(fdt)))
return NULL;
 
-   return _fdt_offset_ptr(fdt, offset);
+   return fdt_offset_ptr_(fdt, offset);
 }
 
 uint32_t fdt_next_tag(const void *fdt, int startoffset, int *nextoffset)
@@ -141,7 +141,7 @@ uint32_t fdt_next_tag(const void *fdt, int startoffset, int 
*nextoffset)
return tag;
 }
 
-int _fdt_check_node_offset(const void *fdt, int offset)
+int fdt_check_node_offset_(const void *fdt, int offset)
 {
if ((offset < 0) || (offset % FDT_TAGSIZE)
|| (fdt_next_tag(fdt, offset, ) != FDT_BEGIN_NODE))
@@ -150,7 +150,7 @@ int _fdt_check_node_offset(const void *fdt, int offset)
return offset;
 }
 
-int _fdt_check_prop_offset(const void *fdt, int offset)
+int fdt_check_prop_offset_(const void *fdt, int offset)
 {
if ((offset < 0) || (offset % FDT_TAGSIZE)
|| (fdt_next_tag(fdt, offset, ) != FDT_PROP))
@@ -165,7 +165,7 @@ int fdt_next_node(const void *fdt, int offset, int *depth)
uint32_t tag;
 
if (offset >= 0)
-   if ((nextoffset = _fdt_check_node_offset(fdt, offset)) < 0)
+   if ((nextoffset = fdt_check_node_offset_(fdt, offset)) < 0)
return nextoffset;
 
do {
@@ -227,7 +227,7 @@ int fdt_next_subnode(const void *fdt, int offset)
return offset;
 }
 
-const char *_fdt_find_string(const char *strtab, int tabsize, const char *s)
+const char *fdt_find_string_(const char *strtab, int tabsize, const char *s)
 {
int len = strlen(s) + 1;
const char *last = strtab + tabsize - len;
diff --git a/cpukit/dtc/libfdt/fdt_ro.c b/cpukit/dtc/libfdt/fdt_ro.c
index 08de2cce67..ce17814b2b 100644
--- a/cpukit/dtc/libfdt/fdt_ro.c
+++ b/cpukit/dtc/libfdt/fdt_ro.c
@@ -55,7 +55,7 @@
 
 #include "libfdt_internal.h"
 
-static int _fdt_nodename_eq(const void *fdt, int offset,
+static int fdt_nodename_eq_(const void *fdt, int offset,
const char *s, int len)
 {
const char *p = fdt_offset_ptr(fdt, offset + FDT_TAGSIZE, len+1);
@@ -80,7 +80,7 @@ const char *fdt_string(const void *fdt, int stroffset)
return (const char *)fdt + fdt_off_dt_strings(fdt) + stroffset;
 }
 
-static int _fdt_string_eq(const void *fdt, int stroffset,
+static int fdt_string_eq_(const void *fdt, int stroffset,
  const char *s, int len)
 {
const char *p = fdt_string(fdt, stroffset);
@@ -117,8 +117,8 @@ uint32_t fdt_get_max_phandle(const void *fdt)
 int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size)
 {
FDT_CHECK_HEADER(fdt);
-   *address = fdt64_to_cpu(_fdt_mem_rsv(fdt, n)->address);
-   *size = fdt64_to_cpu(_fdt_mem_rsv(fdt, n)->size);
+   *address = fdt64_to_cpu(fdt_mem_rsv_(fdt, n)->address);
+   *size = fdt64_to_cpu(fdt_mem_rsv_(fdt, n)->size);
return 0;
 }
 
@@ -126,12 +126,12 @@ int fdt_num_mem_rsv(const void *fdt)
 {
int i = 0;
 
-   while (fdt64_to_cpu(_fdt_mem_rsv(fdt, i)->size) != 0)
+   while (fdt64_to_cpu(fdt_mem_rsv_(fdt, i)->size) != 0)
i++;
return i;
 }
 
-static int _nextprop(const void *fdt, int offset)
+static int nextprop_(const void *fdt, int offset)
 {
uint32_t tag;
int nextoffset;
@@ -166,7 +166,7 @@ int fdt_subnode_offset_namelen(const void *fdt, int offset,
 (offset >= 0) && (depth >= 0);
 offset = fdt_next_node(fdt, offset, ))
if ((depth == 1)
-   && _fdt_nodename_eq(fdt, offset, name, namelen))
+ 

[PATCH 27/45] Fix a few whitespace and style nits

[Sebastian Huber]

From: Simon Glass 

These were noticed when synching with U-Boot's downstream tree.

Signed-off-by: Simon Glass 
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_empty_tree.c | 1 -
 cpukit/dtc/libfdt/fdt_ro.c | 4 ++--
 cpukit/dtc/libfdt/fdt_rw.c | 4 ++--
 cpukit/dtc/libfdt/fdt_wip.c| 4 ++--
 4 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt_empty_tree.c 
b/cpukit/dtc/libfdt/fdt_empty_tree.c
index f72d13b1d1..f2ae9b77c2 100644
--- a/cpukit/dtc/libfdt/fdt_empty_tree.c
+++ b/cpukit/dtc/libfdt/fdt_empty_tree.c
@@ -81,4 +81,3 @@ int fdt_create_empty_tree(void *buf, int bufsize)
 
return fdt_open_into(buf, buf, bufsize);
 }
-
diff --git a/cpukit/dtc/libfdt/fdt_ro.c b/cpukit/dtc/libfdt/fdt_ro.c
index 3d00d2eee0..08de2cce67 100644
--- a/cpukit/dtc/libfdt/fdt_ro.c
+++ b/cpukit/dtc/libfdt/fdt_ro.c
@@ -60,7 +60,7 @@ static int _fdt_nodename_eq(const void *fdt, int offset,
 {
const char *p = fdt_offset_ptr(fdt, offset + FDT_TAGSIZE, len+1);
 
-   if (! p)
+   if (!p)
/* short match */
return 0;
 
@@ -327,7 +327,7 @@ const void *fdt_getprop_namelen(const void *fdt, int 
nodeoffset,
const struct fdt_property *prop;
 
prop = fdt_get_property_namelen(fdt, nodeoffset, name, namelen, lenp);
-   if (! prop)
+   if (!prop)
return NULL;
 
return prop->data;
diff --git a/cpukit/dtc/libfdt/fdt_rw.c b/cpukit/dtc/libfdt/fdt_rw.c
index 3fd5847377..8b487f6c0f 100644
--- a/cpukit/dtc/libfdt/fdt_rw.c
+++ b/cpukit/dtc/libfdt/fdt_rw.c
@@ -207,7 +207,7 @@ static int _fdt_resize_property(void *fdt, int nodeoffset, 
const char *name,
int err;
 
*prop = fdt_get_property_w(fdt, nodeoffset, name, );
-   if (! (*prop))
+   if (!*prop)
return oldlen;
 
if ((err = _fdt_splice_struct(fdt, (*prop)->data, FDT_TAGALIGN(oldlen),
@@ -323,7 +323,7 @@ int fdt_delprop(void *fdt, int nodeoffset, const char *name)
FDT_RW_CHECK_HEADER(fdt);
 
prop = fdt_get_property_w(fdt, nodeoffset, name, );
-   if (! prop)
+   if (!prop)
return len;
 
proplen = sizeof(*prop) + FDT_TAGALIGN(len);
diff --git a/cpukit/dtc/libfdt/fdt_wip.c b/cpukit/dtc/libfdt/fdt_wip.c
index 6aaab39992..5e85919862 100644
--- a/cpukit/dtc/libfdt/fdt_wip.c
+++ b/cpukit/dtc/libfdt/fdt_wip.c
@@ -82,7 +82,7 @@ int fdt_setprop_inplace(void *fdt, int nodeoffset, const char 
*name,
int proplen;
 
propval = fdt_getprop(fdt, nodeoffset, name, );
-   if (! propval)
+   if (!propval)
return proplen;
 
if (proplen != len)
@@ -107,7 +107,7 @@ int fdt_nop_property(void *fdt, int nodeoffset, const char 
*name)
int len;
 
prop = fdt_get_property_w(fdt, nodeoffset, name, );
-   if (! prop)
+   if (!prop)
return len;
 
_fdt_nop_region(prop, len + sizeof(*prop));
-- 
2.13.7

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

[PATCH 09/45] libfdt: Add max phandle retrieval function

[Sebastian Huber]

From: Maxime Ripard 

Add a function to retrieve the highest phandle in a given device tree.

Acked-by: Simon Glass 
Reviewed-by: Stefan Agner 
Reviewed-by: David Gibson 
Signed-off-by: Maxime Ripard 
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_ro.c | 26 ++
 cpukit/include/libfdt.h| 15 +++
 2 files changed, 41 insertions(+)

diff --git a/cpukit/dtc/libfdt/fdt_ro.c b/cpukit/dtc/libfdt/fdt_ro.c
index 50cce86428..04590984bd 100644
--- a/cpukit/dtc/libfdt/fdt_ro.c
+++ b/cpukit/dtc/libfdt/fdt_ro.c
@@ -88,6 +88,32 @@ static int _fdt_string_eq(const void *fdt, int stroffset,
return (strlen(p) == len) && (memcmp(p, s, len) == 0);
 }
 
+uint32_t fdt_get_max_phandle(const void *fdt)
+{
+   uint32_t max_phandle = 0;
+   int offset;
+
+   for (offset = fdt_next_node(fdt, -1, NULL);;
+offset = fdt_next_node(fdt, offset, NULL)) {
+   uint32_t phandle;
+
+   if (offset == -FDT_ERR_NOTFOUND)
+   return max_phandle;
+
+   if (offset < 0)
+   return (uint32_t)-1;
+
+   phandle = fdt_get_phandle(fdt, offset);
+   if (phandle == (uint32_t)-1)
+   continue;
+
+   if (phandle > max_phandle)
+   max_phandle = phandle;
+   }
+
+   return 0;
+}
+
 int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size)
 {
FDT_CHECK_HEADER(fdt);
diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index be109a8aac..06b84cc16b 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -287,6 +287,21 @@ int fdt_move(const void *fdt, void *buf, int bufsize);
 const char *fdt_string(const void *fdt, int stroffset);
 
 /**
+ * fdt_get_max_phandle - retrieves the highest phandle in a tree
+ * @fdt: pointer to the device tree blob
+ *
+ * fdt_get_max_phandle retrieves the highest phandle in the given
+ * device tree. This will ignore badly formatted phandles, or phandles
+ * with a value of 0 or -1.
+ *
+ * returns:
+ *  the highest phandle on success
+ *  0, if no phandle was found in the device tree
+ *  -1, if an error occurred
+ */
+uint32_t fdt_get_max_phandle(const void *fdt);
+
+/**
  * fdt_num_mem_rsv - retrieve the number of memory reserve map entries
  * @fdt: pointer to the device tree blob
  *
-- 
2.13.7

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

[PATCH 28/45] Introduce fdt_setprop_placeholder() method

[Sebastian Huber]

From: Pantelis Antoniou 

In some cases you need to add a property but the contents of it
are not known at creation time, merely the extend of it.

This method allows you to create a property of a given size (filled
with garbage) while a pointer to the property data will be provided.

Signed-off-by: Pantelis Antoniou 
[dwg: Corrected commit message]
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_rw.c | 20 +---
 cpukit/include/libfdt.h| 31 +++
 2 files changed, 48 insertions(+), 3 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt_rw.c b/cpukit/dtc/libfdt/fdt_rw.c
index 8b487f6c0f..5c3a2bb0bc 100644
--- a/cpukit/dtc/libfdt/fdt_rw.c
+++ b/cpukit/dtc/libfdt/fdt_rw.c
@@ -269,8 +269,8 @@ int fdt_set_name(void *fdt, int nodeoffset, const char 
*name)
return 0;
 }
 
-int fdt_setprop(void *fdt, int nodeoffset, const char *name,
-   const void *val, int len)
+int fdt_setprop_placeholder(void *fdt, int nodeoffset, const char *name,
+   int len, void **prop_data)
 {
struct fdt_property *prop;
int err;
@@ -283,8 +283,22 @@ int fdt_setprop(void *fdt, int nodeoffset, const char 
*name,
if (err)
return err;
 
+   *prop_data = prop->data;
+   return 0;
+}
+
+int fdt_setprop(void *fdt, int nodeoffset, const char *name,
+   const void *val, int len)
+{
+   void *prop_data;
+   int err;
+
+   err = fdt_setprop_placeholder(fdt, nodeoffset, name, len, _data);
+   if (err)
+   return err;
+
if (len)
-   memcpy(prop->data, val, len);
+   memcpy(prop_data, val, len);
return 0;
 }
 
diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index a248b1b57a..313c72a2d1 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -1449,6 +1449,37 @@ int fdt_setprop(void *fdt, int nodeoffset, const char 
*name,
const void *val, int len);
 
 /**
+ * fdt_setprop _placeholder - allocate space for a property
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @len: length of the property value
+ * @prop_data: return pointer to property data
+ *
+ * fdt_setprop_placeholer() allocates the named property in the given node.
+ * If the property exists it is resized. In either case a pointer to the
+ * property data is returned.
+ *
+ * This function may insert or delete data from the blob, and will
+ * therefore change the offsets of some existing nodes.
+ *
+ * returns:
+ * 0, on success
+ * -FDT_ERR_NOSPACE, there is insufficient free space in the blob to
+ * contain the new property value
+ * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE tag
+ * -FDT_ERR_BADLAYOUT,
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADVERSION,
+ * -FDT_ERR_BADSTATE,
+ * -FDT_ERR_BADSTRUCTURE,
+ * -FDT_ERR_BADLAYOUT,
+ * -FDT_ERR_TRUNCATED, standard meanings
+ */
+int fdt_setprop_placeholder(void *fdt, int nodeoffset, const char *name,
+   int len, void **prop_data);
+
+/**
  * fdt_setprop_u32 - set a property to a 32-bit integer
  * @fdt: pointer to the device tree blob
  * @nodeoffset: offset of the node whose property to change
-- 
2.13.7

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

[PATCH 25/45] Adjust libfdt.h to work with swig

[Sebastian Huber]

From: Simon Glass 

There are a few places where libfdt.h cannot be used as is with swig:

- macros like fdt_totalsize() have to be defined as C declarations
- fdt_offset_ptr() and fdt_getprop_namelen() need special treatment due to
a TODO in the wrapper for fdt_getprop(). However they are not useful to
Python so can be removed

Add #ifdefs to work around these problem.

Signed-off-by: Simon Glass 
Signed-off-by: David Gibson 
---
 cpukit/include/libfdt.h | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index ac42e04595..2c9ddb4867 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -143,7 +143,9 @@
 /* Low-level functions (you probably don't need these)*/
 /**/
 
+#ifndef SWIG /* This function is not useful in Python */
 const void *fdt_offset_ptr(const void *fdt, int offset, unsigned int checklen);
+#endif
 static inline void *fdt_offset_ptr_w(void *fdt, int offset, int checklen)
 {
return (void *)(uintptr_t)fdt_offset_ptr(fdt, offset, checklen);
@@ -210,7 +212,6 @@ int fdt_next_subnode(const void *fdt, int offset);
 /**/
 /* General functions  */
 /**/
-
 #define fdt_get_header(fdt, field) \
(fdt32_to_cpu(((const struct fdt_header *)(fdt))->field))
 #define fdt_magic(fdt) (fdt_get_header(fdt, magic))
@@ -354,8 +355,10 @@ int fdt_get_mem_rsv(const void *fdt, int n, uint64_t 
*address, uint64_t *size);
  * useful for finding subnodes based on a portion of a larger string,
  * such as a full path.
  */
+#ifndef SWIG /* Not available in Python */
 int fdt_subnode_offset_namelen(const void *fdt, int parentoffset,
   const char *name, int namelen);
+#endif
 /**
  * fdt_subnode_offset - find a subnode of a given node
  * @fdt: pointer to the device tree blob
@@ -391,7 +394,9 @@ int fdt_subnode_offset(const void *fdt, int parentoffset, 
const char *name);
  * Identical to fdt_path_offset(), but only consider the first namelen
  * characters of path as the path name.
  */
+#ifndef SWIG /* Not available in Python */
 int fdt_path_offset_namelen(const void *fdt, const char *path, int namelen);
+#endif
 
 /**
  * fdt_path_offset - find a tree node by its full path
@@ -550,10 +555,12 @@ const struct fdt_property 
*fdt_get_property_by_offset(const void *fdt,
  * Identical to fdt_get_property(), but only examine the first namelen
  * characters of name for matching the property name.
  */
+#ifndef SWIG /* Not available in Python */
 const struct fdt_property *fdt_get_property_namelen(const void *fdt,
int nodeoffset,
const char *name,
int namelen, int *lenp);
+#endif
 
 /**
  * fdt_get_property - find a given property in a given node
@@ -624,8 +631,10 @@ static inline struct fdt_property *fdt_get_property_w(void 
*fdt, int nodeoffset,
  * -FDT_ERR_BADSTRUCTURE,
  * -FDT_ERR_TRUNCATED, standard meanings
  */
+#ifndef SWIG /* This function is not useful in Python */
 const void *fdt_getprop_by_offset(const void *fdt, int offset,
  const char **namep, int *lenp);
+#endif
 
 /**
  * fdt_getprop_namelen - get property value based on substring
@@ -638,6 +647,7 @@ const void *fdt_getprop_by_offset(const void *fdt, int 
offset,
  * Identical to fdt_getprop(), but only examine the first namelen
  * characters of name for matching the property name.
  */
+#ifndef SWIG /* Not available in Python */
 const void *fdt_getprop_namelen(const void *fdt, int nodeoffset,
const char *name, int namelen, int *lenp);
 static inline void *fdt_getprop_namelen_w(void *fdt, int nodeoffset,
@@ -647,6 +657,7 @@ static inline void *fdt_getprop_namelen_w(void *fdt, int 
nodeoffset,
return (void *)(uintptr_t)fdt_getprop_namelen(fdt, nodeoffset, name,
  namelen, lenp);
 }
+#endif
 
 /**
  * fdt_getprop - retrieve the value of a given property
@@ -707,8 +718,10 @@ uint32_t fdt_get_phandle(const void *fdt, int nodeoffset);
  * Identical to fdt_get_alias(), but only examine the first namelen
  * characters of name for matching the alias name.
  */
+#ifndef SWIG /* Not available in Python */
 const char *fdt_get_alias_namelen(const void *fdt,
  const char *name, int namelen);
+#endif
 
 /**
  * fdt_get_alias - retrieve the path referenced by a given alias
@@ -1106,10 +1119,12 @@ int fdt_size_cells(const void *fdt, int nodeoffset);
  * of the name. It is useful when you want to manipulate 

[PATCH 11/45] libfdt: Add fdt_setprop_inplace_namelen_partial

[Sebastian Huber]

From: Maxime Ripard 

Add a function to modify inplace only a portion of a property..

This is especially useful when the property is an array of values, and you
want to update one of them without changing the DT size.

Acked-by: Simon Glass 
Reviewed-by: David Gibson 
Signed-off-by: Maxime Ripard 
[dwg: Remove unnecessary unsigned qualifier, correct a comment]
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_wip.c | 29 +
 cpukit/include/libfdt.h | 21 +
 2 files changed, 46 insertions(+), 4 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt_wip.c b/cpukit/dtc/libfdt/fdt_wip.c
index c5bbb68d32..6aaab39992 100644
--- a/cpukit/dtc/libfdt/fdt_wip.c
+++ b/cpukit/dtc/libfdt/fdt_wip.c
@@ -55,21 +55,42 @@
 
 #include "libfdt_internal.h"
 
+int fdt_setprop_inplace_namelen_partial(void *fdt, int nodeoffset,
+   const char *name, int namelen,
+   uint32_t idx, const void *val,
+   int len)
+{
+   void *propval;
+   int proplen;
+
+   propval = fdt_getprop_namelen_w(fdt, nodeoffset, name, namelen,
+   );
+   if (!propval)
+   return proplen;
+
+   if (proplen < (len + idx))
+   return -FDT_ERR_NOSPACE;
+
+   memcpy((char *)propval + idx, val, len);
+   return 0;
+}
+
 int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
const void *val, int len)
 {
-   void *propval;
+   const void *propval;
int proplen;
 
-   propval = fdt_getprop_w(fdt, nodeoffset, name, );
+   propval = fdt_getprop(fdt, nodeoffset, name, );
if (! propval)
return proplen;
 
if (proplen != len)
return -FDT_ERR_NOSPACE;
 
-   memcpy(propval, val, len);
-   return 0;
+   return fdt_setprop_inplace_namelen_partial(fdt, nodeoffset, name,
+  strlen(name), 0,
+  val, len);
 }
 
 static void _fdt_nop_region(void *start, int len)
diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index 0189350fb3..376e628150 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -1080,6 +1080,27 @@ int fdt_size_cells(const void *fdt, int nodeoffset);
 /**/
 
 /**
+ * fdt_setprop_inplace_namelen_partial - change a property's value,
+ *   but not its size
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to change
+ * @name: name of the property to change
+ * @namelen: number of characters of name to consider
+ * @idx: index of the property to change in the array
+ * @val: pointer to data to replace the property value with
+ * @len: length of the property value
+ *
+ * Identical to fdt_setprop_inplace(), but modifies the given property
+ * starting from the given index, and using only the first characters
+ * of the name. It is useful when you want to manipulate only one value of
+ * an array and you have a string that doesn't end with \0.
+ */
+int fdt_setprop_inplace_namelen_partial(void *fdt, int nodeoffset,
+   const char *name, int namelen,
+   uint32_t idx, const void *val,
+   int len);
+
+/**
  * fdt_setprop_inplace - change a property's value, but not its size
  * @fdt: pointer to the device tree blob
  * @nodeoffset: offset of the node whose property to change
-- 
2.13.7

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

[PATCH 01/45] libfdt: check for potential overrun in _fdt_splice()

[Sebastian Huber]

From: Courtney Cavin 

This patch catches the conditions where:
 - 'splicepoint' is set to a point outside of [ fdt, fdt_totalsize(fdt) )
 - 'newlen' is negative, or 'splicepoint' plus 'newlen' results in overflow

Either of these cases can be caused by math which overflows in calling
functions, or by sizes specified through dynamic means.

Signed-off-by: Courtney Cavin 
Signed-off-by: Bjorn Andersson 
---
 cpukit/dtc/libfdt/fdt_rw.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/cpukit/dtc/libfdt/fdt_rw.c b/cpukit/dtc/libfdt/fdt_rw.c
index 70adec6c37..8be02b1f68 100644
--- a/cpukit/dtc/libfdt/fdt_rw.c
+++ b/cpukit/dtc/libfdt/fdt_rw.c
@@ -101,6 +101,8 @@ static int _fdt_splice(void *fdt, void *splicepoint, int 
oldlen, int newlen)
 
if (((p + oldlen) < p) || ((p + oldlen) > end))
return -FDT_ERR_BADOFFSET;
+   if ((p < (char *)fdt) || ((end - oldlen + newlen) < (char *)fdt))
+   return -FDT_ERR_BADOFFSET;
if ((end - oldlen + newlen) > ((char *)fdt + fdt_totalsize(fdt)))
return -FDT_ERR_NOSPACE;
memmove(p + newlen, p + oldlen, end - p - oldlen);
-- 
2.13.7

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

[PATCH 29/45] Fix some errors in comments

[Sebastian Huber]

From: David Gibson 

A comment in tests/stringlist.c refers to fdt_get_string(), which is not a
function that exists.  From the content, it's supposed to be referring to
fdt_getprop_string().

A comment in libfdt.h has an extraneous space in a function name.

Signed-off-by: David Gibson 
---
 cpukit/include/libfdt.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index 313c72a2d1..c8865208df 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -1449,7 +1449,7 @@ int fdt_setprop(void *fdt, int nodeoffset, const char 
*name,
const void *val, int len);
 
 /**
- * fdt_setprop _placeholder - allocate space for a property
+ * fdt_setprop_placeholder - allocate space for a property
  * @fdt: pointer to the device tree blob
  * @nodeoffset: offset of the node whose property to change
  * @name: name of the property to change
-- 
2.13.7

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

[PATCH 14/45] libfdt: Add new errors for the overlay code

[Sebastian Huber]

From: Maxime Ripard 

Add a few new error codes to report the failure conditions we might
encounter in the overlay application code:
   - FDT_ERR_BADOVERLAY, when an overlay cannot be parsed, even though its
 structure is correct
   - FDT_ERR_NOPHANDLES, when we ran out of available phandles and we
 cannot use a new phandle without either using an invalid one (-1 or
 0), or one already used.

Signed-off-by: Maxime Ripard 
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_strerror.c |  3 +++
 cpukit/include/libfdt.h  | 11 ++-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/cpukit/dtc/libfdt/fdt_strerror.c b/cpukit/dtc/libfdt/fdt_strerror.c
index e6c3ceee8c..3cb357f604 100644
--- a/cpukit/dtc/libfdt/fdt_strerror.c
+++ b/cpukit/dtc/libfdt/fdt_strerror.c
@@ -76,6 +76,9 @@ static struct fdt_errtabent fdt_errtable[] = {
FDT_ERRTABENT(FDT_ERR_BADVERSION),
FDT_ERRTABENT(FDT_ERR_BADSTRUCTURE),
FDT_ERRTABENT(FDT_ERR_BADLAYOUT),
+   FDT_ERRTABENT(FDT_ERR_BADOVERLAY),
+   FDT_ERRTABENT(FDT_ERR_BADOVERLAY),
+   FDT_ERRTABENT(FDT_ERR_NOPHANDLES),
 };
 #define FDT_ERRTABSIZE (sizeof(fdt_errtable) / sizeof(fdt_errtable[0]))
 
diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index ecb11fc9e9..361cc6c719 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -126,7 +126,16 @@
 * value. For example: a property expected to contain a string list
 * is not NUL-terminated within the length of its value. */
 
-#define FDT_ERR_MAX15
+#define FDT_ERR_BADOVERLAY 16
+   /* FDT_ERR_BADOVERLAY: The device tree overlay, while
+* correctly structured, cannot be applied due to some
+* unexpected or missing value, property or node. */
+
+#define FDT_ERR_NOPHANDLES 17
+   /* FDT_ERR_NOPHANDLES: The device tree doesn't have any
+* phandle available anymore without causing an overflow */
+
+#define FDT_ERR_MAX17
 
 /**/
 /* Low-level functions (you probably don't need these)*/
-- 
2.13.7

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

[PATCH 26/45] Add a libfdt function to write a property placeholder

[Sebastian Huber]

From: Simon Glass 

The existing function to add a new property to a tree being built requires
that the entire contents of the new property be passed in. For some
applications it is more convenient to be able to add the property contents
later, perhaps by reading from a file. This avoids double-buffering of the
contents.

Add a new function to support this and adjust the existing fdt_property() to
use it.
Signed-off-by: Simon Glass 
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_sw.c | 16 ++--
 cpukit/include/libfdt.h| 16 
 2 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt_sw.c b/cpukit/dtc/libfdt/fdt_sw.c
index 6a804859fd..2bd15e7aef 100644
--- a/cpukit/dtc/libfdt/fdt_sw.c
+++ b/cpukit/dtc/libfdt/fdt_sw.c
@@ -220,7 +220,7 @@ static int _fdt_find_add_string(void *fdt, const char *s)
return offset;
 }
 
-int fdt_property(void *fdt, const char *name, const void *val, int len)
+int fdt_property_placeholder(void *fdt, const char *name, int len, void **valp)
 {
struct fdt_property *prop;
int nameoff;
@@ -238,7 +238,19 @@ int fdt_property(void *fdt, const char *name, const void 
*val, int len)
prop->tag = cpu_to_fdt32(FDT_PROP);
prop->nameoff = cpu_to_fdt32(nameoff);
prop->len = cpu_to_fdt32(len);
-   memcpy(prop->data, val, len);
+   *valp = prop->data;
+   return 0;
+}
+
+int fdt_property(void *fdt, const char *name, const void *val, int len)
+{
+   void *ptr;
+   int ret;
+
+   ret = fdt_property_placeholder(fdt, name, len, );
+   if (ret)
+   return ret;
+   memcpy(ptr, val, len);
return 0;
 }
 
diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index 2c9ddb4867..a248b1b57a 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -1314,6 +1314,22 @@ static inline int fdt_property_cell(void *fdt, const 
char *name, uint32_t val)
 {
return fdt_property_u32(fdt, name, val);
 }
+
+/**
+ * fdt_property_placeholder - add a new property and return a ptr to its value
+ *
+ * @fdt: pointer to the device tree blob
+ * @name: name of property to add
+ * @len: length of property value in bytes
+ * @valp: returns a pointer to where where the value should be placed
+ *
+ * returns:
+ * 0, on success
+ * -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_NOSPACE, standard meanings
+ */
+int fdt_property_placeholder(void *fdt, const char *name, int len, void 
**valp);
+
 #define fdt_property_string(fdt, name, str) \
fdt_property(fdt, name, str, strlen(str)+1)
 int fdt_end_node(void *fdt);
-- 
2.13.7

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

[PATCH 05/45] Correct line lengths in libfdt.h

[Sebastian Huber]

From: Simon Glass 

There are a few lines that are over 80 columns. Fix these.

Signed-off-by: Simon Glass 
Signed-off-by: David Gibson 
---
 cpukit/include/libfdt.h | 35 +++
 1 file changed, 23 insertions(+), 12 deletions(-)

diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index 25311cbfe7..2c7b4e876c 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -318,8 +318,9 @@ int fdt_subnode_offset_namelen(const void *fdt, int 
parentoffset,
  * returns:
  * structure block offset of the requested subnode (>=0), on success
  * -FDT_ERR_NOTFOUND, if the requested subnode does not exist
- * -FDT_ERR_BADOFFSET, if parentoffset did not point to an FDT_BEGIN_NODE 
tag
- *  -FDT_ERR_BADMAGIC,
+ * -FDT_ERR_BADOFFSET, if parentoffset did not point to an FDT_BEGIN_NODE
+ * tag
+ * -FDT_ERR_BADMAGIC,
  * -FDT_ERR_BADVERSION,
  * -FDT_ERR_BADSTATE,
  * -FDT_ERR_BADSTRUCTURE,
@@ -351,7 +352,8 @@ int fdt_path_offset_namelen(const void *fdt, const char 
*path, int namelen);
  * address).
  *
  * returns:
- * structure block offset of the node with the requested path (>=0), on 
success
+ * structure block offset of the node with the requested path (>=0), on
+ * success
  * -FDT_ERR_BADPATH, given path does not begin with '/' or is invalid
  * -FDT_ERR_NOTFOUND, if the requested node does not exist
  *  -FDT_ERR_BADMAGIC,
@@ -375,10 +377,12 @@ int fdt_path_offset(const void *fdt, const char *path);
  *
  * returns:
  * pointer to the node's name, on success
- * If lenp is non-NULL, *lenp contains the length of that name 
(>=0)
+ * If lenp is non-NULL, *lenp contains the length of that name
+ * (>=0)
  * NULL, on error
  * if lenp is non-NULL *lenp contains an error code (<0):
- * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE 
tag
+ * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE
+ * tag
  * -FDT_ERR_BADMAGIC,
  * -FDT_ERR_BADVERSION,
  * -FDT_ERR_BADSTATE, standard meanings
@@ -490,7 +494,8 @@ const struct fdt_property *fdt_get_property_namelen(const 
void *fdt,
  * NULL, on error
  * if lenp is non-NULL, *lenp contains an error code (<0):
  * -FDT_ERR_NOTFOUND, node does not have named property
- * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE 
tag
+ * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE
+ * tag
  * -FDT_ERR_BADMAGIC,
  * -FDT_ERR_BADVERSION,
  * -FDT_ERR_BADSTATE,
@@ -575,7 +580,8 @@ const void *fdt_getprop_namelen(const void *fdt, int 
nodeoffset,
  * NULL, on error
  * if lenp is non-NULL, *lenp contains an error code (<0):
  * -FDT_ERR_NOTFOUND, node does not have named property
- * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE 
tag
+ * -FDT_ERR_BADOFFSET, nodeoffset did not point to FDT_BEGIN_NODE
+ * tag
  * -FDT_ERR_BADMAGIC,
  * -FDT_ERR_BADVERSION,
  * -FDT_ERR_BADSTATE,
@@ -680,7 +686,8 @@ int fdt_get_path(const void *fdt, int nodeoffset, char 
*buf, int buflen);
  * structure block offset of the node at node offset's ancestor
  * of depth supernodedepth (>=0), on success
  * -FDT_ERR_BADOFFSET, nodeoffset does not refer to a BEGIN_NODE tag
- * -FDT_ERR_NOTFOUND, supernodedepth was greater than the depth of 
nodeoffset
+ * -FDT_ERR_NOTFOUND, supernodedepth was greater than the depth of
+ * nodeoffset
  * -FDT_ERR_BADMAGIC,
  * -FDT_ERR_BADVERSION,
  * -FDT_ERR_BADSTATE,
@@ -959,7 +966,8 @@ const char *fdt_stringlist_get(const void *fdt, int 
nodeoffset,
  * returns:
  * 0 <= n < FDT_MAX_NCELLS, on success
  *  2, if the node has no #address-cells property
- *  -FDT_ERR_BADNCELLS, if the node has a badly formatted or invalid 
#address-cells property
+ *  -FDT_ERR_BADNCELLS, if the node has a badly formatted or invalid
+ * #address-cells property
  * -FDT_ERR_BADMAGIC,
  * -FDT_ERR_BADVERSION,
  * -FDT_ERR_BADSTATE,
@@ -979,7 +987,8 @@ int fdt_address_cells(const void *fdt, int nodeoffset);
  * returns:
  * 0 <= n < FDT_MAX_NCELLS, on success
  *  2, if the node has no #address-cells property
- *  -FDT_ERR_BADNCELLS, if the node has a badly formatted or invalid 
#size-cells property
+ *  -FDT_ERR_BADNCELLS, if the node has a badly formatted or invalid
+ * #size-cells property
  * -FDT_ERR_BADMAGIC,
  * -FDT_ERR_BADVERSION,
  * -FDT_ERR_BADSTATE,
@@ -1603,9 +1612,11 @@ int fdt_add_subnode_namelen(void *fdt, int parentoffset,
  * change the offsets of some existing nodes.
 
  * returns:
- * 

[PATCH 12/45] libfdt: simplify fdt_del_mem_rsv()

[Sebastian Huber]

From: Masahiro Yamada 

The variable "err" is unneeded.

Signed-off-by: Masahiro Yamada 
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_rw.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt_rw.c b/cpukit/dtc/libfdt/fdt_rw.c
index 8be02b1f68..2eed4f5838 100644
--- a/cpukit/dtc/libfdt/fdt_rw.c
+++ b/cpukit/dtc/libfdt/fdt_rw.c
@@ -191,17 +191,13 @@ int fdt_add_mem_rsv(void *fdt, uint64_t address, uint64_t 
size)
 int fdt_del_mem_rsv(void *fdt, int n)
 {
struct fdt_reserve_entry *re = _fdt_mem_rsv_w(fdt, n);
-   int err;
 
FDT_RW_CHECK_HEADER(fdt);
 
if (n >= fdt_num_mem_rsv(fdt))
return -FDT_ERR_NOTFOUND;
 
-   err = _fdt_splice_mem_rsv(fdt, re, 1, 0);
-   if (err)
-   return err;
-   return 0;
+   return _fdt_splice_mem_rsv(fdt, re, 1, 0);
 }
 
 static int _fdt_resize_property(void *fdt, int nodeoffset, const char *name,
-- 
2.13.7

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

[PATCH 08/45] libfdt: Add iterator over properties

[Sebastian Huber]

From: Maxime Ripard 

Implement a macro based on fdt_first_property_offset and
fdt_next_property_offset that provides a convenience to iterate over all
the properties of a given node.

Signed-off-by: Maxime Ripard 
Acked-by: Simon Glass 
[dwg: Removed a stray trailing blank line]
Signed-off-by: David Gibson 
---
 cpukit/include/libfdt.h | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index 911e548163..be109a8aac 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -459,6 +459,33 @@ int fdt_first_property_offset(const void *fdt, int 
nodeoffset);
 int fdt_next_property_offset(const void *fdt, int offset);
 
 /**
+ * fdt_for_each_property_offset - iterate over all properties of a node
+ *
+ * @property_offset:   property offset (int, lvalue)
+ * @fdt:   FDT blob (const void *)
+ * @node:  node offset (int)
+ *
+ * This is actually a wrapper around a for loop and would be used like so:
+ *
+ * fdt_for_each_property_offset(property, fdt, node) {
+ * Use property
+ * ...
+ * }
+ *
+ * if ((property < 0) && (property != -FDT_ERR_NOT_FOUND)) {
+ * Error handling
+ * }
+ *
+ * Note that this is implemented as a macro and property is used as
+ * iterator in the loop. The node variable can be constant or even a
+ * literal.
+ */
+#define fdt_for_each_property_offset(property, fdt, node)  \
+   for (property = fdt_first_property_offset(fdt, node);   \
+property >= 0; \
+property = fdt_next_property_offset(fdt, property))
+
+/**
  * fdt_get_property_by_offset - retrieve the property at a given offset
  * @fdt: pointer to the device tree blob
  * @offset: offset of the property to retrieve
-- 
2.13.7

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

[PATCH 02/45] libfdt: Fix undefined behaviour in fdt_offset_ptr()

[Sebastian Huber]

From: David Gibson 

Using pointer arithmetic to generate a pointer outside a known object is,
technically, undefined behaviour in C.  Unfortunately, we were using that
in fdt_offset_ptr() to detect overflows.

To fix this we need to do our bounds / overflow checking on the offsets
before constructing pointers from them.

Reported-by: David Binderman 
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt.c b/cpukit/dtc/libfdt/fdt.c
index 2ce6a44179..22286a1aae 100644
--- a/cpukit/dtc/libfdt/fdt.c
+++ b/cpukit/dtc/libfdt/fdt.c
@@ -76,18 +76,19 @@ int fdt_check_header(const void *fdt)
 
 const void *fdt_offset_ptr(const void *fdt, int offset, unsigned int len)
 {
-   const char *p;
+   unsigned absoffset = offset + fdt_off_dt_struct(fdt);
+
+   if ((absoffset < offset)
+   || ((absoffset + len) < absoffset)
+   || (absoffset + len) > fdt_totalsize(fdt))
+   return NULL;
 
if (fdt_version(fdt) >= 0x11)
if (((offset + len) < offset)
|| ((offset + len) > fdt_size_dt_struct(fdt)))
return NULL;
 
-   p = _fdt_offset_ptr(fdt, offset);
-
-   if (p + len < p)
-   return NULL;
-   return p;
+   return _fdt_offset_ptr(fdt, offset);
 }
 
 uint32_t fdt_next_tag(const void *fdt, int startoffset, int *nextoffset)
-- 
2.13.7

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

[PATCH 06/45] Correct a missing space in a fdt_header cast

[Sebastian Huber]

From: Simon Glass 

The code style here is slightly incorrect. Fix it.

Signed-off-by: Simon Glass 
Signed-off-by: David Gibson 
---
 cpukit/include/libfdt.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index 2c7b4e876c..36222fd4a6 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -188,7 +188,7 @@ int fdt_next_subnode(const void *fdt, int offset);
 #define __fdt_set_hdr(name) \
static inline void fdt_set_##name(void *fdt, uint32_t val) \
{ \
-   struct fdt_header *fdth = (struct fdt_header*)fdt; \
+   struct fdt_header *fdth = (struct fdt_header *)fdt; \
fdth->name = cpu_to_fdt32(val); \
}
 __fdt_set_hdr(magic);
-- 
2.13.7

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

[PATCH 03/45] libfdt: simplify fdt_node_check_compatible()

[Sebastian Huber]

From: Masahiro Yamada 

Because fdt_stringlist_contains() returns 1 or 0,
fdt_node_check_compatible() can just return the inverted value.

Signed-off-by: Masahiro Yamada 
Signed-off-by: David Gibson 
---
 cpukit/dtc/libfdt/fdt_ro.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/cpukit/dtc/libfdt/fdt_ro.c b/cpukit/dtc/libfdt/fdt_ro.c
index e5b3136820..50cce86428 100644
--- a/cpukit/dtc/libfdt/fdt_ro.c
+++ b/cpukit/dtc/libfdt/fdt_ro.c
@@ -647,10 +647,8 @@ int fdt_node_check_compatible(const void *fdt, int 
nodeoffset,
prop = fdt_getprop(fdt, nodeoffset, "compatible", );
if (!prop)
return len;
-   if (fdt_stringlist_contains(prop, len, compatible))
-   return 0;
-   else
-   return 1;
+
+   return !fdt_stringlist_contains(prop, len, compatible);
 }
 
 int fdt_node_offset_by_compatible(const void *fdt, int startoffset,
-- 
2.13.7

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

[PATCH 13/45] Fix some typing errors in libfdt.h and livetree.c

[Sebastian Huber]

From: Thomas Huth 

Correct some typos discovered with the codespell utility.

Signed-off-by: Thomas Huth 
Signed-off-by: David Gibson 
---
 cpukit/include/libfdt.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/cpukit/include/libfdt.h b/cpukit/include/libfdt.h
index 376e628150..ecb11fc9e9 100644
--- a/cpukit/include/libfdt.h
+++ b/cpukit/include/libfdt.h
@@ -61,7 +61,7 @@
 #define FDT_ERR_NOTFOUND   1
/* FDT_ERR_NOTFOUND: The requested node or property does not exist */
 #define FDT_ERR_EXISTS 2
-   /* FDT_ERR_EXISTS: Attemped to create a node or property which
+   /* FDT_ERR_EXISTS: Attempted to create a node or property which
 * already exists */
 #define FDT_ERR_NOSPACE3
/* FDT_ERR_NOSPACE: Operation needed to expand the device
@@ -700,7 +700,7 @@ const char *fdt_get_alias_namelen(const void *fdt,
  const char *name, int namelen);
 
 /**
- * fdt_get_alias - retreive the path referenced by a given alias
+ * fdt_get_alias - retrieve the path referenced by a given alias
  * @fdt: pointer to the device tree blob
  * @name: name of the alias th look up
  *
-- 
2.13.7

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

Re: [GSoC - x86_64] Clock driver - which hardware source to support primarily?

[Amaan Cheval]

Hi!

Thanks a ton for all the details, they definitely help clarify the
direction a fair bit. I think we're settling on working on interrupt
support and the APIC timer (and some PIT work to calibrate the APIC
timer) in the immediate future.

After ticker.exe passes through the APIC timer, we'll have a nearly
complete BSP and then the rtems-tools can be fixed up to let us run
tests more easily, and we can also look into alternate bootloaders for
UEFI-awareness instead of FreeBSD's.

Let me know if anyone disagrees with that?

On Tue, Jul 17, 2018 at 11:04 PM, Joel Sherrill  wrote:
>
>
> On Tue, Jul 17, 2018 at 12:18 PM, Amaan Cheval 
> wrote:
>>
>> Hi!
>>
>> Now that I'm working on the clock driver, we need to pick what we
>> support first. Our options in brief are:
>>
>> - rdtsc; will need calibration through the PIT or one of the other options
>
>
> Can this generate an interrupt?

Nope, it's only an instruction that reads out the value held in the
timestamp counter. It can be used to determine the time since the last
interrupt - something as simple as:

last_interrupt = rdtsc();
// ...;
time_since_last_interrupt = rdtsc() - last_interrupt;

I'm now leaning towards the APIC timer (read on), so this may not be
used at all.

>
> This is currently used to get the offset since the last tick and
> there is calibration code in pc386. Of course, that likely uses
> the PIT so is just a guide.
>
>>
>> - PIT; likely not given how legacy it is, but it may be quite simple
>
>
> Legacy. Preferably off the table as a permanent solution.
>
> How legacy is it? It doesn't seem to have disappeared like IO ports,
> non-UEFI booting, etc.

It's one of the "classic" timers - basically guaranteed to be there
(unlike _most_ of the other options in consideration). It's not our
ideal option, but I think we'll inevitably need it as a fallback, and
to synchronize the other timers during initialization. Our support may
not need to be full-fledged if we can assume processors recent enough
to support APIC timers, which really _should_ be the case on just
about anything modern enough to include UEFI firmware anyway.

>
>>
>> - APIC timer[1]; better for long-term as it's independent of multiple
>> core time sync problems in general, and it also has multiple modes,
>> including having the timer generate deadline interrupts instead of the
>> "polled" ticking method. It'll need better interrupt support and ACPI
>> to detect/use.
>
>
> I had hoped we would end up here.
>
> Looks like it needs to be calibrated and likely you can read the
> counter to see how long it has been running since the IRQ was
> generated. Plus you can read it for the time since last IRQ.
>
> Good and self-contained I think.

Agreed - if interrupts are an absolute must, the APIC timer can do
everything we need, with only a little help during calibration from
the PIT.

>
>>
>>
>> - HPET[2] (high-precision event timer); may be the "best" option -
>> it's fairly modern, highly accurate. Only downside is it needing ACPI
>> to detect and use (as opposed to usually CPUID for the others)
>
>
> Is this present on all CPUs? What's the lowest model? Would this
> be a limiting a factor?

I don't really know, nor do I know how to find it out without much
more research.

>
> Another consideration is that this may best be left alone since
> it may make sense to have it available for applications needing
> a secondary timer.
>
> Finally, it simply looks fairly complex to deal with. You have to
> detect it, can be at different IO addresses, and (worst) may not
> be present at all and you have to have APIC timer support anyway.
>

Right, I think I'm leaning away from even considering this for the
reasons you listed.

>>
>>
>> - RTC; legacy real-time clock - not really a good option in my
>> understanding because it's often too slow for real use-cases needing
>> the high precision
>
>
> This is a bad option and was even for pc386. I don't recall if it
> could even generate an interrupt but the granularity was bad.
>
>>
>>
>> I suspect using rdtsc+pit (option 1) is likely the best for now in
>> providing us with speed (rdtsc is much faster than the PIT, I've read)
>> and ease-of-development (for the port, that is).
>
>
> If speed == ease-of-development, this is the best option since you
> have code to reuse.
>
> APIC timer has to be there even if in the future, the HPET is
> supported.
>
>>
>>
>> Using the APIC timer may work well as well since basic ACPI and
>> interrupt support are likely important for this port (for eg.
>> currently, the port doesn't know how to reset the system at all, until
>> we look into ACPI more). This will likely take a while but help the
>> port be much more well-rounded for future growth.
>
>
> I think this is most likely the preferred option.
>
> Is the TSC needed for time since last interrupt or can that be
> determined directly from the APIC timer?

I think it can be determined from the APIC timer directly with a
little calculation to convert 

[PATCH] cpu-supplement: Update interrupt stack paragraph

[Sebastian Huber]

Close #3459.
---
 cpu-supplement/port.rst | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/cpu-supplement/port.rst b/cpu-supplement/port.rst
index dec91a7..bf1de3e 100644
--- a/cpu-supplement/port.rst
+++ b/cpu-supplement/port.rst
@@ -222,9 +222,9 @@ switches to this dedicated stack.  On architectures without 
hardware support
 for a dedicated interrupt stack which is separate from those of the tasks,
 RTEMS will support switching to a dedicated stack for interrupt processing.
 
-Without a dedicated interrupt stack, every task in the system MUST have enough
+Without a dedicated interrupt stack, every task in the system must have enough
 stack space to accommodate the worst case stack usage of that particular task
-and the interrupt service routines COMBINED.  By supporting a dedicated
+and the interrupt service routines combined.  By supporting a dedicated
 interrupt stack, RTEMS significantly lowers the stack requirements for each
 task.
 
@@ -232,16 +232,20 @@ A nested interrupt is processed similarly with the 
exception that since the CPU
 is already executing on the interrupt stack, there is no need to switch to the
 interrupt stack.
 
-In some configurations, RTEMS allocates the interrupt stack from the Workspace
-Area.  The amount of memory allocated for the interrupt stack is user
-configured and based upon the ``confdefs.h`` parameter
+The interrupt stacks (one for each configured processor) are statically
+allocated by the application configuration via  in the
+special section ``.rtemsstack``.  This enables an optimal placement of the
+interrupt stacks by the Board Support Package (BSP), e.g. a fast on-chip
+memory.  The amount of memory allocated for each interrupt stack is user
+configured and based upon the  parameter
 ``CONFIGURE_INTERRUPT_STACK_SIZE``.  This parameter is described in detail in
-the Configuring a System chapter of the User's Guide.  On configurations in
-which RTEMS allocates the interrupt stack, during the initialization process,
-RTEMS will also install its interrupt stack.  In other configurations, the
-interrupt stack is allocated and installed by the Board Support Package (BSP).
+the Configuring a System chapter of the User's Guide.  Since interrupts are
+disabled during the sequential system initialization and the
+``_Thread_Start_multitasking()`` function does not return to the caller each
+interrupt stack may be used for the initialization stack on the corresponding
+processor.
 
-In each of the architecture specific chapters, this section discesses the
+In each of the architecture specific chapters, this section discusses the
 interrupt response and control mechanisms of the architecture as they pertain
 to RTEMS.
 
-- 
2.13.7

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