Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

On 04/03/2020 07:07, Sebastian Huber wrote:
> On 04/03/2020 05:55, Chris Johns wrote:
>>> I think for Boards that normally run a Linux it is a sane approach to
>>> just replace the Linux Kernel with a RTEMS binary and otherwise keep the
>>> boot process with for example U-Boot. Everything else is a lot of extra
>>> effort to implement and not necessary in a lot of situations.
>> Is there documentation about that shows this process for an existing
>> board?
>>
>> I get what you are saying and it make prefect sense and it would be no
>> issue for
>> me to do this however there are a number of steps involved and there is a
>> certain amount of assumed knowledge here. How do we establish a
>> framework or
>> template that lets are capture this so it is useful and usable to our
>> users?
> 
> My approach would be to use the devices trees shipped by the hardware
> vendor and fix our drivers if necessary. For example, I had to adjust
> the Altera Cyclone V BSP for these modules:
> 
> https://www.enclustra.com/en/products/system-on-chip-modules/mars-ma3/
> 
> The device tree has a different clock structure compared to the Altera
> Development Kit, so the update_clocks() function supports both:
> 
> https://git.rtems.org/rtems/tree/bsps/arm/altera-cyclone-v/start/bspstart.c#n79
> 
> 

Hello Sebastian,

note that the version delivered with a board is very undefined and it is
not necessarily the same for two boards with a different production
date. So it's quite hard to reproduce a special FDT that works together
with a special version of a BSP. So some method to archive them and say
"that BSP works with this FDT" isn't a bad idea.

Best regards

Christian

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

Hello Chris,

On 04/03/2020 05:55, Chris Johns wrote:
> Sorry about delay in getting back to this. I have been focused on getting the
> release into something close to what we want for RC1.

No problem. The release is relevant for all of us.

> 
> On 28/2/20 9:48 pm, Christian Mauderer wrote:
>> Hello Gedare and Chris,
>>
>> On 27/02/2020 23:14, Gedare Bloom wrote:
>>> On Thu, Feb 27, 2020 at 3:01 PM Chris Johns  wrote:

 On 28/2/20 7:23 am, Alan Cudmore wrote:
> I noticed that the Zephyr RTOS (https://www.zephyrproject.org) uses a
> device tree based initialization for all of its BSPs.
> For example, here is the top level device tree source for the Adafruit
> Trinket M0, which is a very small Atmel Cortex M0 based board:
> https://github.com/zephyrproject-rtos/zephyr/blob/master/boards/arm/adafruit_trinket_m0/adafruit_trinket_m0.dts
>
> The rest of the device tree source for common processors and devices are 
> here:
> https://github.com/zephyrproject-rtos/zephyr/tree/master/dts
>
> To me, it looks like they have to develop (or port) and maintain
> device trees for each board and device that is supported.
>
> Does that look like a model that RTEMS could use? I'm not sure I
> understand everything that deploying such a model implies, or if it
> just makes more sense to use the existing FreeBSD or linux device
> trees.

 This is where I was heading in my thinking but I am not sure. I am 
 settling on
 having a dts tree in rtems.git and we may just have to manually manage the
 files. I am not sure there are enough files to warrant a system like 
 libbsd and
 FreeBSD at this point in time. That may change with the new build system 
 and
 python being available however until then manual is fine. Let me explain 
 ...

 I have been looking beyond the internal development aspects and to how we 
 use
 FDT blobs and I am wondering if the approach we have with the shared FDT 
 BSP
 support is the right fit for RTEMS and a statically linked executable.

 I believe currently we need a suitable bootloader, ie u-boot, to load a 
 blob.
 This is the Linux way of doing things and this may be the right approach 
 for
 Linux but I am not so sure it is for us. It means you need u-boot and a 
 suitable
 file system plus you have a lot more items to configuration manage in 
 production
 systems and a lot more complexity for self upgrading.
>>
>> I think for Boards that normally run a Linux it is a sane approach to
>> just replace the Linux Kernel with a RTEMS binary and otherwise keep the
>> boot process with for example U-Boot. Everything else is a lot of extra
>> effort to implement and not necessary in a lot of situations.
> 
> Is there documentation about that shows this process for an existing board?

To be honest: I don't know. Basically the description for the raspberry,
for BBB, for imx results in this. I haven't looked at the other BSPs
yet. But it isn't documented with this words.

> 
> I get what you are saying and it make prefect sense and it would be no issue 
> for
> me to do this however there are a number of steps involved and there is a
> certain amount of assumed knowledge here. How do we establish a framework or
> template that lets are capture this so it is useful and usable to our users?
> 

Basically the boot process should always be documented in the BSP
section of the manual. We maybe add some default cases:

1. Boards that normally run Linux: Suggestion: Use the same boot process
as Linux. For device trees: Use one delivered with the board (which only
maybe works) or use the one provided by the repository we are discussing
now (which should always work).

2. Boards that are not running Linux but want to use a FDT: I think we
currently don't have any. But if we would have ones, they most likely
have a small hand written FDT or one generated for example together with
a FPGA. Here it might would be a sane approach to link the FDT into the
application. Again: We don't have a BSP yet that is in that category so
not relevant for the release.

3. Boards that are not using an FDT. Most BSPs. The boot is very target
dependent. Not relevant for our current discussion.

>>

 Why do we have a bootloader load the FDT files when we statically link
 everything else?>>
 Why not link them into the executable and register them? It s easy to do.

>>
>> One BSP where it is a disadvantage to statically link is Raspberry Pi.
>> With the recent work you currently can use the same binary for RPi2 and
>> 3 with only a different FDT. Same for RPi1 and RPi Zero / Zero W.
> 
> Great example and a good point.
> 
>> I'm not against the possibility to link the FDT. But we should be open
>> to use both methods.
> 
> OK
> 
 The flow on from doing this has some real advantages. FDT files that are 
 linked
 into an executable 

Re: Device Tree Blob for Beaglebone Black?

[Sebastian Huber]

On 04/03/2020 05:55, Chris Johns wrote:

I think for Boards that normally run a Linux it is a sane approach to
just replace the Linux Kernel with a RTEMS binary and otherwise keep the
boot process with for example U-Boot. Everything else is a lot of extra
effort to implement and not necessary in a lot of situations.

Is there documentation about that shows this process for an existing board?

I get what you are saying and it make prefect sense and it would be no issue for
me to do this however there are a number of steps involved and there is a
certain amount of assumed knowledge here. How do we establish a framework or
template that lets are capture this so it is useful and usable to our users?


My approach would be to use the devices trees shipped by the hardware 
vendor and fix our drivers if necessary. For example, I had to adjust 
the Altera Cyclone V BSP for these modules:


https://www.enclustra.com/en/products/system-on-chip-modules/mars-ma3/

The device tree has a different clock structure compared to the Altera 
Development Kit, so the update_clocks() function supports both:


https://git.rtems.org/rtems/tree/bsps/arm/altera-cyclone-v/start/bspstart.c#n79

--
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: Device Tree Blob for Beaglebone Black?

[Chris Johns]

Sorry about delay in getting back to this. I have been focused on getting the
release into something close to what we want for RC1.

On 28/2/20 9:48 pm, Christian Mauderer wrote:
> Hello Gedare and Chris,
> 
> On 27/02/2020 23:14, Gedare Bloom wrote:
>> On Thu, Feb 27, 2020 at 3:01 PM Chris Johns  wrote:
>>>
>>> On 28/2/20 7:23 am, Alan Cudmore wrote:
 I noticed that the Zephyr RTOS (https://www.zephyrproject.org) uses a
 device tree based initialization for all of its BSPs.
 For example, here is the top level device tree source for the Adafruit
 Trinket M0, which is a very small Atmel Cortex M0 based board:
 https://github.com/zephyrproject-rtos/zephyr/blob/master/boards/arm/adafruit_trinket_m0/adafruit_trinket_m0.dts

 The rest of the device tree source for common processors and devices are 
 here:
 https://github.com/zephyrproject-rtos/zephyr/tree/master/dts

 To me, it looks like they have to develop (or port) and maintain
 device trees for each board and device that is supported.

 Does that look like a model that RTEMS could use? I'm not sure I
 understand everything that deploying such a model implies, or if it
 just makes more sense to use the existing FreeBSD or linux device
 trees.
>>>
>>> This is where I was heading in my thinking but I am not sure. I am settling 
>>> on
>>> having a dts tree in rtems.git and we may just have to manually manage the
>>> files. I am not sure there are enough files to warrant a system like libbsd 
>>> and
>>> FreeBSD at this point in time. That may change with the new build system and
>>> python being available however until then manual is fine. Let me explain ...
>>>
>>> I have been looking beyond the internal development aspects and to how we 
>>> use
>>> FDT blobs and I am wondering if the approach we have with the shared FDT BSP
>>> support is the right fit for RTEMS and a statically linked executable.
>>>
>>> I believe currently we need a suitable bootloader, ie u-boot, to load a 
>>> blob.
>>> This is the Linux way of doing things and this may be the right approach for
>>> Linux but I am not so sure it is for us. It means you need u-boot and a 
>>> suitable
>>> file system plus you have a lot more items to configuration manage in 
>>> production
>>> systems and a lot more complexity for self upgrading.
> 
> I think for Boards that normally run a Linux it is a sane approach to
> just replace the Linux Kernel with a RTEMS binary and otherwise keep the
> boot process with for example U-Boot. Everything else is a lot of extra
> effort to implement and not necessary in a lot of situations.

Is there documentation about that shows this process for an existing board?

I get what you are saying and it make prefect sense and it would be no issue for
me to do this however there are a number of steps involved and there is a
certain amount of assumed knowledge here. How do we establish a framework or
template that lets are capture this so it is useful and usable to our users?

> 
>>>
>>> Why do we have a bootloader load the FDT files when we statically link
>>> everything else?>>
>>> Why not link them into the executable and register them? It s easy to do.
>>>
> 
> One BSP where it is a disadvantage to statically link is Raspberry Pi.
> With the recent work you currently can use the same binary for RPi2 and
> 3 with only a different FDT. Same for RPi1 and RPi Zero / Zero W.

Great example and a good point.

> I'm not against the possibility to link the FDT. But we should be open
> to use both methods.

OK

>>> The flow on from doing this has some real advantages. FDT files that are 
>>> linked
>>> into an executable can then live in the rtems.git repo. If you move branches
>>> when testing or in production you do not need to manage and match suitable 
>>> FDT
>>> blobs.
>>>
>>> I am not advocating this is the only solution. I can see for some BSPs this 
>>> will
>>> not work and u-boot loading is the only or best solution. I however believe 
>>> for
>>> DTS that is open and available we should avoid the whole mess of needing to
>>> build and manage them on boot media separately to the executable.
> 
> Note the licensing issues if you use FreeBSD or Linux FDTs: They are
> GPL. If you statically link them you will infect other code too.

Ouch, that is a blocker to linking to the image. In light of this maybe any
effort to link it is not worth it. I wonder what you do with a board that needs
an FDT but has no media to hold one?

> Although for BSPs where no FDT exists it might is a good idea to write
> your own FDT and license it with a RTEMS compatible license. For BSPs
> like BBB it's not a good idea if you ask me. It's a lot of work.

Yes I agree.

>>> The issue of RTEMS version mismatch of blobs is a real issue waiting to hit 
>>> our
>>> users and simply linking the blobs into the executable would solve this.
> 
> Again: It opens licensing issues for our users!
> 

Understood. I had not considered 

Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

Hello Gedare and Chris,

On 27/02/2020 23:14, Gedare Bloom wrote:
> On Thu, Feb 27, 2020 at 3:01 PM Chris Johns  wrote:
>>
>> On 28/2/20 7:23 am, Alan Cudmore wrote:
>>> I noticed that the Zephyr RTOS (https://www.zephyrproject.org) uses a
>>> device tree based initialization for all of its BSPs.
>>> For example, here is the top level device tree source for the Adafruit
>>> Trinket M0, which is a very small Atmel Cortex M0 based board:
>>> https://github.com/zephyrproject-rtos/zephyr/blob/master/boards/arm/adafruit_trinket_m0/adafruit_trinket_m0.dts
>>>
>>> The rest of the device tree source for common processors and devices are 
>>> here:
>>> https://github.com/zephyrproject-rtos/zephyr/tree/master/dts
>>>
>>> To me, it looks like they have to develop (or port) and maintain
>>> device trees for each board and device that is supported.
>>>
>>> Does that look like a model that RTEMS could use? I'm not sure I
>>> understand everything that deploying such a model implies, or if it
>>> just makes more sense to use the existing FreeBSD or linux device
>>> trees.
>>
>> This is where I was heading in my thinking but I am not sure. I am settling 
>> on
>> having a dts tree in rtems.git and we may just have to manually manage the
>> files. I am not sure there are enough files to warrant a system like libbsd 
>> and
>> FreeBSD at this point in time. That may change with the new build system and
>> python being available however until then manual is fine. Let me explain ...
>>
>> I have been looking beyond the internal development aspects and to how we use
>> FDT blobs and I am wondering if the approach we have with the shared FDT BSP
>> support is the right fit for RTEMS and a statically linked executable.
>>
>> I believe currently we need a suitable bootloader, ie u-boot, to load a blob.
>> This is the Linux way of doing things and this may be the right approach for
>> Linux but I am not so sure it is for us. It means you need u-boot and a 
>> suitable
>> file system plus you have a lot more items to configuration manage in 
>> production
>> systems and a lot more complexity for self upgrading.

I think for Boards that normally run a Linux it is a sane approach to
just replace the Linux Kernel with a RTEMS binary and otherwise keep the
boot process with for example U-Boot. Everything else is a lot of extra
effort to implement and not necessary in a lot of situations.

>>
>> Why do we have a bootloader load the FDT files when we statically link
>> everything else?>>
>> Why not link them into the executable and register them? It s easy to do.
>>

One BSP where it is a disadvantage to statically link is Raspberry Pi.
With the recent work you currently can use the same binary for RPi2 and
3 with only a different FDT. Same for RPi1 and RPi Zero / Zero W.

I'm not against the possibility to link the FDT. But we should be open
to use both methods.

>> The flow on from doing this has some real advantages. FDT files that are 
>> linked
>> into an executable can then live in the rtems.git repo. If you move branches
>> when testing or in production you do not need to manage and match suitable 
>> FDT
>> blobs.
>>
>> I am not advocating this is the only solution. I can see for some BSPs this 
>> will
>> not work and u-boot loading is the only or best solution. I however believe 
>> for
>> DTS that is open and available we should avoid the whole mess of needing to
>> build and manage them on boot media separately to the executable.

Note the licensing issues if you use FreeBSD or Linux FDTs: They are
GPL. If you statically link them you will infect other code too.

Although for BSPs where no FDT exists it might is a good idea to write
your own FDT and license it with a RTEMS compatible license. For BSPs
like BBB it's not a good idea if you ask me. It's a lot of work.

>>
>> The issue of RTEMS version mismatch of blobs is a real issue waiting to hit 
>> our
>> users and simply linking the blobs into the executable would solve this.

Again: It opens licensing issues for our users!

>>
>> I am confronted by this now. I have a BBB with FDT blobs for libbsd master 
>> and
>> now I need to run libbsd 5-freebsd-12 to test a release. I have to open my 
>> test
>> set up open, pop the SD card and then update it. This seems unnecessary and
>> avoidable to me.
>>
>> This also looks like a blocker for CI testing.
>>
>> Chris
>>
> Hi Chris,
> 
> I'm 100% with you. I will also go a step further and advocate that
> source-based DTS -> dtc -> FDT in static images seems beneficial to
> users. I don't know if we could get any input from users to justify
> that, but I can see advantages for pre-qual and license compliance
> that go beyond the technical advantages that you discuss above.
> 
> Initial steps in this direction would make a good GSoC for the right
> (strong) student.

If Chris sees it as a blocker for the release, GSoC might is not the
right frame. It would need too much time and the result is not
guaranteed to be OK.

Maybe we 

Re: Device Tree Blob for Beaglebone Black?

[Amar Takhar]

On 2020-02-28 09:01 +1100, Chris Johns wrote:


> The issue of RTEMS version mismatch of blobs is a real issue waiting to hit 
> our
> users and simply linking the blobs into the executable would solve this.

 
> This also looks like a blocker for CI testing.

I agree with everything you said but I'd like to add a bit to this:

The only two ways this can be dealt with is to have an order of magnitude more 
boards for testing running different versions.  The second way is to boot to 
RTEMS or something else and write new files back to the card.  The 2nd will 
result in heavy SD card wear and is complicated to get working correctly over 
time.

I've had to do this before but not with FDT.  The issue is things change 
over time and this 'write back' becomes a moving target.  This results in 
multiple test environments based on specific sets of source it's a lot of 
overhead.

It's easy to say it looks good now but that's rarely true in 5, 10, 15 years 
down the road when you still have to support old branches and sometimes 
multiple 
versions within those branches.


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

Re: Device Tree Blob for Beaglebone Black?

[Chris Johns]

On 28/2/20 9:14 am, Gedare Bloom wrote:
> On Thu, Feb 27, 2020 at 3:01 PM Chris Johns  wrote:
>>
>> On 28/2/20 7:23 am, Alan Cudmore wrote:
>>> I noticed that the Zephyr RTOS (https://www.zephyrproject.org) uses a
>>> device tree based initialization for all of its BSPs.
>>> For example, here is the top level device tree source for the Adafruit
>>> Trinket M0, which is a very small Atmel Cortex M0 based board:
>>> https://github.com/zephyrproject-rtos/zephyr/blob/master/boards/arm/adafruit_trinket_m0/adafruit_trinket_m0.dts
>>>
>>> The rest of the device tree source for common processors and devices are 
>>> here:
>>> https://github.com/zephyrproject-rtos/zephyr/tree/master/dts
>>>
>>> To me, it looks like they have to develop (or port) and maintain
>>> device trees for each board and device that is supported.
>>>
>>> Does that look like a model that RTEMS could use? I'm not sure I
>>> understand everything that deploying such a model implies, or if it
>>> just makes more sense to use the existing FreeBSD or linux device
>>> trees.
>>
>> This is where I was heading in my thinking but I am not sure. I am settling 
>> on
>> having a dts tree in rtems.git and we may just have to manually manage the
>> files. I am not sure there are enough files to warrant a system like libbsd 
>> and
>> FreeBSD at this point in time. That may change with the new build system and
>> python being available however until then manual is fine. Let me explain ...
>>
>> I have been looking beyond the internal development aspects and to how we use
>> FDT blobs and I am wondering if the approach we have with the shared FDT BSP
>> support is the right fit for RTEMS and a statically linked executable.
>>
>> I believe currently we need a suitable bootloader, ie u-boot, to load a blob.
>> This is the Linux way of doing things and this may be the right approach for
>> Linux but I am not so sure it is for us. It means you need u-boot and a 
>> suitable
>> file system plus you have a lot more items to configuration manage in 
>> production
>> systems and a lot more complexity for self upgrading.
>>
>> Why do we have a bootloader load the FDT files when we statically link
>> everything else?
>>
>> Why not link them into the executable and register them? It s easy to do.
>>
>> The flow on from doing this has some real advantages. FDT files that are 
>> linked
>> into an executable can then live in the rtems.git repo. If you move branches
>> when testing or in production you do not need to manage and match suitable 
>> FDT
>> blobs.
>>
>> I am not advocating this is the only solution. I can see for some BSPs this 
>> will
>> not work and u-boot loading is the only or best solution. I however believe 
>> for
>> DTS that is open and available we should avoid the whole mess of needing to
>> build and manage them on boot media separately to the executable.
>>
>> The issue of RTEMS version mismatch of blobs is a real issue waiting to hit 
>> our
>> users and simply linking the blobs into the executable would solve this.
>>
>> I am confronted by this now. I have a BBB with FDT blobs for libbsd master 
>> and
>> now I need to run libbsd 5-freebsd-12 to test a release. I have to open my 
>> test
>> set up open, pop the SD card and then update it. This seems unnecessary and
>> avoidable to me.
>>
>> This also looks like a blocker for CI testing.
>>
>> Chris
>>
> Hi Chris,
> 
> I'm 100% with you. I will also go a step further and advocate that
> source-based DTS -> dtc -> FDT in static images seems beneficial to
> users. I don't know if we could get any input from users to justify
> that, but I can see advantages for pre-qual and license compliance
> that go beyond the technical advantages that you discuss above.

Thanks and yes what I raised was a small part of the problem space.

> Initial steps in this direction would make a good GSoC for the right
> (strong) student.

This is a good idea. I am not sure how much work is needed or how to define the
work. I think the RTEMS side of things should not be hard but I am not sure
about the interface to libbsd and what is required here. I would help mentor
this project if is suitable for GSoC.

If this goes ahead we can start to populate a dts tree in RTEMS and that would
mean a release could be made.

One issue this raises is the libbds master vs 5-freebsd-12 branch. I am not sure
what happens here and which dts is placed in the rtems.git repo. Maybe placing
5-freebsd-12 dts in rtems.git is done up to the release of RTEMS 5 then we
update rtems.git master to match libbsd's master?

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

Re: Device Tree Blob for Beaglebone Black?

[Gedare Bloom]

On Thu, Feb 27, 2020 at 3:01 PM Chris Johns  wrote:
>
> On 28/2/20 7:23 am, Alan Cudmore wrote:
> > I noticed that the Zephyr RTOS (https://www.zephyrproject.org) uses a
> > device tree based initialization for all of its BSPs.
> > For example, here is the top level device tree source for the Adafruit
> > Trinket M0, which is a very small Atmel Cortex M0 based board:
> > https://github.com/zephyrproject-rtos/zephyr/blob/master/boards/arm/adafruit_trinket_m0/adafruit_trinket_m0.dts
> >
> > The rest of the device tree source for common processors and devices are 
> > here:
> > https://github.com/zephyrproject-rtos/zephyr/tree/master/dts
> >
> > To me, it looks like they have to develop (or port) and maintain
> > device trees for each board and device that is supported.
> >
> > Does that look like a model that RTEMS could use? I'm not sure I
> > understand everything that deploying such a model implies, or if it
> > just makes more sense to use the existing FreeBSD or linux device
> > trees.
>
> This is where I was heading in my thinking but I am not sure. I am settling on
> having a dts tree in rtems.git and we may just have to manually manage the
> files. I am not sure there are enough files to warrant a system like libbsd 
> and
> FreeBSD at this point in time. That may change with the new build system and
> python being available however until then manual is fine. Let me explain ...
>
> I have been looking beyond the internal development aspects and to how we use
> FDT blobs and I am wondering if the approach we have with the shared FDT BSP
> support is the right fit for RTEMS and a statically linked executable.
>
> I believe currently we need a suitable bootloader, ie u-boot, to load a blob.
> This is the Linux way of doing things and this may be the right approach for
> Linux but I am not so sure it is for us. It means you need u-boot and a 
> suitable
> file system plus you have a lot more items to configuration manage in 
> production
> systems and a lot more complexity for self upgrading.
>
> Why do we have a bootloader load the FDT files when we statically link
> everything else?
>
> Why not link them into the executable and register them? It s easy to do.
>
> The flow on from doing this has some real advantages. FDT files that are 
> linked
> into an executable can then live in the rtems.git repo. If you move branches
> when testing or in production you do not need to manage and match suitable FDT
> blobs.
>
> I am not advocating this is the only solution. I can see for some BSPs this 
> will
> not work and u-boot loading is the only or best solution. I however believe 
> for
> DTS that is open and available we should avoid the whole mess of needing to
> build and manage them on boot media separately to the executable.
>
> The issue of RTEMS version mismatch of blobs is a real issue waiting to hit 
> our
> users and simply linking the blobs into the executable would solve this.
>
> I am confronted by this now. I have a BBB with FDT blobs for libbsd master and
> now I need to run libbsd 5-freebsd-12 to test a release. I have to open my 
> test
> set up open, pop the SD card and then update it. This seems unnecessary and
> avoidable to me.
>
> This also looks like a blocker for CI testing.
>
> Chris
>
Hi Chris,

I'm 100% with you. I will also go a step further and advocate that
source-based DTS -> dtc -> FDT in static images seems beneficial to
users. I don't know if we could get any input from users to justify
that, but I can see advantages for pre-qual and license compliance
that go beyond the technical advantages that you discuss above.

Initial steps in this direction would make a good GSoC for the right
(strong) student.

Gedare

> >
> > Just a thought.. I'm still catching up!
> > Thanks,
> > Alan
> >
> > On Thu, Feb 27, 2020 at 2:44 PM Amar Takhar  wrote:
> >>
> >> On 2020-02-27 20:06 +0100, Christian Mauderer wrote:
> >>
>  The only good way to handle this is to have it all in 1 giant repository 
>  we work
>  with.  Every other solution is a pain no matter how well thought out it 
>  is.  I
>  personally lean more on the service side of things that it should be 
>  *our*
>  problem to maintain this and for users it should just work.>
>  The easiest way to handle this is to have the minimum version required 
>  in the
>  commit message.  Eg, when pushing to libbsd have:
> 
>    Minimum RTEMS: 
> 
>  After that it's up to the user to ensure to keep up-to-date.  The first 
>  thing
>  most developers do is check the log.
> >>>
> >>> Sounds like a nice suggestion. But it needs quite a lot of discipline
> >>> for the developers. So most likely a lot of errors will happen. Beneath
> >>> that it's not far from what we do now: Suggest to use commits from the
> >>> same date.
> >>
> >> There are two ways to look at it -- requiring discipline or simply doing
> >> something we should already be doing.  Because right now there is no way 
> 

Re: Device Tree Blob for Beaglebone Black?

[Chris Johns]

On 28/2/20 7:23 am, Alan Cudmore wrote:
> I noticed that the Zephyr RTOS (https://www.zephyrproject.org) uses a
> device tree based initialization for all of its BSPs.
> For example, here is the top level device tree source for the Adafruit
> Trinket M0, which is a very small Atmel Cortex M0 based board:
> https://github.com/zephyrproject-rtos/zephyr/blob/master/boards/arm/adafruit_trinket_m0/adafruit_trinket_m0.dts
> 
> The rest of the device tree source for common processors and devices are here:
> https://github.com/zephyrproject-rtos/zephyr/tree/master/dts
> 
> To me, it looks like they have to develop (or port) and maintain
> device trees for each board and device that is supported.
> 
> Does that look like a model that RTEMS could use? I'm not sure I
> understand everything that deploying such a model implies, or if it
> just makes more sense to use the existing FreeBSD or linux device
> trees.

This is where I was heading in my thinking but I am not sure. I am settling on
having a dts tree in rtems.git and we may just have to manually manage the
files. I am not sure there are enough files to warrant a system like libbsd and
FreeBSD at this point in time. That may change with the new build system and
python being available however until then manual is fine. Let me explain ...

I have been looking beyond the internal development aspects and to how we use
FDT blobs and I am wondering if the approach we have with the shared FDT BSP
support is the right fit for RTEMS and a statically linked executable.

I believe currently we need a suitable bootloader, ie u-boot, to load a blob.
This is the Linux way of doing things and this may be the right approach for
Linux but I am not so sure it is for us. It means you need u-boot and a suitable
file system plus you have a lot more items to configuration manage in production
systems and a lot more complexity for self upgrading.

Why do we have a bootloader load the FDT files when we statically link
everything else?

Why not link them into the executable and register them? It s easy to do.

The flow on from doing this has some real advantages. FDT files that are linked
into an executable can then live in the rtems.git repo. If you move branches
when testing or in production you do not need to manage and match suitable FDT
blobs.

I am not advocating this is the only solution. I can see for some BSPs this will
not work and u-boot loading is the only or best solution. I however believe for
DTS that is open and available we should avoid the whole mess of needing to
build and manage them on boot media separately to the executable.

The issue of RTEMS version mismatch of blobs is a real issue waiting to hit our
users and simply linking the blobs into the executable would solve this.

I am confronted by this now. I have a BBB with FDT blobs for libbsd master and
now I need to run libbsd 5-freebsd-12 to test a release. I have to open my test
set up open, pop the SD card and then update it. This seems unnecessary and
avoidable to me.

This also looks like a blocker for CI testing.

Chris

> 
> Just a thought.. I'm still catching up!
> Thanks,
> Alan
> 
> On Thu, Feb 27, 2020 at 2:44 PM Amar Takhar  wrote:
>>
>> On 2020-02-27 20:06 +0100, Christian Mauderer wrote:
>>
 The only good way to handle this is to have it all in 1 giant repository 
 we work
 with.  Every other solution is a pain no matter how well thought out it 
 is.  I
 personally lean more on the service side of things that it should be *our*
 problem to maintain this and for users it should just work.>
 The easiest way to handle this is to have the minimum version required in 
 the
 commit message.  Eg, when pushing to libbsd have:

   Minimum RTEMS: 

 After that it's up to the user to ensure to keep up-to-date.  The first 
 thing
 most developers do is check the log.
>>>
>>> Sounds like a nice suggestion. But it needs quite a lot of discipline
>>> for the developers. So most likely a lot of errors will happen. Beneath
>>> that it's not far from what we do now: Suggest to use commits from the
>>> same date.
>>
>> There are two ways to look at it -- requiring discipline or simply doing
>> something we should already be doing.  Because right now there is no way to 
>> tell
>> other than updating to the latest and if you are trying to bisect an issue 
>> this
>> because huge because you could feasibly jump into a comment that skips a
>> version.  How would a user know which version of the library *or* RTEMS to 
>> use?
>>
>>
>>> But maybe we should move that discussion. It's not FDT related anymore
>>> so no one will find it in this toppic. And I think for Chris the
>>> pressing matter is FDT just now because it blocks the release.
>>
>> Yes that's true.
>>
>>> The BSP groups that use bsps/shared/start/bsp-fdt.c are:
>>>
>>> - riscv/riscv
>>> - arm/imx
>>> - arm/beagle
>>> - arm/raspberrypi
>>> - arm/altera-cyclone-v
>>> - powerpc/qoriq
>>>
>>> For 

Re: Device Tree Blob for Beaglebone Black?

[Alan Cudmore]

I noticed that the Zephyr RTOS (https://www.zephyrproject.org) uses a
device tree based initialization for all of its BSPs.
For example, here is the top level device tree source for the Adafruit
Trinket M0, which is a very small Atmel Cortex M0 based board:
https://github.com/zephyrproject-rtos/zephyr/blob/master/boards/arm/adafruit_trinket_m0/adafruit_trinket_m0.dts

The rest of the device tree source for common processors and devices are here:
https://github.com/zephyrproject-rtos/zephyr/tree/master/dts

To me, it looks like they have to develop (or port) and maintain
device trees for each board and device that is supported.

Does that look like a model that RTEMS could use? I'm not sure I
understand everything that deploying such a model implies, or if it
just makes more sense to use the existing FreeBSD or linux device
trees.

Just a thought.. I'm still catching up!
Thanks,
Alan

On Thu, Feb 27, 2020 at 2:44 PM Amar Takhar  wrote:
>
> On 2020-02-27 20:06 +0100, Christian Mauderer wrote:
>
> > > The only good way to handle this is to have it all in 1 giant repository 
> > > we work
> > > with.  Every other solution is a pain no matter how well thought out it 
> > > is.  I
> > > personally lean more on the service side of things that it should be *our*
> > > problem to maintain this and for users it should just work.>
> > > The easiest way to handle this is to have the minimum version required in 
> > > the
> > > commit message.  Eg, when pushing to libbsd have:
> > >
> > >   Minimum RTEMS: 
> > >
> > > After that it's up to the user to ensure to keep up-to-date.  The first 
> > > thing
> > > most developers do is check the log.
> >
> > Sounds like a nice suggestion. But it needs quite a lot of discipline
> > for the developers. So most likely a lot of errors will happen. Beneath
> > that it's not far from what we do now: Suggest to use commits from the
> > same date.
>
> There are two ways to look at it -- requiring discipline or simply doing
> something we should already be doing.  Because right now there is no way to 
> tell
> other than updating to the latest and if you are trying to bisect an issue 
> this
> because huge because you could feasibly jump into a comment that skips a
> version.  How would a user know which version of the library *or* RTEMS to 
> use?
>
>
> > But maybe we should move that discussion. It's not FDT related anymore
> > so no one will find it in this toppic. And I think for Chris the
> > pressing matter is FDT just now because it blocks the release.
>
> Yes that's true.
>
> > The BSP groups that use bsps/shared/start/bsp-fdt.c are:
> >
> > - riscv/riscv
> > - arm/imx
> > - arm/beagle
> > - arm/raspberrypi
> > - arm/altera-cyclone-v
> > - powerpc/qoriq
> >
> > For beagle and raspberry it should be definitely the FreeBSD FDT.
> >
> > For imx: I'm currently working on imx6 support in the imx BSP and that
> > one will use a FreeBSD derived one too. Not sure about the original imx7
> > support in that BSP.
> >
> > For the other BSPs I don't have any idea which FDT has been used during
> > development.
>
>
> Okay that list is already compelling enough to have the split model of having
> source based files in-tree and binary outside.  I think it makes sense to have
> it 'just work' for opensource boards like the beagle and rpi even if that's 
> the
> only two that require it.
>
>
> Amar.
> ___
> 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: Device Tree Blob for Beaglebone Black?

[Amar Takhar]

On 2020-02-27 20:06 +0100, Christian Mauderer wrote:

> > The only good way to handle this is to have it all in 1 giant repository we 
> > work 
> > with.  Every other solution is a pain no matter how well thought out it is. 
> >  I 
> > personally lean more on the service side of things that it should be *our* 
> > problem to maintain this and for users it should just work.>
> > The easiest way to handle this is to have the minimum version required in 
> > the 
> > commit message.  Eg, when pushing to libbsd have:
> > 
> >   Minimum RTEMS: 
> > 
> > After that it's up to the user to ensure to keep up-to-date.  The first 
> > thing 
> > most developers do is check the log.
> 
> Sounds like a nice suggestion. But it needs quite a lot of discipline
> for the developers. So most likely a lot of errors will happen. Beneath
> that it's not far from what we do now: Suggest to use commits from the
> same date.

There are two ways to look at it -- requiring discipline or simply doing 
something we should already be doing.  Because right now there is no way to 
tell 
other than updating to the latest and if you are trying to bisect an issue this 
because huge because you could feasibly jump into a comment that skips a 
version.  How would a user know which version of the library *or* RTEMS to use?


> But maybe we should move that discussion. It's not FDT related anymore
> so no one will find it in this toppic. And I think for Chris the
> pressing matter is FDT just now because it blocks the release.

Yes that's true.

> The BSP groups that use bsps/shared/start/bsp-fdt.c are:
> 
> - riscv/riscv
> - arm/imx
> - arm/beagle
> - arm/raspberrypi
> - arm/altera-cyclone-v
> - powerpc/qoriq
> 
> For beagle and raspberry it should be definitely the FreeBSD FDT.
> 
> For imx: I'm currently working on imx6 support in the imx BSP and that
> one will use a FreeBSD derived one too. Not sure about the original imx7
> support in that BSP.
> 
> For the other BSPs I don't have any idea which FDT has been used during
> development.


Okay that list is already compelling enough to have the split model of having 
source based files in-tree and binary outside.  I think it makes sense to have 
it 'just work' for opensource boards like the beagle and rpi even if that's the 
only two that require it.


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

Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

On 27/02/2020 18:14, Amar Takhar wrote:
> On 2020-02-27 08:45 +0100, Christian Mauderer wrote:
>>
>> It's just another problem that I noted sometimes on the mailing list
>> with RTEMS and libbsd: Sometimes libbsd doesn't compile with some odd
>> error messages like unresolved symbols. Most of the time the problem is
>> that libbsd has been updated by the user but RTEMS hasn't. Having
>> defined versions in a master repository could help the average user to
>> see which version should be used together. On the other hand someone
>> would have to keep it up to date and I'm not sure whether all
>> maintainers would be happy about another necessary maintainance task.
>> Therefore it's not yet a well thought through idea.
> 
> The only good way to handle this is to have it all in 1 giant repository we 
> work 
> with.  Every other solution is a pain no matter how well thought out it is.  
> I 
> personally lean more on the service side of things that it should be *our* 
> problem to maintain this and for users it should just work.>
> The easiest way to handle this is to have the minimum version required in the 
> commit message.  Eg, when pushing to libbsd have:
> 
>   Minimum RTEMS: 
> 
> After that it's up to the user to ensure to keep up-to-date.  The first thing 
> most developers do is check the log.

Sounds like a nice suggestion. But it needs quite a lot of discipline
for the developers. So most likely a lot of errors will happen. Beneath
that it's not far from what we do now: Suggest to use commits from the
same date.

But maybe we should move that discussion. It's not FDT related anymore
so no one will find it in this toppic. And I think for Chris the
pressing matter is FDT just now because it blocks the release.



> 
> Regardless of what we choose none of it will work if the user is not updating 
> their repository or checking online for changes.  Having it in the commit 
> message also helps for build automation.  I've used git tags for this in the 
> past but hardly anyone uses or checks those which is too bad.
> >
>> If you are a new user and see "for this BSP use the FDT from X" but you
>> want to use some other BSP and someone tells you "for that BSP the FDT
>> isn't in X but at Y" it maybe isn't really that clear. Therefore - if we
>> introduce some handling - I would be in favor of only one location and
>> not a mix of two or three. Otherwise the situation is only slightly
>> better than now.
> 
> Having a section in the documentation to manage this is fine I think.  It's 
> either going to say:
> 
>   1. The FDT source is in rtems-fdt.git
>   2. The FDT source is already in RTEMS you don't need to do anything.
>   3. You need to purchase a board and place the files 
>   4. Covers all: If you want to roll your own place the files  -- same 
>  place as #3 maybe.
> 
> An easier way to make a decision would be to see what we're looking at right 
> now.  How many would be in-tree and how many external?
> 

The BSP groups that use bsps/shared/start/bsp-fdt.c are:

- riscv/riscv
- arm/imx
- arm/beagle
- arm/raspberrypi
- arm/altera-cyclone-v
- powerpc/qoriq

For beagle and raspberry it should be definitely the FreeBSD FDT.

For imx: I'm currently working on imx6 support in the imx BSP and that
one will use a FreeBSD derived one too. Not sure about the original imx7
support in that BSP.

For the other BSPs I don't have any idea which FDT has been used during
development.

Best regards

Christian

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

Re: Device Tree Blob for Beaglebone Black?

[Amar Takhar]

On 2020-02-27 08:45 +0100, Christian Mauderer wrote:
> 
> It's just another problem that I noted sometimes on the mailing list
> with RTEMS and libbsd: Sometimes libbsd doesn't compile with some odd
> error messages like unresolved symbols. Most of the time the problem is
> that libbsd has been updated by the user but RTEMS hasn't. Having
> defined versions in a master repository could help the average user to
> see which version should be used together. On the other hand someone
> would have to keep it up to date and I'm not sure whether all
> maintainers would be happy about another necessary maintainance task.
> Therefore it's not yet a well thought through idea.

The only good way to handle this is to have it all in 1 giant repository we 
work 
with.  Every other solution is a pain no matter how well thought out it is.  I 
personally lean more on the service side of things that it should be *our* 
problem to maintain this and for users it should just work.

The easiest way to handle this is to have the minimum version required in the 
commit message.  Eg, when pushing to libbsd have:

  Minimum RTEMS: 

After that it's up to the user to ensure to keep up-to-date.  The first thing 
most developers do is check the log.

Regardless of what we choose none of it will work if the user is not updating 
their repository or checking online for changes.  Having it in the commit 
message also helps for build automation.  I've used git tags for this in the 
past but hardly anyone uses or checks those which is too bad.


> If you are a new user and see "for this BSP use the FDT from X" but you
> want to use some other BSP and someone tells you "for that BSP the FDT
> isn't in X but at Y" it maybe isn't really that clear. Therefore - if we
> introduce some handling - I would be in favor of only one location and
> not a mix of two or three. Otherwise the situation is only slightly
> better than now.

Having a section in the documentation to manage this is fine I think.  It's 
either going to say:

  1. The FDT source is in rtems-fdt.git
  2. The FDT source is already in RTEMS you don't need to do anything.
  3. You need to purchase a board and place the files 
  4. Covers all: If you want to roll your own place the files  -- same 
 place as #3 maybe.

An easier way to make a decision would be to see what we're looking at right 
now.  How many would be in-tree and how many external?


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

Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

On 26/02/2020 22:12, Amar Takhar wrote:
> On 2020-02-26 18:46 +0100, Christian Mauderer wrote:
>> Hello Amar,
>>
>> somehow I missed your response this morning. My filter for the mailing
>> list normally keeps stuff with my name in the inbox but your answer
>> didn't contain it and therefore it was hidden in the mailing list folder.
> 
> No problem! :)
> 
> 
>> Full acknowledge. I'm not a fan of another repository like I already
>> said toward Chris. On the other hand: We already have that problem and
>> have to deal with it sometimes anyway. I added a note in the response
>> toward Chris that we maybe sometimes should think about a master
>> repository with sub-repos to make the version dependencies more clear.
>> In other words: One repository to rule them all ;-)
> 
> We can for sure create a sub repository to handle this.  That can be annoying 
> however if the sub repositories don't update often because git pull can take 
> a 
> while.

It's just another problem that I noted sometimes on the mailing list
with RTEMS and libbsd: Sometimes libbsd doesn't compile with some odd
error messages like unresolved symbols. Most of the time the problem is
that libbsd has been updated by the user but RTEMS hasn't. Having
defined versions in a master repository could help the average user to
see which version should be used together. On the other hand someone
would have to keep it up to date and I'm not sure whether all
maintainers would be happy about another necessary maintainance task.
Therefore it's not yet a well thought through idea.

> 
> The other option here is to just document for the user how to do a 'git 
> submodule add' and do it themselves within the RTEMS tree or a separate 
> repository it would depend on just how much demand there would be for this.  
> It's not a huge deal though to detect if the FDT repository is in-tree 
> otherwise 
> force a --with-fdt-repo.
> 
> 
> 
>>> We don't really have a choice here however I would 
>>> suggest we do a mix of the two.
>>>
>>
>> I'm not sure whether that is a very transparent approach.
> 
> Transparent or complicated?  :)  It will still all be documented and out in 
> the 
> open.
> 

If you are a new user and see "for this BSP use the FDT from X" but you
want to use some other BSP and someone tells you "for that BSP the FDT
isn't in X but at Y" it maybe isn't really that clear. Therefore - if we
introduce some handling - I would be in favor of only one location and
not a mix of two or three. Otherwise the situation is only slightly
better than now.

> 
>>>   1. Any source/permissive files be kept within the RTEMS repository.
>>>   2. Binary blobs get ejected to a separate repository lets say 'rtems-fdt'.
>>>   3. Source files with strict licensing gets the boot, too -- though we can 
>>>  discuss how much we care about this.
>>
>> I think we will get big problems finding "permissive" licenses. Most
>> device trees are Linux based and therefore GPL. Even the ones in FreeBSD.
> 
> Okay well if they're all GPL then instead of permissive just say source-based 
> because that is still far better than binary blobs.  It will still be left up 
> to 
> the user if they want to include it the license won't change whether it's in 
> tree 
> our outside.
> 
>>>
>>> How it would work is simple.  During configure if the required FDT files 
>>> exist 
>>> that's great we look for the two binaries we need and build them all as 
>>> part of 
>>> the normal building process.
>>
>> That would add dtc to our mandatory set of tools for RTEMS. Otherwise
>> nothing against it.
> 
> It would for BSPs that have it and if users want it.  Otherwise if there is 
> no 
> FDT then we wouldn't require those tools.
> 
> 
>> There is even a case 5: We have a FDT (for example for BBB) but the user
>> wants to use an adapted one because he has connected extra peripherals
>> or has a board that is only based on the evaluation board. Our build
>> system should be open enough to handle such a case.
>>
>> The FreeBSD FDT scripts work fine for that. You give them your file and
>> the path to the FreeBSD fdt sources and they do the rest.
> 
> Yes that adds yet another option letting users supply their own files.  I 
> should 
> have added that one thank you.
> 
> 
>> Agreed: Open BSPs are first class citizens.
> 
> Awesome I'm glad we agree on that! :)
> 
> 
> Amar.
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Device Tree Blob for Beaglebone Black?

[Amar Takhar]

On 2020-02-26 18:46 +0100, Christian Mauderer wrote:
> Hello Amar,
> 
> somehow I missed your response this morning. My filter for the mailing
> list normally keeps stuff with my name in the inbox but your answer
> didn't contain it and therefore it was hidden in the mailing list folder.

No problem! :)


> Full acknowledge. I'm not a fan of another repository like I already
> said toward Chris. On the other hand: We already have that problem and
> have to deal with it sometimes anyway. I added a note in the response
> toward Chris that we maybe sometimes should think about a master
> repository with sub-repos to make the version dependencies more clear.
> In other words: One repository to rule them all ;-)

We can for sure create a sub repository to handle this.  That can be annoying 
however if the sub repositories don't update often because git pull can take a 
while.

The other option here is to just document for the user how to do a 'git 
submodule add' and do it themselves within the RTEMS tree or a separate 
repository it would depend on just how much demand there would be for this.  
It's not a huge deal though to detect if the FDT repository is in-tree 
otherwise 
force a --with-fdt-repo.



> > We don't really have a choice here however I would 
> > suggest we do a mix of the two.
> > 
> 
> I'm not sure whether that is a very transparent approach.

Transparent or complicated?  :)  It will still all be documented and out in the 
open.


> >   1. Any source/permissive files be kept within the RTEMS repository.
> >   2. Binary blobs get ejected to a separate repository lets say 'rtems-fdt'.
> >   3. Source files with strict licensing gets the boot, too -- though we can 
> >  discuss how much we care about this.
> 
> I think we will get big problems finding "permissive" licenses. Most
> device trees are Linux based and therefore GPL. Even the ones in FreeBSD.

Okay well if they're all GPL then instead of permissive just say source-based 
because that is still far better than binary blobs.  It will still be left up 
to 
the user if they want to include it the license won't change whether it's in 
tree 
our outside.

> > 
> > How it would work is simple.  During configure if the required FDT files 
> > exist 
> > that's great we look for the two binaries we need and build them all as 
> > part of 
> > the normal building process.
> 
> That would add dtc to our mandatory set of tools for RTEMS. Otherwise
> nothing against it.

It would for BSPs that have it and if users want it.  Otherwise if there is no 
FDT then we wouldn't require those tools.


> There is even a case 5: We have a FDT (for example for BBB) but the user
> wants to use an adapted one because he has connected extra peripherals
> or has a board that is only based on the evaluation board. Our build
> system should be open enough to handle such a case.
> 
> The FreeBSD FDT scripts work fine for that. You give them your file and
> the path to the FreeBSD fdt sources and they do the rest.

Yes that adds yet another option letting users supply their own files.  I 
should 
have added that one thank you.


> Agreed: Open BSPs are first class citizens.

Awesome I'm glad we agree on that! :)


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

Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

Hello Amar,

somehow I missed your response this morning. My filter for the mailing
list normally keeps stuff with my name in the inbox but your answer
didn't contain it and therefore it was hidden in the mailing list folder.

On 26/02/2020 06:00, Amar Takhar wrote:
> 
> I've had to deal with this issue quite a lot in the past it can be really 
> annoying having to maintain separate repositories where we have to 'pin' a 
> version to the main repo. 

Full acknowledge. I'm not a fan of another repository like I already
said toward Chris. On the other hand: We already have that problem and
have to deal with it sometimes anyway. I added a note in the response
toward Chris that we maybe sometimes should think about a master
repository with sub-repos to make the version dependencies more clear.
In other words: One repository to rule them all ;-)

> We don't really have a choice here however I would 
> suggest we do a mix of the two.
> 

I'm not sure whether that is a very transparent approach.

> 
>   1. Any source/permissive files be kept within the RTEMS repository.
>   2. Binary blobs get ejected to a separate repository lets say 'rtems-fdt'.
>   3. Source files with strict licensing gets the boot, too -- though we can 
>  discuss how much we care about this.

I think we will get big problems finding "permissive" licenses. Most
device trees are Linux based and therefore GPL. Even the ones in FreeBSD.

> 
> How it would work is simple.  During configure if the required FDT files 
> exist 
> that's great we look for the two binaries we need and build them all as part 
> of 
> the normal building process.

That would add dtc to our mandatory set of tools for RTEMS. Otherwise
nothing against it.

> 
> If they are not found print a notice to the user to get the 'rtems-fdt' 
> repository and point to it with a --rtems-fdt-path=  This is where it gets 
> annoying because there are several steps to get the right file.  Generally we 
> have to:
> 
>   1. Read a file stored within RTEMS that says what version of the FDT 
>  repository to checkout.
>   2. As part of configure this file needs to be loaded and the 'rtems-fdt'
>  repository checked to see if it's at the right revision.
>   3. If it as not at the right revision then the user will have to fix this 
>  manually and re-run configure.
>   4. Some BSPs may not even have the FDT files until you purchase a board.  
> Do 
>  we have any of these cases?  Now we have a situation where we have no 
>  revision *or* files and no way to test this code or ensure it even works.

There is even a case 5: We have a FDT (for example for BBB) but the user
wants to use an adapted one because he has connected extra peripherals
or has a board that is only based on the evaluation board. Our build
system should be open enough to handle such a case.

The FreeBSD FDT scripts work fine for that. You give them your file and
the path to the FreeBSD fdt sources and they do the rest.

> 
> Regardless for case #4 it's going to be a user issue to get the FDT files and 
> our issue to suck these in.
> 
> It makes sense to do it this way for RTEMS as I don't see a reason to 
> "punish" 
> the BSPs where everything is free and open it would be great to have these 
> 'just 
> work' and it is less maintenance for us longterm.

Agreed: Open BSPs are first class citizens.

Best regards

Christian

> 
> 
> Amar.
> ___
> 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: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

On 26/02/2020 04:50, Chris Johns wrote:
> On 25/2/20 5:30 pm, Christian Mauderer wrote:
>> On 24/02/2020 23:26, Chris Johns wrote:
 On 24 Feb 2020, at 7:39 pm, Christian Mauderer 
  wrote:

 On 24/02/2020 07:01, Chris Johns wrote:
>
>
>>> On 24 Feb 2020, at 5:32 am, Christian Mauderer  
>>> wrote:
>>
>> On 23/02/2020 17:07, Alan Cudmore wrote:
>>> I have been trying to bring up RTEMS with rtems-libbsd on the
>>> beaglebone black (latest master).
>>>
>>> I can run the regular RTEMS samples on the board, and a couple of the
>>> rtems-libbsd testsuite examples run as well.
>>>
>>> The samples such as ping01 and usb01 get a fatal exception in the
>>> function fdt_ro_probe_ , leading me to believe that maybe I am not
>>> using the correct device tree blob.
>>>
>>> I'm using the instructions here:
>>> https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
>>>
>>> And I have am loading am335x-boneblack.dtb that I copied from a linux
>>> u-boot build. The instructions talk about getting the one from the
>>> FreeBSD repository, but there are many other files included in that
>>> dts source.
>>>
>>> What dtb is normally used for the Beaglebone black RTEMS libbsd testing?
>>>
>>> Is the dtb needed for the non-libbsd BSP?
>>>
>>> Also, is the ethernet supported on the RTEMS beagle BSP, or do I need
>>> libbsd to get ethernet?
>>>
>>> Thanks,
>>> Alan
>>
>> Hello Alan,
>>
>> I recommend to use the FreeBSD device trees. libbsd is FreeBSD based and
>> therefore works best with them. Normally I would suggest to use the
>> version matching the FreeBSD commit used in libbsd. But unfortunately in
>> the last commit that doesn't seem to work. Vijay had some problems with
>> it and noted that the version from FreeBSD commit
>> 19a6ceb89dbacf74697d493e48c388767126d418 works fine.
>
> Is this with 5 branch in Libbsd?
>
> I am a little confused about the branch to package in a release and also 
> which FDT files we need for which branch. If different I feel a release 
> will makes things more complicated. This flies into the BSP  vertical 
> stack building in the RSB. 
>
> I am working on releasing and I hope this does not block things. 
>
> Chris

 Hello Chris,

 the non-working device tree is for the master branch from a few weeks
 back. I didn't tested it with the 5-freebsd-12 branch.
>>>
>>> Which FDT files are needed for the 5-freebsd-12 branch? I could assume the
>>> 12-release branch in the FreeBSD repo however this is a guess, unfriendly 
>>> on our
>>> part and time consuming to sort out. I am not sure how we improve this and 
>>> how
>>> we should manage FDT source but we need to address the issue.
>>
>> Same problem here. The topic already popped up multiple times and I
>> can't really answer it.
> 
> I know but we have too.
> 
>> Like I said multiple time: My approach is to use the fdt that matches
>> the FreeBSD commit used in libbsd. So for the 5-freebsd-12 branch that
>> is the one from FreeBSD commit 0d1c391321b34b3025cf0e72f2231d836ff76da8.
>> But it's not a rule that works for all BSPs. Some BSPs are adapted to
>> use a board manufacturers DTB or some random Linux one.
> 
> This means users need a clone of the FreeBSD repo  and that means a bigger
> disk array and a larger net pipe ;)
> 

I agree that it's not optimal to pull the FreeBSD sources in it's
entirety. An import into libbsd (or some other solution) would be better.

>>
>>>
>>> There are long time RTEMS users including myself struggling with this so it 
>>> is a
>>> clear indication in my mind we have an issue we need to improve.
>>>
> Again: In the normal case I would just suggest to use the FDT sources
 that match the FreeBSD commit we use for libbsd. That worked best for me
 in the past. But in the current referenced commit FreeBSD has updated
 the device tree sources to the ones from a recent Linux version and the
 drivers haven't been adapted yet (on master - I expect that it works
 better on 5-freebsd-12).

 Regarding the release: I don't think you pack the FDT files (yet), do
 you? 
>>>
>>> No I do not but then should I be the one doing this in a release. I would 
>>> have
>>> thought this is a core issue for the BSPs that depend on FDT blobs at 
>>> runtime.
>>>
>>> I am up to libbsd with the release packaging. I can build a beagleboneblack 
>>> as a
>>> vertical stack up to libbsd and then I hit the issue of using master and 
>>> not the
>>> 5-freebsd-12 branch and after that is the rtems_waf submodule naming. I 
>>> would
>>> like to resolve this in the RSB however before I do this I would like to 
>>> resolve
>>> the FDT files so I make a single pass over this.
>>>
 So I don't see why there should be a reason for this topic to block
 the 

Re: Device Tree Blob for Beaglebone Black?

[Amar Takhar]

I've had to deal with this issue quite a lot in the past it can be really 
annoying having to maintain separate repositories where we have to 'pin' a 
version to the main repo.  We don't really have a choice here however I would 
suggest we do a mix of the two.


  1. Any source/permissive files be kept within the RTEMS repository.
  2. Binary blobs get ejected to a separate repository lets say 'rtems-fdt'.
  3. Source files with strict licensing gets the boot, too -- though we can 
 discuss how much we care about this.

How it would work is simple.  During configure if the required FDT files exist 
that's great we look for the two binaries we need and build them all as part of 
the normal building process.

If they are not found print a notice to the user to get the 'rtems-fdt' 
repository and point to it with a --rtems-fdt-path=  This is where it gets 
annoying because there are several steps to get the right file.  Generally we 
have to:

  1. Read a file stored within RTEMS that says what version of the FDT 
 repository to checkout.
  2. As part of configure this file needs to be loaded and the 'rtems-fdt'
 repository checked to see if it's at the right revision.
  3. If it as not at the right revision then the user will have to fix this 
 manually and re-run configure.
  4. Some BSPs may not even have the FDT files until you purchase a board.  Do 
 we have any of these cases?  Now we have a situation where we have no 
 revision *or* files and no way to test this code or ensure it even works.

Regardless for case #4 it's going to be a user issue to get the FDT files and 
our issue to suck these in.

It makes sense to do it this way for RTEMS as I don't see a reason to "punish" 
the BSPs where everything is free and open it would be great to have these 
'just 
work' and it is less maintenance for us longterm.


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

Re: Device Tree Blob for Beaglebone Black?

[Chris Johns]

On 25/2/20 5:30 pm, Christian Mauderer wrote:
> On 24/02/2020 23:26, Chris Johns wrote:
>>> On 24 Feb 2020, at 7:39 pm, Christian Mauderer 
>>>  wrote:
>>>
>>> On 24/02/2020 07:01, Chris Johns wrote:


>> On 24 Feb 2020, at 5:32 am, Christian Mauderer  
>> wrote:
>
> On 23/02/2020 17:07, Alan Cudmore wrote:
>> I have been trying to bring up RTEMS with rtems-libbsd on the
>> beaglebone black (latest master).
>>
>> I can run the regular RTEMS samples on the board, and a couple of the
>> rtems-libbsd testsuite examples run as well.
>>
>> The samples such as ping01 and usb01 get a fatal exception in the
>> function fdt_ro_probe_ , leading me to believe that maybe I am not
>> using the correct device tree blob.
>>
>> I'm using the instructions here:
>> https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
>>
>> And I have am loading am335x-boneblack.dtb that I copied from a linux
>> u-boot build. The instructions talk about getting the one from the
>> FreeBSD repository, but there are many other files included in that
>> dts source.
>>
>> What dtb is normally used for the Beaglebone black RTEMS libbsd testing?
>>
>> Is the dtb needed for the non-libbsd BSP?
>>
>> Also, is the ethernet supported on the RTEMS beagle BSP, or do I need
>> libbsd to get ethernet?
>>
>> Thanks,
>> Alan
>
> Hello Alan,
>
> I recommend to use the FreeBSD device trees. libbsd is FreeBSD based and
> therefore works best with them. Normally I would suggest to use the
> version matching the FreeBSD commit used in libbsd. But unfortunately in
> the last commit that doesn't seem to work. Vijay had some problems with
> it and noted that the version from FreeBSD commit
> 19a6ceb89dbacf74697d493e48c388767126d418 works fine.

 Is this with 5 branch in Libbsd?

 I am a little confused about the branch to package in a release and also 
 which FDT files we need for which branch. If different I feel a release 
 will makes things more complicated. This flies into the BSP  vertical 
 stack building in the RSB. 

 I am working on releasing and I hope this does not block things. 

 Chris
>>>
>>> Hello Chris,
>>>
>>> the non-working device tree is for the master branch from a few weeks
>>> back. I didn't tested it with the 5-freebsd-12 branch.
>>
>> Which FDT files are needed for the 5-freebsd-12 branch? I could assume the
>> 12-release branch in the FreeBSD repo however this is a guess, unfriendly on 
>> our
>> part and time consuming to sort out. I am not sure how we improve this and 
>> how
>> we should manage FDT source but we need to address the issue.
> 
> Same problem here. The topic already popped up multiple times and I
> can't really answer it.

I know but we have too.

> Like I said multiple time: My approach is to use the fdt that matches
> the FreeBSD commit used in libbsd. So for the 5-freebsd-12 branch that
> is the one from FreeBSD commit 0d1c391321b34b3025cf0e72f2231d836ff76da8.
> But it's not a rule that works for all BSPs. Some BSPs are adapted to
> use a board manufacturers DTB or some random Linux one.

This means users need a clone of the FreeBSD repo  and that means a bigger
disk array and a larger net pipe ;)

> 
>>
>> There are long time RTEMS users including myself struggling with this so it 
>> is a
>> clear indication in my mind we have an issue we need to improve.
>>
 Again: In the normal case I would just suggest to use the FDT sources
>>> that match the FreeBSD commit we use for libbsd. That worked best for me
>>> in the past. But in the current referenced commit FreeBSD has updated
>>> the device tree sources to the ones from a recent Linux version and the
>>> drivers haven't been adapted yet (on master - I expect that it works
>>> better on 5-freebsd-12).
>>>
>>> Regarding the release: I don't think you pack the FDT files (yet), do
>>> you? 
>>
>> No I do not but then should I be the one doing this in a release. I would 
>> have
>> thought this is a core issue for the BSPs that depend on FDT blobs at 
>> runtime.
>>
>> I am up to libbsd with the release packaging. I can build a beagleboneblack 
>> as a
>> vertical stack up to libbsd and then I hit the issue of using master and not 
>> the
>> 5-freebsd-12 branch and after that is the rtems_waf submodule naming. I would
>> like to resolve this in the RSB however before I do this I would like to 
>> resolve
>> the FDT files so I make a single pass over this.
>>
>>> So I don't see why there should be a reason for this topic to block
>>> the release.
>>
>> I do. To not handle this is to create a release where the files in the 
>> release
>> package crash a beagleboneblack with libbsd unless you manually get the 
>> correct
>> set of FDT files. This is unhelpful for users in a release context.
>>
>> Consider a release called rtems-libbsd-5.0.5.tar.xz 

Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

On 24/02/2020 23:26, Chris Johns wrote:
>> On 24 Feb 2020, at 7:39 pm, Christian Mauderer 
>>  wrote:
>>
>> On 24/02/2020 07:01, Chris Johns wrote:
>>>
>>>
> On 24 Feb 2020, at 5:32 am, Christian Mauderer  wrote:

 On 23/02/2020 17:07, Alan Cudmore wrote:
> I have been trying to bring up RTEMS with rtems-libbsd on the
> beaglebone black (latest master).
>
> I can run the regular RTEMS samples on the board, and a couple of the
> rtems-libbsd testsuite examples run as well.
>
> The samples such as ping01 and usb01 get a fatal exception in the
> function fdt_ro_probe_ , leading me to believe that maybe I am not
> using the correct device tree blob.
>
> I'm using the instructions here:
> https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
>
> And I have am loading am335x-boneblack.dtb that I copied from a linux
> u-boot build. The instructions talk about getting the one from the
> FreeBSD repository, but there are many other files included in that
> dts source.
>
> What dtb is normally used for the Beaglebone black RTEMS libbsd testing?
>
> Is the dtb needed for the non-libbsd BSP?
>
> Also, is the ethernet supported on the RTEMS beagle BSP, or do I need
> libbsd to get ethernet?
>
> Thanks,
> Alan

 Hello Alan,

 I recommend to use the FreeBSD device trees. libbsd is FreeBSD based and
 therefore works best with them. Normally I would suggest to use the
 version matching the FreeBSD commit used in libbsd. But unfortunately in
 the last commit that doesn't seem to work. Vijay had some problems with
 it and noted that the version from FreeBSD commit
 19a6ceb89dbacf74697d493e48c388767126d418 works fine.
>>>
>>> Is this with 5 branch in Libbsd?
>>>
>>> I am a little confused about the branch to package in a release and also 
>>> which FDT files we need for which branch. If different I feel a release 
>>> will makes things more complicated. This flies into the BSP  vertical stack 
>>> building in the RSB. 
>>>
>>> I am working on releasing and I hope this does not block things. 
>>>
>>> Chris
>>
>> Hello Chris,
>>
>> the non-working device tree is for the master branch from a few weeks
>> back. I didn't tested it with the 5-freebsd-12 branch.
> 
> Which FDT files are needed for the 5-freebsd-12 branch? I could assume the
> 12-release branch in the FreeBSD repo however this is a guess, unfriendly on 
> our
> part and time consuming to sort out. I am not sure how we improve this and how
> we should manage FDT source but we need to address the issue.

Same problem here. The topic already popped up multiple times and I
can't really answer it.

Like I said multiple time: My approach is to use the fdt that matches
the FreeBSD commit used in libbsd. So for the 5-freebsd-12 branch that
is the one from FreeBSD commit 0d1c391321b34b3025cf0e72f2231d836ff76da8.
But it's not a rule that works for all BSPs. Some BSPs are adapted to
use a board manufacturers DTB or some random Linux one.

> 
> There are long time RTEMS users including myself struggling with this so it 
> is a
> clear indication in my mind we have an issue we need to improve.
> 
>>> Again: In the normal case I would just suggest to use the FDT sources
>> that match the FreeBSD commit we use for libbsd. That worked best for me
>> in the past. But in the current referenced commit FreeBSD has updated
>> the device tree sources to the ones from a recent Linux version and the
>> drivers haven't been adapted yet (on master - I expect that it works
>> better on 5-freebsd-12).
>>
>> Regarding the release: I don't think you pack the FDT files (yet), do
>> you? 
> 
> No I do not but then should I be the one doing this in a release. I would have
> thought this is a core issue for the BSPs that depend on FDT blobs at runtime.
> 
> I am up to libbsd with the release packaging. I can build a beagleboneblack 
> as a
> vertical stack up to libbsd and then I hit the issue of using master and not 
> the
> 5-freebsd-12 branch and after that is the rtems_waf submodule naming. I would
> like to resolve this in the RSB however before I do this I would like to 
> resolve
> the FDT files so I make a single pass over this.
> 
>> So I don't see why there should be a reason for this topic to block
>> the release.
> 
> I do. To not handle this is to create a release where the files in the release
> package crash a beagleboneblack with libbsd unless you manually get the 
> correct
> set of FDT files. This is unhelpful for users in a release context.
> 
> Consider a release called rtems-libbsd-5.0.5.tar.xz that you build. Some of 
> the
> libbsd tests work and some do not. Is the RTEMS release broken? You have never
> used RTEMS and you have never used libbsd. It is all new, untested and
> unfamiliar and when you follow a simple example to start networking it 
> crashes.
> After a bit of digging or a post to the user list and 

Re: Device Tree Blob for Beaglebone Black?

[Chris Johns]

> On 24 Feb 2020, at 7:39 pm, Christian Mauderer 
>  wrote:
> 
> On 24/02/2020 07:01, Chris Johns wrote:
>> 
>> 
 On 24 Feb 2020, at 5:32 am, Christian Mauderer  wrote:
>>> 
>>> On 23/02/2020 17:07, Alan Cudmore wrote:
 I have been trying to bring up RTEMS with rtems-libbsd on the
 beaglebone black (latest master).
 
 I can run the regular RTEMS samples on the board, and a couple of the
 rtems-libbsd testsuite examples run as well.
 
 The samples such as ping01 and usb01 get a fatal exception in the
 function fdt_ro_probe_ , leading me to believe that maybe I am not
 using the correct device tree blob.
 
 I'm using the instructions here:
 https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
 
 And I have am loading am335x-boneblack.dtb that I copied from a linux
 u-boot build. The instructions talk about getting the one from the
 FreeBSD repository, but there are many other files included in that
 dts source.
 
 What dtb is normally used for the Beaglebone black RTEMS libbsd testing?
 
 Is the dtb needed for the non-libbsd BSP?
 
 Also, is the ethernet supported on the RTEMS beagle BSP, or do I need
 libbsd to get ethernet?
 
 Thanks,
 Alan
>>> 
>>> Hello Alan,
>>> 
>>> I recommend to use the FreeBSD device trees. libbsd is FreeBSD based and
>>> therefore works best with them. Normally I would suggest to use the
>>> version matching the FreeBSD commit used in libbsd. But unfortunately in
>>> the last commit that doesn't seem to work. Vijay had some problems with
>>> it and noted that the version from FreeBSD commit
>>> 19a6ceb89dbacf74697d493e48c388767126d418 works fine.
>> 
>> Is this with 5 branch in Libbsd?
>> 
>> I am a little confused about the branch to package in a release and also 
>> which FDT files we need for which branch. If different I feel a release will 
>> makes things more complicated. This flies into the BSP  vertical stack 
>> building in the RSB. 
>> 
>> I am working on releasing and I hope this does not block things. 
>> 
>> Chris
> 
> Hello Chris,
> 
> the non-working device tree is for the master branch from a few weeks
> back. I didn't tested it with the 5-freebsd-12 branch.

Which FDT files are needed for the 5-freebsd-12 branch? I could assume the
12-release branch in the FreeBSD repo however this is a guess, unfriendly on our
part and time consuming to sort out. I am not sure how we improve this and how
we should manage FDT source but we need to address the issue.

There are long time RTEMS users including myself struggling with this so it is a
clear indication in my mind we have an issue we need to improve.

> > Again: In the normal case I would just suggest to use the FDT sources
> that match the FreeBSD commit we use for libbsd. That worked best for me
> in the past. But in the current referenced commit FreeBSD has updated
> the device tree sources to the ones from a recent Linux version and the
> drivers haven't been adapted yet (on master - I expect that it works
> better on 5-freebsd-12).
> 
> Regarding the release: I don't think you pack the FDT files (yet), do
> you? 

No I do not but then should I be the one doing this in a release. I would have
thought this is a core issue for the BSPs that depend on FDT blobs at runtime.

I am up to libbsd with the release packaging. I can build a beagleboneblack as a
vertical stack up to libbsd and then I hit the issue of using master and not the
5-freebsd-12 branch and after that is the rtems_waf submodule naming. I would
like to resolve this in the RSB however before I do this I would like to resolve
the FDT files so I make a single pass over this.

> So I don't see why there should be a reason for this topic to block
> the release.

I do. To not handle this is to create a release where the files in the release
package crash a beagleboneblack with libbsd unless you manually get the correct
set of FDT files. This is unhelpful for users in a release context.

Consider a release called rtems-libbsd-5.0.5.tar.xz that you build. Some of the
libbsd tests work and some do not. Is the RTEMS release broken? You have never
used RTEMS and you have never used libbsd. It is all new, untested and
unfamiliar and when you follow a simple example to start networking it crashes.
After a bit of digging or a post to the user list and you find out you are
suppose to find FDT files to match from deep in the FreeBSD source. This is not
user friendly and we have not packaged what is needed to run a board. FDT is
important to RTEMS so it is important we manage it.

I would like this resolved this and for the RTEMS 5 release. The more that help
and contribute the quicker it is done and sooner I can release RTEMS 5.

> Note that the exact FDT version used for different BSPs is still a
> bigger problem. 

I see it as the same problem, it is just bigger in size than a BBB.

> Some BSPs expect a version provided by a board
> manufacturer. 

Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

On 24/02/2020 19:43, Alan Cudmore wrote:
> It looks like the mkimage command difference fixed the crash.
> 
> The original BSP README:
> https://git.rtems.org/rtems/tree/bsps/arm/beagle/README
> $ mkimage -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n
> RTEMS -d $exe.bin.gz rtems-app.img
> 
> The docs.rtems.org beagle BSP readme:
> https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
> mkimage -A arm -O linux -T kernel -a 0x8000 -e 0x8000 -n RTEMS
> -d app.bin.gz rtems-app.img

I think that the README is heavily outdated. Is there some information
left in it that isn't in the User Manual (docs.rtems.org)? If no: Would
you like to send a patch that removes it?

> 
> Thanks for the help! Next is trying to get the ethernet to communicate
> with a host!
> 
> Alan
> 
> On Mon, Feb 24, 2020 at 12:08 PM Vijay Kumar Banerjee
>  wrote:
>>
>>
>>
>>
>> On Mon, Feb 24, 2020 at 8:16 PM Alan Cudmore  wrote:
>>>
>>> Hi Vijay,
>>> My uEnv.txt was very similar, but I did not have the "fdt addr
>>> 0x8800" command. But that did not seem to help. I still get a
>>> fatal exception when trying to run the usb01 and ping01 programs.
>>>
>>> Do you think the u-boot version matters?
>>> I am using the following:
>>> - MLO and u-boot.img from a buildroot linux build. ( u-boot 2018.1)
>>
>> I don't think it's making much difference. I'm currently running u-boot 
>> 2018.11
>>>
>>> - RTEMS kernel master from about a week ago ( samples like unlimited
>>> and ticker work )
>>> - rtems-libbsd 5-freebsd-12 branch
>>
>> I haven't tested with 5-freebsd-12 branch but it runs fine on master branch.
>>>
>>> - The am335x-boneblack.dtb compiled from the suggested commit from the
>>> FreeBSD github repository.
>>>
>> This one is fine.
>>>
>>> I don't have a debugger, so I looked up the PC address from the register 
>>> dump.
>>> For the ping01 sample the PC indicates that it is in the fdt_ro_probe_ 
>>> function.
>>> For the usb01, it seems to crash in an termios program.
>>>
>>> ## Transferring control to RTEMS (at address 8000) ...
>>>
>>> RTEMS Beagleboard: am335x-based
>>> ARM Debug: 0x4b141000
>>> *** LIBBSD PING 1 TEST ***
>>>
>>> *** FATAL ***
>>> fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
>>>
>>> R0   = 0x R8  = 0x
>>> R1   = 0xfeed R9  = 0x
>>> R2   = 0x0007 R10 = 0x0064
>>> R3   = 0x006e6573 R11 = 0x802520a0
>>> R4   = 0x0007 R12 = 0x01010101
>>> R5   = 0xfff7 SP  = 0x8027589c
>>> R6   = 0x80150dac LR  = 0x8011b1d0
>>> R7   = 0x PC  = 0x8011a11c
>>> CPSR = 0x0113 VEC = 0x0004
>>> RTEMS version: 5.0.0.588646279951ff696f3893a4c2e79aa1ba67fccf
>>> RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (57011908b007), Newlib 
>>> d14714c69)
>>> executing thread ID: 0x08a010001
>>> executing thread name: UI1
>>>
>>> One more question:
>>> I am converting the images using the following commands:
>>> arm-rtems5-objcopy $1.exe -O binary $1.bin
>>> gzip -9 $1.bin
>>> mkimage -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n RTEMS
>>> -d $1.bin.gz $1-app.img
>>>
>> Mine is similar with a slight change in OS option:
>>
>> arm-rtems5-objcopy $executable -O binary $TMPDIR/${base}.bin
>> gzip -9 $TMPDIR/${base}.bin
>> mkimage -A arm -O linux -T kernel -a 0x8000 -e 0x8000 -n RTEMS -d 
>> $TMPDIR/${base}.bin.gz $TMPDIR/$app
>>
>>> Are the 0x8000. addresses correct in the mkimage command? It seems
>>> that the RTEMS executable considers the start of RAM to be 0x8000.
>>>
>> Yes, the start address is correct.
>>>
>>> It might be good to have an image I can try.
>>>
>> I'll send that to you offlist shortly :)
>>>
>>> Thanks for the help!
>>> Alan
>>>
>>> On Mon, Feb 24, 2020 at 12:57 AM Vijay Kumar Banerjee
>>>  wrote:



 On Sun, Feb 23, 2020 at 11:46 PM Alan Cudmore  
 wrote:
>
> Hi Christian,
> Thanks for the quick response. I followed the instructions in the
> docs.rtems.org manual and generated the dtb from the FreeBSD commit
> that Vijay suggested. It still resulted in an exception in the same
> function.
>
> Do you know if a specific commit of rtems-libbsd is required to work
> with that dtb?
> I tried master, and then the "5-freebsd-12" branch.
>
> Thanks,
> Alan
>
 Hi Alan,

 I checked with the usb01 and ping01 tests running on libbsd master
 and the dtb from the commit mentioned by Christian. I can't reproduce
 the error and it seems to run as expected. I'm not sure where the
 error might be coming from. Below I'm pasting the contents of my uEnv.txt
 If the error isn't in the uEnv, I can send you my sd card image(offlist) 
 so that you
 can try that on your board and that might give some hint on what was going
 wrong.

 ```
 setenv bootdelay 5
 uenvcmd=run boot
 boot=fatload mmc 0 0x8080 rtems-app.img ; fatload mmc 0 0x8800 
 am335x-boneblack.dtb ; fdt addr 0x8800; bootm 

Re: Device Tree Blob for Beaglebone Black?

[Alan Cudmore]

It looks like the mkimage command difference fixed the crash.

The original BSP README:
https://git.rtems.org/rtems/tree/bsps/arm/beagle/README
$ mkimage -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n
RTEMS -d $exe.bin.gz rtems-app.img

The docs.rtems.org beagle BSP readme:
https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
mkimage -A arm -O linux -T kernel -a 0x8000 -e 0x8000 -n RTEMS
-d app.bin.gz rtems-app.img

Thanks for the help! Next is trying to get the ethernet to communicate
with a host!

Alan

On Mon, Feb 24, 2020 at 12:08 PM Vijay Kumar Banerjee
 wrote:
>
>
>
>
> On Mon, Feb 24, 2020 at 8:16 PM Alan Cudmore  wrote:
>>
>> Hi Vijay,
>> My uEnv.txt was very similar, but I did not have the "fdt addr
>> 0x8800" command. But that did not seem to help. I still get a
>> fatal exception when trying to run the usb01 and ping01 programs.
>>
>> Do you think the u-boot version matters?
>> I am using the following:
>> - MLO and u-boot.img from a buildroot linux build. ( u-boot 2018.1)
>
> I don't think it's making much difference. I'm currently running u-boot 
> 2018.11
>>
>> - RTEMS kernel master from about a week ago ( samples like unlimited
>> and ticker work )
>> - rtems-libbsd 5-freebsd-12 branch
>
> I haven't tested with 5-freebsd-12 branch but it runs fine on master branch.
>>
>> - The am335x-boneblack.dtb compiled from the suggested commit from the
>> FreeBSD github repository.
>>
> This one is fine.
>>
>> I don't have a debugger, so I looked up the PC address from the register 
>> dump.
>> For the ping01 sample the PC indicates that it is in the fdt_ro_probe_ 
>> function.
>> For the usb01, it seems to crash in an termios program.
>>
>> ## Transferring control to RTEMS (at address 8000) ...
>>
>> RTEMS Beagleboard: am335x-based
>> ARM Debug: 0x4b141000
>> *** LIBBSD PING 1 TEST ***
>>
>> *** FATAL ***
>> fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
>>
>> R0   = 0x R8  = 0x
>> R1   = 0xfeed R9  = 0x
>> R2   = 0x0007 R10 = 0x0064
>> R3   = 0x006e6573 R11 = 0x802520a0
>> R4   = 0x0007 R12 = 0x01010101
>> R5   = 0xfff7 SP  = 0x8027589c
>> R6   = 0x80150dac LR  = 0x8011b1d0
>> R7   = 0x PC  = 0x8011a11c
>> CPSR = 0x0113 VEC = 0x0004
>> RTEMS version: 5.0.0.588646279951ff696f3893a4c2e79aa1ba67fccf
>> RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (57011908b007), Newlib d14714c69)
>> executing thread ID: 0x08a010001
>> executing thread name: UI1
>>
>> One more question:
>> I am converting the images using the following commands:
>> arm-rtems5-objcopy $1.exe -O binary $1.bin
>> gzip -9 $1.bin
>> mkimage -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n RTEMS
>> -d $1.bin.gz $1-app.img
>>
> Mine is similar with a slight change in OS option:
>
> arm-rtems5-objcopy $executable -O binary $TMPDIR/${base}.bin
> gzip -9 $TMPDIR/${base}.bin
> mkimage -A arm -O linux -T kernel -a 0x8000 -e 0x8000 -n RTEMS -d 
> $TMPDIR/${base}.bin.gz $TMPDIR/$app
>
>> Are the 0x8000. addresses correct in the mkimage command? It seems
>> that the RTEMS executable considers the start of RAM to be 0x8000.
>>
> Yes, the start address is correct.
>>
>> It might be good to have an image I can try.
>>
> I'll send that to you offlist shortly :)
>>
>> Thanks for the help!
>> Alan
>>
>> On Mon, Feb 24, 2020 at 12:57 AM Vijay Kumar Banerjee
>>  wrote:
>> >
>> >
>> >
>> > On Sun, Feb 23, 2020 at 11:46 PM Alan Cudmore  
>> > wrote:
>> >>
>> >> Hi Christian,
>> >> Thanks for the quick response. I followed the instructions in the
>> >> docs.rtems.org manual and generated the dtb from the FreeBSD commit
>> >> that Vijay suggested. It still resulted in an exception in the same
>> >> function.
>> >>
>> >> Do you know if a specific commit of rtems-libbsd is required to work
>> >> with that dtb?
>> >> I tried master, and then the "5-freebsd-12" branch.
>> >>
>> >> Thanks,
>> >> Alan
>> >>
>> > Hi Alan,
>> >
>> > I checked with the usb01 and ping01 tests running on libbsd master
>> > and the dtb from the commit mentioned by Christian. I can't reproduce
>> > the error and it seems to run as expected. I'm not sure where the
>> > error might be coming from. Below I'm pasting the contents of my uEnv.txt
>> > If the error isn't in the uEnv, I can send you my sd card image(offlist) 
>> > so that you
>> > can try that on your board and that might give some hint on what was going
>> > wrong.
>> >
>> > ```
>> > setenv bootdelay 5
>> > uenvcmd=run boot
>> > boot=fatload mmc 0 0x8080 rtems-app.img ; fatload mmc 0 0x8800 
>> > am335x-boneblack.dtb ; fdt addr 0x8800; bootm 0x8080 - 0x8800
>> > ```
>> >
>> > Best regards,
>> > Vijay
>> >>
>> >> On Sun, Feb 23, 2020 at 11:32 AM Christian Mauderer  
>> >> wrote:
>> >> >
>> >> > On 23/02/2020 17:07, Alan Cudmore wrote:
>> >> > > I have been trying to bring up RTEMS with rtems-libbsd on the
>> >> > > beaglebone black (latest master).
>> >> > >
>> >> > > I can run the regular 

Re: Device Tree Blob for Beaglebone Black?

[Vijay Kumar Banerjee]

On Mon, Feb 24, 2020 at 8:16 PM Alan Cudmore  wrote:

> Hi Vijay,
> My uEnv.txt was very similar, but I did not have the "fdt addr
> 0x8800" command. But that did not seem to help. I still get a
> fatal exception when trying to run the usb01 and ping01 programs.
>
> Do you think the u-boot version matters?
> I am using the following:
> - MLO and u-boot.img from a buildroot linux build. ( u-boot 2018.1)
>
I don't think it's making much difference. I'm currently running u-boot
2018.11

> - RTEMS kernel master from about a week ago ( samples like unlimited
> and ticker work )
> - rtems-libbsd 5-freebsd-12 branch
>
I haven't tested with 5-freebsd-12 branch but it runs fine on master
branch.

> - The am335x-boneblack.dtb compiled from the suggested commit from the
> FreeBSD github repository.
>
> This one is fine.

> I don't have a debugger, so I looked up the PC address from the register
> dump.
> For the ping01 sample the PC indicates that it is in the fdt_ro_probe_
> function.
> For the usb01, it seems to crash in an termios program.
>
> ## Transferring control to RTEMS (at address 8000) ...
>
> RTEMS Beagleboard: am335x-based
> ARM Debug: 0x4b141000
> *** LIBBSD PING 1 TEST ***
>
> *** FATAL ***
> fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
>
> R0   = 0x R8  = 0x
> R1   = 0xfeed R9  = 0x
> R2   = 0x0007 R10 = 0x0064
> R3   = 0x006e6573 R11 = 0x802520a0
> R4   = 0x0007 R12 = 0x01010101
> R5   = 0xfff7 SP  = 0x8027589c
> R6   = 0x80150dac LR  = 0x8011b1d0
> R7   = 0x PC  = 0x8011a11c
> CPSR = 0x0113 VEC = 0x0004
> RTEMS version: 5.0.0.588646279951ff696f3893a4c2e79aa1ba67fccf
> RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (57011908b007), Newlib
> d14714c69)
> executing thread ID: 0x08a010001
> executing thread name: UI1
>
> One more question:
> I am converting the images using the following commands:
> arm-rtems5-objcopy $1.exe -O binary $1.bin
> gzip -9 $1.bin
> mkimage -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n RTEMS
> -d $1.bin.gz $1-app.img
>
> Mine is similar with a slight change in OS option:

arm-rtems5-objcopy $executable -O binary $TMPDIR/${base}.bin
gzip -9 $TMPDIR/${base}.bin
mkimage -A arm -O linux -T kernel -a 0x8000 -e 0x8000 -n RTEMS -d
$TMPDIR/${base}.bin.gz $TMPDIR/$app

Are the 0x8000. addresses correct in the mkimage command? It seems
> that the RTEMS executable considers the start of RAM to be 0x8000.
>
> Yes, the start address is correct.

> It might be good to have an image I can try.
>
> I'll send that to you offlist shortly :)

> Thanks for the help!
> Alan
>
> On Mon, Feb 24, 2020 at 12:57 AM Vijay Kumar Banerjee
>  wrote:
> >
> >
> >
> > On Sun, Feb 23, 2020 at 11:46 PM Alan Cudmore 
> wrote:
> >>
> >> Hi Christian,
> >> Thanks for the quick response. I followed the instructions in the
> >> docs.rtems.org manual and generated the dtb from the FreeBSD commit
> >> that Vijay suggested. It still resulted in an exception in the same
> >> function.
> >>
> >> Do you know if a specific commit of rtems-libbsd is required to work
> >> with that dtb?
> >> I tried master, and then the "5-freebsd-12" branch.
> >>
> >> Thanks,
> >> Alan
> >>
> > Hi Alan,
> >
> > I checked with the usb01 and ping01 tests running on libbsd master
> > and the dtb from the commit mentioned by Christian. I can't reproduce
> > the error and it seems to run as expected. I'm not sure where the
> > error might be coming from. Below I'm pasting the contents of my uEnv.txt
> > If the error isn't in the uEnv, I can send you my sd card image(offlist)
> so that you
> > can try that on your board and that might give some hint on what was
> going
> > wrong.
> >
> > ```
> > setenv bootdelay 5
> > uenvcmd=run boot
> > boot=fatload mmc 0 0x8080 rtems-app.img ; fatload mmc 0 0x8800
> am335x-boneblack.dtb ; fdt addr 0x8800; bootm 0x8080 - 0x8800
> > ```
> >
> > Best regards,
> > Vijay
> >>
> >> On Sun, Feb 23, 2020 at 11:32 AM Christian Mauderer 
> wrote:
> >> >
> >> > On 23/02/2020 17:07, Alan Cudmore wrote:
> >> > > I have been trying to bring up RTEMS with rtems-libbsd on the
> >> > > beaglebone black (latest master).
> >> > >
> >> > > I can run the regular RTEMS samples on the board, and a couple of
> the
> >> > > rtems-libbsd testsuite examples run as well.
> >> > >
> >> > > The samples such as ping01 and usb01 get a fatal exception in the
> >> > > function fdt_ro_probe_ , leading me to believe that maybe I am not
> >> > > using the correct device tree blob.
> >> > >
> >> > > I'm using the instructions here:
> >> > > https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
> >> > >
> >> > > And I have am loading am335x-boneblack.dtb that I copied from a
> linux
> >> > > u-boot build. The instructions talk about getting the one from the
> >> > > FreeBSD repository, but there are many other files included in that
> >> > > dts source.
> >> > >
> >> > > What dtb is normally used for the Beaglebone 

Re: Device Tree Blob for Beaglebone Black?

[Alan Cudmore]

Hi Vijay,
My uEnv.txt was very similar, but I did not have the "fdt addr
0x8800" command. But that did not seem to help. I still get a
fatal exception when trying to run the usb01 and ping01 programs.

Do you think the u-boot version matters?
I am using the following:
- MLO and u-boot.img from a buildroot linux build. ( u-boot 2018.1)
- RTEMS kernel master from about a week ago ( samples like unlimited
and ticker work )
- rtems-libbsd 5-freebsd-12 branch
- The am335x-boneblack.dtb compiled from the suggested commit from the
FreeBSD github repository.

I don't have a debugger, so I looked up the PC address from the register dump.
For the ping01 sample the PC indicates that it is in the fdt_ro_probe_ function.
For the usb01, it seems to crash in an termios program.

## Transferring control to RTEMS (at address 8000) ...

RTEMS Beagleboard: am335x-based
ARM Debug: 0x4b141000
*** LIBBSD PING 1 TEST ***

*** FATAL ***
fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)

R0   = 0x R8  = 0x
R1   = 0xfeed R9  = 0x
R2   = 0x0007 R10 = 0x0064
R3   = 0x006e6573 R11 = 0x802520a0
R4   = 0x0007 R12 = 0x01010101
R5   = 0xfff7 SP  = 0x8027589c
R6   = 0x80150dac LR  = 0x8011b1d0
R7   = 0x PC  = 0x8011a11c
CPSR = 0x0113 VEC = 0x0004
RTEMS version: 5.0.0.588646279951ff696f3893a4c2e79aa1ba67fccf
RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (57011908b007), Newlib d14714c69)
executing thread ID: 0x08a010001
executing thread name: UI1

One more question:
I am converting the images using the following commands:
arm-rtems5-objcopy $1.exe -O binary $1.bin
gzip -9 $1.bin
mkimage -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n RTEMS
-d $1.bin.gz $1-app.img

Are the 0x8000. addresses correct in the mkimage command? It seems
that the RTEMS executable considers the start of RAM to be 0x8000.

It might be good to have an image I can try.

Thanks for the help!
Alan

On Mon, Feb 24, 2020 at 12:57 AM Vijay Kumar Banerjee
 wrote:
>
>
>
> On Sun, Feb 23, 2020 at 11:46 PM Alan Cudmore  wrote:
>>
>> Hi Christian,
>> Thanks for the quick response. I followed the instructions in the
>> docs.rtems.org manual and generated the dtb from the FreeBSD commit
>> that Vijay suggested. It still resulted in an exception in the same
>> function.
>>
>> Do you know if a specific commit of rtems-libbsd is required to work
>> with that dtb?
>> I tried master, and then the "5-freebsd-12" branch.
>>
>> Thanks,
>> Alan
>>
> Hi Alan,
>
> I checked with the usb01 and ping01 tests running on libbsd master
> and the dtb from the commit mentioned by Christian. I can't reproduce
> the error and it seems to run as expected. I'm not sure where the
> error might be coming from. Below I'm pasting the contents of my uEnv.txt
> If the error isn't in the uEnv, I can send you my sd card image(offlist) so 
> that you
> can try that on your board and that might give some hint on what was going
> wrong.
>
> ```
> setenv bootdelay 5
> uenvcmd=run boot
> boot=fatload mmc 0 0x8080 rtems-app.img ; fatload mmc 0 0x8800 
> am335x-boneblack.dtb ; fdt addr 0x8800; bootm 0x8080 - 0x8800
> ```
>
> Best regards,
> Vijay
>>
>> On Sun, Feb 23, 2020 at 11:32 AM Christian Mauderer  
>> wrote:
>> >
>> > On 23/02/2020 17:07, Alan Cudmore wrote:
>> > > I have been trying to bring up RTEMS with rtems-libbsd on the
>> > > beaglebone black (latest master).
>> > >
>> > > I can run the regular RTEMS samples on the board, and a couple of the
>> > > rtems-libbsd testsuite examples run as well.
>> > >
>> > > The samples such as ping01 and usb01 get a fatal exception in the
>> > > function fdt_ro_probe_ , leading me to believe that maybe I am not
>> > > using the correct device tree blob.
>> > >
>> > > I'm using the instructions here:
>> > > https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
>> > >
>> > > And I have am loading am335x-boneblack.dtb that I copied from a linux
>> > > u-boot build. The instructions talk about getting the one from the
>> > > FreeBSD repository, but there are many other files included in that
>> > > dts source.
>> > >
>> > > What dtb is normally used for the Beaglebone black RTEMS libbsd testing?
>> > >
>> > > Is the dtb needed for the non-libbsd BSP?
>> > >
>> > > Also, is the ethernet supported on the RTEMS beagle BSP, or do I need
>> > > libbsd to get ethernet?
>> > >
>> > > Thanks,
>> > > Alan
>> >
>> > Hello Alan,
>> >
>> > I recommend to use the FreeBSD device trees. libbsd is FreeBSD based and
>> > therefore works best with them. Normally I would suggest to use the
>> > version matching the FreeBSD commit used in libbsd. But unfortunately in
>> > the last commit that doesn't seem to work. Vijay had some problems with
>> > it and noted that the version from FreeBSD commit
>> > 19a6ceb89dbacf74697d493e48c388767126d418 works fine.
>> >
>> > Regarding Ethernet support: As far as I know there is no support for the
>> > legacy stack. But the one in libbsd 

Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

On 24/02/2020 07:01, Chris Johns wrote:
> 
> 
>> On 24 Feb 2020, at 5:32 am, Christian Mauderer  wrote:
>>
>> On 23/02/2020 17:07, Alan Cudmore wrote:
>>> I have been trying to bring up RTEMS with rtems-libbsd on the
>>> beaglebone black (latest master).
>>>
>>> I can run the regular RTEMS samples on the board, and a couple of the
>>> rtems-libbsd testsuite examples run as well.
>>>
>>> The samples such as ping01 and usb01 get a fatal exception in the
>>> function fdt_ro_probe_ , leading me to believe that maybe I am not
>>> using the correct device tree blob.
>>>
>>> I'm using the instructions here:
>>> https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
>>>
>>> And I have am loading am335x-boneblack.dtb that I copied from a linux
>>> u-boot build. The instructions talk about getting the one from the
>>> FreeBSD repository, but there are many other files included in that
>>> dts source.
>>>
>>> What dtb is normally used for the Beaglebone black RTEMS libbsd testing?
>>>
>>> Is the dtb needed for the non-libbsd BSP?
>>>
>>> Also, is the ethernet supported on the RTEMS beagle BSP, or do I need
>>> libbsd to get ethernet?
>>>
>>> Thanks,
>>> Alan
>>
>> Hello Alan,
>>
>> I recommend to use the FreeBSD device trees. libbsd is FreeBSD based and
>> therefore works best with them. Normally I would suggest to use the
>> version matching the FreeBSD commit used in libbsd. But unfortunately in
>> the last commit that doesn't seem to work. Vijay had some problems with
>> it and noted that the version from FreeBSD commit
>> 19a6ceb89dbacf74697d493e48c388767126d418 works fine.
> 
> Is this with 5 branch in Libbsd?
> 
> I am a little confused about the branch to package in a release and also 
> which FDT files we need for which branch. If different I feel a release will 
> makes things more complicated. This flies into the BSP  vertical stack 
> building in the RSB. 
> 
> I am working on releasing and I hope this does not block things. 
> 
> Chris

Hello Chris,

the non-working device tree is for the master branch from a few weeks
back. I didn't tested it with the 5-freebsd-12 branch.

Again: In the normal case I would just suggest to use the FDT sources
that match the FreeBSD commit we use for libbsd. That worked best for me
in the past. But in the current referenced commit FreeBSD has updated
the device tree sources to the ones from a recent Linux version and the
drivers haven't been adapted yet (on master - I expect that it works
better on 5-freebsd-12).

Regarding the release: I don't think you pack the FDT files (yet), do
you? So I don't see why there should be a reason for this topic to block
the release.

Note that the exact FDT version used for different BSPs is still a
bigger problem. Some BSPs expect a version provided by a board
manufacturer. Some use a random Linux DTB. And some work well with the
ones from FreeBSD (which is just a snapshot of the Linux ones) - that's
the method I prefer because it works well with libbsd most of the time.
I think currently the right device tree for the board is only documented
in the User Manual (if it is documented).

Best regards

Christian
-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

On 24/02/2020 06:57, Vijay Kumar Banerjee wrote:
> 
> 
> On Sun, Feb 23, 2020 at 11:46 PM Alan Cudmore  > wrote:
> 
> Hi Christian,
> Thanks for the quick response. I followed the instructions in the
> docs.rtems.org  manual and generated the dtb
> from the FreeBSD commit
> that Vijay suggested. It still resulted in an exception in the same
> function.
> 
> Do you know if a specific commit of rtems-libbsd is required to work
> with that dtb?
> I tried master, and then the "5-freebsd-12" branch.
> 
> Thanks,
> Alan
> 
> Hi Alan,
> 
> I checked with the usb01 and ping01 tests running on libbsd master
> and the dtb from the commit mentioned by Christian. I can't reproduce
> the error and it seems to run as expected. I'm not sure where the
> error might be coming from. Below I'm pasting the contents of my uEnv.txt
> If the error isn't in the uEnv, I can send you my sd card image(offlist)
> so that you
> can try that on your board and that might give some hint on what was going
> wrong.
> 
> ```
> setenv bootdelay 5
> uenvcmd=run boot
> boot=fatload mmc 0 0x8080 rtems-app.img ; fatload mmc 0 0x8800
> am335x-boneblack.dtb ; fdt addr 0x8800; bootm 0x8080 - 0x8800
> ```
> 
> Best regards,
> Vijay

Hello Alan,

another point: You know that your exception is in fdt_ro_probe_. So I
assume you have a debugger connected? Can you post a full backtrace so
that we can see from which driver the exception comes from?

Best regards

Christian

> 
> On Sun, Feb 23, 2020 at 11:32 AM Christian Mauderer
> mailto:l...@c-mauderer.de>> wrote:
> >
> > On 23/02/2020 17:07, Alan Cudmore wrote:
> > > I have been trying to bring up RTEMS with rtems-libbsd on the
> > > beaglebone black (latest master).
> > >
> > > I can run the regular RTEMS samples on the board, and a couple
> of the
> > > rtems-libbsd testsuite examples run as well.
> > >
> > > The samples such as ping01 and usb01 get a fatal exception in the
> > > function fdt_ro_probe_ , leading me to believe that maybe I am not
> > > using the correct device tree blob.
> > >
> > > I'm using the instructions here:
> > > https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
> > >
> > > And I have am loading am335x-boneblack.dtb that I copied from a
> linux
> > > u-boot build. The instructions talk about getting the one from the
> > > FreeBSD repository, but there are many other files included in that
> > > dts source.
> > >
> > > What dtb is normally used for the Beaglebone black RTEMS libbsd
> testing?
> > >
> > > Is the dtb needed for the non-libbsd BSP?
> > >
> > > Also, is the ethernet supported on the RTEMS beagle BSP, or do I
> need
> > > libbsd to get ethernet?
> > >
> > > Thanks,
> > > Alan
> >
> > Hello Alan,
> >
> > I recommend to use the FreeBSD device trees. libbsd is FreeBSD
> based and
> > therefore works best with them. Normally I would suggest to use the
> > version matching the FreeBSD commit used in libbsd. But
> unfortunately in
> > the last commit that doesn't seem to work. Vijay had some problems
> with
> > it and noted that the version from FreeBSD commit
> > 19a6ceb89dbacf74697d493e48c388767126d418 works fine.
> >
> > Regarding Ethernet support: As far as I know there is no support
> for the
> > legacy stack. But the one in libbsd worked fine the last time I tested
> > it (which was when I ported it). If you really want to use the legacy
> > stack please note that it is still an IPv4 only one and therefore
> it is
> > quite limited nowadays.
> >
> > Best regards
> >
> > Christian
> ___
> 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
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Device Tree Blob for Beaglebone Black?

[Chris Johns]

> On 24 Feb 2020, at 5:32 am, Christian Mauderer  wrote:
> 
> On 23/02/2020 17:07, Alan Cudmore wrote:
>> I have been trying to bring up RTEMS with rtems-libbsd on the
>> beaglebone black (latest master).
>> 
>> I can run the regular RTEMS samples on the board, and a couple of the
>> rtems-libbsd testsuite examples run as well.
>> 
>> The samples such as ping01 and usb01 get a fatal exception in the
>> function fdt_ro_probe_ , leading me to believe that maybe I am not
>> using the correct device tree blob.
>> 
>> I'm using the instructions here:
>> https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
>> 
>> And I have am loading am335x-boneblack.dtb that I copied from a linux
>> u-boot build. The instructions talk about getting the one from the
>> FreeBSD repository, but there are many other files included in that
>> dts source.
>> 
>> What dtb is normally used for the Beaglebone black RTEMS libbsd testing?
>> 
>> Is the dtb needed for the non-libbsd BSP?
>> 
>> Also, is the ethernet supported on the RTEMS beagle BSP, or do I need
>> libbsd to get ethernet?
>> 
>> Thanks,
>> Alan
> 
> Hello Alan,
> 
> I recommend to use the FreeBSD device trees. libbsd is FreeBSD based and
> therefore works best with them. Normally I would suggest to use the
> version matching the FreeBSD commit used in libbsd. But unfortunately in
> the last commit that doesn't seem to work. Vijay had some problems with
> it and noted that the version from FreeBSD commit
> 19a6ceb89dbacf74697d493e48c388767126d418 works fine.

Is this with 5 branch in Libbsd?

I am a little confused about the branch to package in a release and also which 
FDT files we need for which branch. If different I feel a release will makes 
things more complicated. This flies into the BSP  vertical stack building in 
the RSB. 

I am working on releasing and I hope this does not block things. 

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

Re: Device Tree Blob for Beaglebone Black?

[Vijay Kumar Banerjee]

On Sun, Feb 23, 2020 at 11:46 PM Alan Cudmore 
wrote:

> Hi Christian,
> Thanks for the quick response. I followed the instructions in the
> docs.rtems.org manual and generated the dtb from the FreeBSD commit
> that Vijay suggested. It still resulted in an exception in the same
> function.
>
> Do you know if a specific commit of rtems-libbsd is required to work
> with that dtb?
> I tried master, and then the "5-freebsd-12" branch.
>
> Thanks,
> Alan
>
> Hi Alan,

I checked with the usb01 and ping01 tests running on libbsd master
and the dtb from the commit mentioned by Christian. I can't reproduce
the error and it seems to run as expected. I'm not sure where the
error might be coming from. Below I'm pasting the contents of my uEnv.txt
If the error isn't in the uEnv, I can send you my sd card image(offlist) so
that you
can try that on your board and that might give some hint on what was going
wrong.

```
setenv bootdelay 5
uenvcmd=run boot
boot=fatload mmc 0 0x8080 rtems-app.img ; fatload mmc 0 0x8800
am335x-boneblack.dtb ; fdt addr 0x8800; bootm 0x8080 - 0x8800
```

Best regards,
Vijay

> On Sun, Feb 23, 2020 at 11:32 AM Christian Mauderer 
> wrote:
> >
> > On 23/02/2020 17:07, Alan Cudmore wrote:
> > > I have been trying to bring up RTEMS with rtems-libbsd on the
> > > beaglebone black (latest master).
> > >
> > > I can run the regular RTEMS samples on the board, and a couple of the
> > > rtems-libbsd testsuite examples run as well.
> > >
> > > The samples such as ping01 and usb01 get a fatal exception in the
> > > function fdt_ro_probe_ , leading me to believe that maybe I am not
> > > using the correct device tree blob.
> > >
> > > I'm using the instructions here:
> > > https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
> > >
> > > And I have am loading am335x-boneblack.dtb that I copied from a linux
> > > u-boot build. The instructions talk about getting the one from the
> > > FreeBSD repository, but there are many other files included in that
> > > dts source.
> > >
> > > What dtb is normally used for the Beaglebone black RTEMS libbsd
> testing?
> > >
> > > Is the dtb needed for the non-libbsd BSP?
> > >
> > > Also, is the ethernet supported on the RTEMS beagle BSP, or do I need
> > > libbsd to get ethernet?
> > >
> > > Thanks,
> > > Alan
> >
> > Hello Alan,
> >
> > I recommend to use the FreeBSD device trees. libbsd is FreeBSD based and
> > therefore works best with them. Normally I would suggest to use the
> > version matching the FreeBSD commit used in libbsd. But unfortunately in
> > the last commit that doesn't seem to work. Vijay had some problems with
> > it and noted that the version from FreeBSD commit
> > 19a6ceb89dbacf74697d493e48c388767126d418 works fine.
> >
> > Regarding Ethernet support: As far as I know there is no support for the
> > legacy stack. But the one in libbsd worked fine the last time I tested
> > it (which was when I ported it). If you really want to use the legacy
> > stack please note that it is still an IPv4 only one and therefore it is
> > quite limited nowadays.
> >
> > Best regards
> >
> > Christian
> ___
> 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: Device Tree Blob for Beaglebone Black?

[Alan Cudmore]

Hi Christian,
Thanks for the quick response. I followed the instructions in the
docs.rtems.org manual and generated the dtb from the FreeBSD commit
that Vijay suggested. It still resulted in an exception in the same
function.

Do you know if a specific commit of rtems-libbsd is required to work
with that dtb?
I tried master, and then the "5-freebsd-12" branch.

Thanks,
Alan

On Sun, Feb 23, 2020 at 11:32 AM Christian Mauderer  wrote:
>
> On 23/02/2020 17:07, Alan Cudmore wrote:
> > I have been trying to bring up RTEMS with rtems-libbsd on the
> > beaglebone black (latest master).
> >
> > I can run the regular RTEMS samples on the board, and a couple of the
> > rtems-libbsd testsuite examples run as well.
> >
> > The samples such as ping01 and usb01 get a fatal exception in the
> > function fdt_ro_probe_ , leading me to believe that maybe I am not
> > using the correct device tree blob.
> >
> > I'm using the instructions here:
> > https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
> >
> > And I have am loading am335x-boneblack.dtb that I copied from a linux
> > u-boot build. The instructions talk about getting the one from the
> > FreeBSD repository, but there are many other files included in that
> > dts source.
> >
> > What dtb is normally used for the Beaglebone black RTEMS libbsd testing?
> >
> > Is the dtb needed for the non-libbsd BSP?
> >
> > Also, is the ethernet supported on the RTEMS beagle BSP, or do I need
> > libbsd to get ethernet?
> >
> > Thanks,
> > Alan
>
> Hello Alan,
>
> I recommend to use the FreeBSD device trees. libbsd is FreeBSD based and
> therefore works best with them. Normally I would suggest to use the
> version matching the FreeBSD commit used in libbsd. But unfortunately in
> the last commit that doesn't seem to work. Vijay had some problems with
> it and noted that the version from FreeBSD commit
> 19a6ceb89dbacf74697d493e48c388767126d418 works fine.
>
> Regarding Ethernet support: As far as I know there is no support for the
> legacy stack. But the one in libbsd worked fine the last time I tested
> it (which was when I ported it). If you really want to use the legacy
> stack please note that it is still an IPv4 only one and therefore it is
> quite limited nowadays.
>
> Best regards
>
> Christian
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

On 23/02/2020 17:07, Alan Cudmore wrote:
> I have been trying to bring up RTEMS with rtems-libbsd on the
> beaglebone black (latest master).
> 
> I can run the regular RTEMS samples on the board, and a couple of the
> rtems-libbsd testsuite examples run as well.
> 
> The samples such as ping01 and usb01 get a fatal exception in the
> function fdt_ro_probe_ , leading me to believe that maybe I am not
> using the correct device tree blob.
> 
> I'm using the instructions here:
> https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
> 
> And I have am loading am335x-boneblack.dtb that I copied from a linux
> u-boot build. The instructions talk about getting the one from the
> FreeBSD repository, but there are many other files included in that
> dts source.
> 
> What dtb is normally used for the Beaglebone black RTEMS libbsd testing?
> 
> Is the dtb needed for the non-libbsd BSP?
> 
> Also, is the ethernet supported on the RTEMS beagle BSP, or do I need
> libbsd to get ethernet?
> 
> Thanks,
> Alan

Hello Alan,

I recommend to use the FreeBSD device trees. libbsd is FreeBSD based and
therefore works best with them. Normally I would suggest to use the
version matching the FreeBSD commit used in libbsd. But unfortunately in
the last commit that doesn't seem to work. Vijay had some problems with
it and noted that the version from FreeBSD commit
19a6ceb89dbacf74697d493e48c388767126d418 works fine.

Regarding Ethernet support: As far as I know there is no support for the
legacy stack. But the one in libbsd worked fine the last time I tested
it (which was when I ported it). If you really want to use the legacy
stack please note that it is still an IPv4 only one and therefore it is
quite limited nowadays.

Best regards

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

Device Tree Blob for Beaglebone Black?

[Alan Cudmore]

I have been trying to bring up RTEMS with rtems-libbsd on the
beaglebone black (latest master).

I can run the regular RTEMS samples on the board, and a couple of the
rtems-libbsd testsuite examples run as well.

The samples such as ping01 and usb01 get a fatal exception in the
function fdt_ro_probe_ , leading me to believe that maybe I am not
using the correct device tree blob.

I'm using the instructions here:
https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst

And I have am loading am335x-boneblack.dtb that I copied from a linux
u-boot build. The instructions talk about getting the one from the
FreeBSD repository, but there are many other files included in that
dts source.

What dtb is normally used for the Beaglebone black RTEMS libbsd testing?

Is the dtb needed for the non-libbsd BSP?

Also, is the ethernet supported on the RTEMS beagle BSP, or do I need
libbsd to get ethernet?

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