Re: Device Tree Blob for Beaglebone Black?

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

Re: Device Tree Blob for Beaglebone Black?

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

Re: Device Tree Blob for Beaglebone Black?

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

Re: Device Tree Blob for Beaglebone Black?

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

Re: Device Tree Blob for Beaglebone Black?

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.

Re: Device Tree Blob for Beaglebone Black?

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

Re: Device Tree Blob for Beaglebone Black?

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

Re: Device Tree Blob for Beaglebone Black?

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

Re: Device Tree Blob for Beaglebone Black?

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

Re: Device Tree Blob for Beaglebone Black?

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:

Re: Device Tree Blob for Beaglebone Black?

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

Re: Device Tree Blob for Beaglebone Black?

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

Re: Device Tree Blob for Beaglebone Black?

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

Re: Device Tree Blob for Beaglebone Black?

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

Re: Device Tree Blob for Beaglebone Black?

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

Re: Device Tree Blob for Beaglebone Black?

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

Re: Device Tree Blob for Beaglebone Black?

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,

Re: Device Tree Blob for Beaglebone Black?

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

Re: Device Tree Blob for Beaglebone Black?

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

Re: Device Tree Blob for Beaglebone Black?

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

Re: Device Tree Blob for Beaglebone Black?

> 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

Re: Device Tree Blob for Beaglebone Black?

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

Re: Device Tree Blob for Beaglebone Black?

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:

Re: Device Tree Blob for Beaglebone Black?

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

Re: Device Tree Blob for Beaglebone Black?

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

Re: Device Tree Blob for Beaglebone Black?

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

Re: Device Tree Blob for Beaglebone Black?

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

Re: Device Tree Blob for Beaglebone Black?

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

Re: Device Tree Blob for Beaglebone Black?

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

Re: Device Tree Blob for Beaglebone Black?

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

Re: Device Tree Blob for Beaglebone Black?

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