GSoC 2020: Implemented FreeBSD structures in RTEMS

Hello, As part of my GSoC project: Beagle BSP: Add FDT based initialization I had to import a few drivers from libBSD to RTEMS this eventually led to importing their dependencies and other simple drivers. While porting these drivers we saw a huge amount of code being duplicated or I must say a

Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd

On Wed, Jul 8, 2020 at 2:48 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 08/07/2020 11:11, Niteesh G. S. wrote: > > > Could you please use the 5-freebsd-12 branch with the default > > build set. > > This is what I use normally. &

Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd

On Wed, Jul 8, 2020 at 2:00 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 29/06/2020 21:39, Niteesh G. S. wrote: > > > Hello, > > > > I tried compiling RTEMS-libBSD with RTEMS6 toolchain and the new build > > system > > but failed

Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd

On Wed, Jul 8, 2020 at 12:11 PM Christian Mauderer < christian.maude...@embedded-brains.de> wrote: > On 08/07/2020 08:35, Niteesh G. S. wrote: > > On Wed, Jul 8, 2020 at 11:52 AM Christian Mauderer > > > <mailto:christian.maude...@embedded-brains.de>> wrote

Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd

On Wed, Jul 8, 2020 at 11:52 AM Christian Mauderer < christian.maude...@embedded-brains.de> wrote: > On 08/07/2020 08:13, Sebastian Huber wrote: > > On 08/07/2020 08:10, Niteesh G. S. wrote: > > > >> On Tue, Jul 7, 2020 at 10:42 AM Sebastian Huber > >&g

Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd

Hello, On Tue, Jul 7, 2020 at 10:42 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello, > > the problem is that the new build system doesn't export optimization > flags such as -Wl,--gc-sections. The libbsd build should enable this > linker option unconditionally. > Thank

Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd

I'll have to try to start with a clean > build again tomorrow to see whether I maybe broke something. My prefix > isn't in the best shape after trying multiple branches and installs. > > Best regards > > Christian > > On 06/07/2020 20:09, Niteesh G. S. wrote: > > Hello all

Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd

Hello all, This thread has lost activity for quite some time. Can someone please provide a solution to this. This is blocking me from testing my patches with libbsd. Thanks, Niteesh. On Tue, Jun 30, 2020 at 1:12 AM Christian Mauderer wrote: > Hello, > > On 29/06/2020 21:39, Nit

GSoC 2020: OFW patch needs review

Hello, As per the feedback from my mentor, I am posting all my patches created so far to the mailing list. My patches are based on the new build system so my mentor suggested posting a link to my GitHub repo instead of posting the patches itself since they cannot be directly applied to the master

Re: New Build System: Can't include headers

Hello, This is a follow-up message since activity on this thread has stopped a couple of days ago. Thanks, Niteesh. On Tue, Jun 30, 2020 at 1:49 AM Niteesh G. S. wrote: > On Mon, Jun 29, 2020 at 8:59 PM Gedare Bloom wrote: > >> On Mon, Jun 29, 2020 at 9:14 AM Niteesh G.

Re: New Build System: Can't include headers

On Mon, Jun 29, 2020 at 8:59 PM Gedare Bloom wrote: > On Mon, Jun 29, 2020 at 9:14 AM Niteesh G. S. > wrote: > > > > Hello, > > > > https://lists.rtems.org/pipermail/devel/2020-June/060145.html > > As agreed on the above mail I have started to create patch

NEW BUILD SYSTEM: Cannot build rtems-libbsd

Hello, I tried compiling RTEMS-libBSD with RTEMS6 toolchain and the new build system but failed. I get errors when compiling RTEMS-libBSD The new build system is pulled from Sebastian's branch HEAD: e4c193ddc163d6adb1b003254af9cc6b5d174a6f RTEMS was configured with the following options: 1)

Re: New Build System: Can't include headers

Hello, On Mon, Jun 29, 2020 at 8:47 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello, > > your header files are in the wrong place. Architecture and BSP > independent header files which need to be installed should be under > "cpukit/include". For libfreebsd, this means we

New Build System: Can't include headers

Hello, https://lists.rtems.org/pipermail/devel/2020-June/060145.html As agreed on the above mail I have started to create patches based on the new build system. But I encountered a few issues related to the inclusion of header files. I am using one of my patches as an example to illustrate the

NEW BUILD SYSTEM: Error on waf install

Hello, The new build system pulled from https://git.rtems.org/sebh/rtems.git/log/?h=build HEAD: 3957793dec1480a24d8a8902202015c47e153e97 The new build system throws the following error while issuing

GSoC 2020: Weekly Update (Meeting #3)

Hello, Weekly Process Report. Project: Beagle BSP: Add FDT based initialization DATE: June 17, 2020 Current work: -- Import the pinmux driver from FreeBSD to RTEMS. Test the driver with libBSD. Implement simple FreeBSD structures into RTEMS to make porting easier. Progress:

Re: [PATCH RTEMS v2 5/6] libfreebsd: Port OFW to RTEMS

On Sun, Jun 14, 2020 at 5:48 PM Christian Mauderer wrote: > > > On 14/06/2020 13:37, Vijay Kumar Banerjee wrote: > > On Sat, Jun 13, 2020 at 11:44 PM Niteesh G. S. > wrote: > >> > >> > >> > >> On Sat, Jun 13, 2020 at 6:30 PM Vijay Kumar Ba

Re: [PATCH RTEMS v2 5/6] libfreebsd: Port OFW to RTEMS

On Sat, Jun 13, 2020 at 6:30 PM Vijay Kumar Banerjee wrote: > On Thu, Jun 11, 2020 at 5:53 PM G S Niteesh Babu > wrote: > > > > The following files have been ported to RTEMS > > 1) openfirm.h > > 2) openfirm.c > > 3) ofw_fdt.c > > --- > > cpukit/libfreebsd/dev/ofw/ofw_fdt.c | 146

Re: [PATCH 4/5] libfreebsd: Port OFW to RTEMS

On Sat, Jun 6, 2020 at 5:40 PM Christian Mauderer wrote: > On 04/06/2020 19:43, G S Niteesh Babu wrote: > > The following files have been ported to RTEMS > > 1) openfirm.h > > 2) openfirm.c > > 3) ofw_fdt.c > > --- > > cpukit/libfreebsd/dev/ofw/ofw_fdt.c | 117 ++- > >

Re: [PATCH 3/5] libfreebsd: FreeBSD porting helper header

On Sat, Jun 6, 2020 at 5:27 PM Christian Mauderer wrote: > On 04/06/2020 19:43, G S Niteesh Babu wrote: > > This file serve the purpose as rtems-bsd-kernel-space.h in the > > rtems-libbsd. > > This file is intended to be included in every source file that > > is to imported from FreeBSD. This is

Re: [PATCH 2/5] libfreebsd: Added ofw_if.h

Hello Christian, I fixed this. Thanks, Niteesh. On Sat, Jun 6, 2020 at 5:20 PM Christian Mauderer wrote: > Some style comments: > > On 04/06/2020 19:43, G S Niteesh Babu wrote: > > This file is the RTEMS implementation of ofw_if.h in FreeBSD. The > > ofw_if.h in FreeBSD is an autogenerated

Re: [PATCH 1/5] bsps/shared/freebsd: Import OFW files from FreeBSD.

I have a few questions which I would like to resolve before sending in the patch. 1) Will the definitions for the wrapper functions go under cpukit/libtest like it is currently done for printf, puts, etc.? And also why are we wrapping printf and puts? Is it to provide definitions for BSPs that

Re: [PATCH 1/5] bsps/shared/freebsd: Import OFW files from FreeBSD.

Hello, This email is a reminder since this thread has lost activity. Thanks, Niteesh. On Tue, Jun 2, 2020 at 12:25 AM Niteesh G. S. wrote: > On Fri, May 29, 2020 at 6:49 PM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> On 29/05/2020 12:41, Niteesh G.

Re: [PATCH 1/5] bsps/shared/freebsd: Import OFW files from FreeBSD.

On Fri, May 29, 2020 at 6:49 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 29/05/2020 12:41, Niteesh G. S. wrote: > Hello Sebastian, > > Hello, > > > > On Fri, May 29, 2020 at 12:52 PM Sebastian Huber > > > <mailto:

Re: [PATCH 1/5] bsps/shared/freebsd: Import OFW files from FreeBSD.

Hello, On Fri, May 29, 2020 at 12:52 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello, > > since this code is not BSP-specific it should be located in cpukit. How > many FreeBSD source files do you intend to import within this project? > This code depends on a bsp that

Re: GSoC: Porting OFW to RTEMS

Hello Christian, On Thu, May 28, 2020 at 8:12 PM Christian Mauderer < christian.maude...@embedded-brains.de> wrote: > Hello Niteesh, > > On 28/05/2020 16:34, Niteesh G. S. wrote: > > > > > > On Wed, May 27, 2020 at 11:25 PM Christian Mauderer >

Re: GSoC: Porting OFW to RTEMS

On Wed, May 27, 2020 at 11:25 PM Christian Mauderer wrote: > On 27/05/2020 19:32, Niteesh G. S. wrote: > > > > > > On Wed, May 27, 2020 at 12:04 AM Christian Mauderer > <mailto:o...@c-mauderer.de>> wrote: > > > > Hello Niteesh, > > &g

Re: GSoC: Porting OFW to RTEMS

On Wed, May 27, 2020 at 12:04 AM Christian Mauderer wrote: > Hello Niteesh, > > On 26/05/2020 19:56, Christian Mauderer wrote: > > Hello Niteesh, > > > > On 25/05/2020 11:20, Niteesh G. S. wrote: > >> Hello, > >> > >> I have completed the po

Re: GSoC: Porting OFW to RTEMS

On Tue, May 26, 2020 at 11:26 PM Christian Mauderer wrote: > Hello Niteesh, > > On 25/05/2020 11:20, Niteesh G. S. wrote: > > Hello, > > > > I have completed the porting of the OFW code from FreeBSD to RTEMS. > > I do acknowledge the fact that we haven't dec

GSoC: Porting OFW to RTEMS

Hello, I have completed the porting of the OFW code from FreeBSD to RTEMS. I do acknowledge the fact that we haven't decided on the directory for files to be placed in. The previous conversation had stopped quite a while ago. Christian suggested I work on the patch since that would also start the

Re: GSoC: RTEMS directory for FreeBSD imports

On Thu, May 14, 2020 at 4:30 PM Christian Mauderer < christian.maude...@embedded-brains.de> wrote: > On 13/05/2020 20:15, Niteesh G. S. wrote: > > Hello, > > > > This mail is to regain attention for this topic and also to discuss a > > few details

Re: GSoC: RTEMS directory for FreeBSD imports

at 12:48 PM Christian Mauderer < christian.maude...@embedded-brains.de> wrote: > On 11/05/2020 09:11, Chris Johns wrote: > > On 11/5/20 4:55 pm, Christian Mauderer wrote: > >> On 11/05/2020 06:57, Chris Johns wrote: > >>> > >>> > >>> On 11/5/

Re: GSoC: RTEMS directory for FreeBSD imports

On Mon, May 11, 2020 at 4:34 AM Chris Johns wrote: > On 10/5/20 6:17 pm, Niteesh G. S. wrote: > > This thread is a continuation of "GSoC 2020: Implementation of OFW > > functions". > > > > A summary of points discussed in that thread is given below. >

GSoC: RTEMS directory for FreeBSD imports

This thread is a continuation of "GSoC 2020: Implementation of OFW functions". A summary of points discussed in that thread is given below. Below is a short description of my GSoC project. For more information please refer to the wiki.

Re: GSoC 2020: Implementation of OFW functions

On Sat, May 9, 2020 at 11:56 AM Christian Mauderer wrote: > > > On 08/05/2020 23:05, Gedare Bloom wrote: > > On Fri, May 8, 2020 at 9:34 AM Christian Mauderer > wrote: > >> > >> > >> On 08/05/2020 17:26, Niteesh G. S. wrote: > >&g

Re: GSoC 2020: Implementation of OFW functions

On Fri, May 8, 2020 at 11:43 AM Christian Mauderer < christian.maude...@embedded-brains.de> wrote: > > On 07/05/2020 17:19, Niteesh G. S. wrote: > > On Thu, May 7, 2020 at 4:07 PM Sebastian Huber > > > <mailto:sebastian.hu...@embedded-brains.de>> wrote: > &

Re: GSoC 2020: Implementation of OFW functions

On Thu, May 7, 2020 at 4:07 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 07/05/2020 12:28, Niteesh G. S. wrote: > > > On Thu, May 7, 2020 at 1:21 PM Sebastian Huber > > > <mailto:sebastian.hu...@embedded-brains.de>> wrote: > >

Re: GSoC 2020: Implementation of OFW functions

On Thu, May 7, 2020 at 1:21 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 07/05/2020 09:35, Niteesh G. S. wrote: > > > This is what I was trying to convey in one of the previous mails. > > https://lists.rtems.org/pipermail/devel/2020-May/059717.html

Re: GSoC 2020: Implementation of OFW functions

On Thu, May 7, 2020 at 12:10 PM Christian Mauderer < christian.maude...@embedded-brains.de> wrote: > Hello Niteesh, > > On 07/05/2020 06:58, Niteesh G. S. wrote: > [...] > > Is there any chance that we will be working with the new build system > > for

Re: GSoC 2020: Implementation of OFW functions

On Thu, May 7, 2020 at 10:44 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 07/05/2020 06:58, Niteesh G. S. wrote: > > > I couldn't go through it yesterday. Today I started off with building > > rtems6 > > toolchain for arm using RSB but failed

Re: GSoC 2020: Implementation of OFW functions

On Wed, May 6, 2020 at 9:18 PM Christian Mauderer wrote: > On 06/05/2020 11:31, Niteesh G. S. wrote: > > On Wed, May 6, 2020 at 2:20 PM Christian Mauderer > > > <mailto:christian.maude...@embedded-brains.de>> wrote: > > > > Hello Niteesh, > > >

Re: GSoC 2020: Implementation of OFW functions

On Wed, May 6, 2020 at 2:20 PM Christian Mauderer < christian.maude...@embedded-brains.de> wrote: > Hello Niteesh, > > On 06/05/2020 10:42, Niteesh G. S. wrote: > > On Tue, May 5, 2020 at 11:46 PM Vijay Kumar Banerjee > <mailto:vi...@rtems.org>> wrote: > &

Re: GSoC 2020: Implementation of OFW functions

On Tue, May 5, 2020 at 11:46 PM Vijay Kumar Banerjee wrote: > > > On Tue, May 5, 2020 at 10:40 PM Niteesh G. S. > wrote: > >> This is thread is about implementing OFW functions in RTEMS as part >> of my GSoC project. I would like to start off with this part since

Re: GSoC 2020: Implementation of OFW functions

On Tue, May 5, 2020 at 11:44 PM Christian Mauderer wrote: > Hello Niteesh, > > On 05/05/2020 19:10, Niteesh G. S. wrote: > > This is thread is about implementing OFW functions in RTEMS as part > > of my GSoC project. I would like to start off with this part since the >

Re: GSoC 2020: Implementation of OFW functions

also have the following doubts. What is ofw_cif used for? It is some kind of function pointer table? Does ofw_init initialize ofw_cif? Thanks, Niteesh. > > On Tue, May 5, 2020 at 12:20 PM Christian Mauderer > wrote: > > > > Hello Niteesh, > > > > On 05/05/2020 19:10,

GSoC 2020: Implementation of OFW functions

This is thread is about implementing OFW functions in RTEMS as part of my GSoC project. I would like to start off with this part since the refactoring work will somewhat depend on this. Implementing these functions into RTEMS will make porting drivers from FreeBSD to RTEMS easy. Currently, the

Re: [PATCH 0/2 rtems-release] Add script to branch repositories.

Thanks for pushing it. Thanks, Niteesh. On Sat, May 2, 2020 at 11:05 AM Chris Johns wrote: > Pushed. Many thanks for helping out with this task. > > Chris > > On 2/5/20 1:52 pm, G S Niteesh Babu wrote: > > The following patches add a script to rtems-release > > to automate branching of

Re: Release task request for help

. I > have pinged Amar to have a look. > > On 30/4/20 4:45 am, Niteesh G. S. wrote: > > Please have a look at this if you missed it previously. :) > > > > Thanks, > > Niteesh. > > > > On Tue, Apr 28, 2020 at 11:30 PM Niteesh G. S. > <mailto:niteesh..

Re: Release task request for help

/58ed0cb3fc1f33f12de8e550979371a51e322754 On Tue, Apr 28, 2020 at 3:51 PM Chris Johns wrote: > On 28/4/20 6:26 pm, Niteesh G. S. wrote: > > On Tue, Apr 28, 2020 at 8:10 AM Chris Johns > <mailto:chr...@rtems.org>> wrote: > > > > On 28/4/20 11:51 am, Niteesh G. S. wrote: >

Re: Release task request for help

On Tue, Apr 28, 2020 at 8:10 AM Chris Johns wrote: > On 28/4/20 11:51 am, Niteesh G. S. wrote: > > > https://github.com/gs-niteesh/rtems-release/commit/8666bcd66066512f91194660817cd42cbb8c76e9 > > If it is okay for you, then I will send the patch to the mailing list. > &g

Re: Release task request for help

https://github.com/gs-niteesh/rtems-release/commit/8666bcd66066512f91194660817cd42cbb8c76e9 If it is okay for you, then I will send the patch to the mailing list. On Tue, Apr 28, 2020 at 7:09 AM Chris Johns wrote: > On 28/4/20 11:30 am, Niteesh G. S. wrote: > > I have updated th

Re: Release task request for help

On Tue, Apr 28, 2020 at 6:40 AM Niteesh G. S. wrote: > The testing method I used had a flaw. Since I don't have access to > RTEMS server, I replaced the URL with GIthub and it seems that > github keeps references to old repos because of this I wasn't getting > an error due to the wro

Re: Release task request for help

The testing method I used had a flaw. Since I don't have access to RTEMS server, I replaced the URL with GIthub and it seems that github keeps references to old repos because of this I wasn't getting an error due to the wrong repo name. On Tue, Apr 28, 2020 at 6:38 AM Niteesh G. S. wrote

Re: Release task request for help

Sounds good. But what is the difference between an RTEMS-package and repo? Aren't they the same? On Tue, Apr 28, 2020 at 6:25 AM Chris Johns wrote: > On 28/4/20 10:50 am, Niteesh G. S. wrote: > > The rtems-release-defaults already contains a rtems-packages > > variable. Can I u

Re: Release task request for help

Hello Chris, On Mon, Apr 27, 2020 at 3:47 AM Chris Johns wrote: > Hi, > > Sorry about the delay getting back to you. I had to take our dog to vet > last Friday and then it was the weekend ... :) > That's okay :) > On 23/4/20 4:42 pm, Niteesh G. S. wrote: > > Hello Chris

Re: Release task request for help

Hello Chris, > Message: 4 > Date: Thu, 23 Apr 2020 14:35:12 +1000 > From: Chris Johns > To: RTEMS Devel > Subject: Release task request for help > Message-ID: <7976c497-cff1-7c73-f673-596dd831c...@rtems.org> > Content-Type: text/plain; charset=utf-8; format=flowed > > Hello, > > I need a

Re: [PATCH v3] bsp/beagle: Update console to new Termios API.

On Fri, Apr 10, 2020 at 9:18 PM Christian Mauderer wrote: > Hello Niteesh, > > sorry for the late review. It somehow slipped my attention. > > Although I'm generally OK with it, my suggestion would be to move it > after the release. It's a not strictly necessary change and therefore I > don't

Re: [PATCH v2] bsp/raspberrypi: Fix build warnings.

This patch has been unnoticed for a while. If the lack of testing is what is stopping from pushing it I am happy to test it on real hardware. But I can't come up with a good methodology for testing it. My initial thoughts were to generate a GPIO interrupt with no ISR. This would cause the default

Re: [PATCH] user/gsoc: GSoC Getting Started Instructions

, Mar 30, 2020 at 9:40 PM Gedare Bloom wrote: > On Sun, Mar 29, 2020 at 11:47 PM Sebastian Huber > wrote: > > > > On 28/03/2020 19:47, Niteesh G. S. wrote: > > > > We have an Installation chapter under the User manual > https://docs.rtems.org/branches/ma

Re: [PATCH 1/2] bsp/raspberrypi: Fix build warnings.

I have a sent v2. It uses PRIdrtems_vector_number as the specifier. Please have a look at it. https://lists.rtems.org/pipermail/devel/2020-March/058716.html Thank you, Niteesh On Sun, Mar 29, 2020 at 5:17 AM Gedare Bloom wrote: > On Sat, Mar 28, 2020 at 10:11 AM Joel Sherrill wrote: > > > >

Re: [PATCH] user/gsoc: GSoC Getting Started Instructions

and ask the students to refer to the quick-start chapter. Thank you, Niteesh. On Mon, Mar 23, 2020 at 8:29 PM Gedare Bloom wrote: > On Mon, Mar 23, 2020 at 3:35 AM Niteesh G. S. > wrote: > > > > On Mon, Mar 23, 2020 at 11:58 AM Sebastian Huber < > sebastian.hu...@e

Re: [PATCH 2/2] gpio/gpio-support: Fix build warnings.

On Sat, Mar 28, 2020 at 9:38 PM Joel Sherrill wrote: > We don't think you should assert or generate a fatal error after > initialization. This could cause an unknown, but safety critical, > application to fail. > > This same logic should be converted to a run-time error. > Should I just return

Re: [PATCH] user/gsoc: GSoC Getting Started Instructions

On Mon, Mar 23, 2020 at 11:58 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 23/03/2020 06:59, Niteesh G. S. wrote: > > From here on I would prefer references to the existing documentation >> with any GSoC details list here. I would prefer we avoid

Re: [PATCH] user/gsoc: GSoC Getting Started Instructions

On Mon, Mar 23, 2020 at 6:43 AM Chris Johns wrote: > On 2020-03-18 07:36, G S Niteesh Babu wrote: > > --- > > user/index.rst | 1 + > > user/start/gsoc.rst | 453 +++ > > user/start/index.rst | 1 + > > 3 files changed, 455 insertions(+) >

Re: [PATCH] user/gsoc: GSoC Getting Started Instructions

On Sun, Mar 22, 2020 at 7:42 PM Gedare Bloom wrote: > Hi Niteesh, > > Did you build the docs with this change > Yes, I did. Did you face any issues? I am sorry for typos and grammatical mistakes. I checked a couple of times but still missed them. > The rewrite is nice. I do have several

Re: Adding GDB BSPs to rtems-tester

:33 PM Joel Sherrill wrote: > > > On Sat, Mar 21, 2020 at 10:38 AM Niteesh G. S. > wrote: > >> Which architecture should I try then? Maybe powerpc or mips? If you have >> any >> of them already built can you please try them out? Building everything >> fr

Re: Adding GDB BSPs to rtems-tester

h G. S. > wrote: > > > > On Thu, Mar 19, 2020 at 11:43 PM Gedare Bloom wrote: > >> > >> On Thu, Mar 19, 2020 at 11:56 AM Niteesh G. S. > wrote: > >> > > >> > Hello, > >> > > >> > While looking for small task

Re: Adding GDB BSPs to rtems-tester

On Thu, Mar 19, 2020 at 11:43 PM Gedare Bloom wrote: > On Thu, Mar 19, 2020 at 11:56 AM Niteesh G. S. > wrote: > > > > Hello, > > > > While looking for small tasks to take up, Gedare mentioned about adding > GDB BSPs > > to rtems-tester. Can som

GSoC 2020 Proposal | Beagle BSP: Add a flattened device tree based initialization

Hello everyone, I have revised my proposal as per your suggestions. Please have a look again. https://docs.google.com/document/d/1V2RitYJOvWOvfow99hPUFB034iw4gb4eSfH8MixHnrk/edit?usp=sharing Thank you, Niteesh. ___ devel mailing list devel@rtems.org

Re: [PATCH rtems-docs] user/raspberrypi: Fix typo

Thanks for pushing it. -Niteesh. On Thu, Mar 19, 2020 at 11:47 AM Christian Mauderer < christian.maude...@embedded-brains.de> wrote: > Hello Niteesh, > > thanks for finding and fixing that. It's a very small patch and no one > objected in the last days. So I pushed it. > > Best regards > >

Re: RTEMS Docs: Adding GSoC Getting Started Instructions

On Tue, Mar 17, 2020 at 2:28 AM Gedare Bloom wrote: > On Mon, Mar 16, 2020 at 12:56 PM Niteesh G. S. > wrote: > > > > I am interested in taking up #3907. I'll mostly be copying and updating > the contents from the old wiki site. > > > > I have the following

RTEMS Docs: Adding GSoC Getting Started Instructions

I am interested in taking up #3907 . I'll mostly be copying and updating the contents from the old wiki site. I have the following plan in mind. I'll start working on it if you are happy with it. Add a new gsoc section in the user manual

Re: [PATCH] bsp/beagle: Update console to new Termios device API.

Please discard this patch. This patch has been sent without testing. Thank you. Niteesh ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

Re: Testing BSP package using beaglebone black

Hii, Can you just check if you have the ARM toolchain installed? The guide that you mentioned is for RTEMS 4.11 and maybe things changed with RTEMS 5. If you don't have it installed you can do in a similar way as you did for sparc $ ../source-builder/sb-set-builder --source-only-download

Re: [PATCH] RTEMS Docs: Fix search field

Hii On Sun, 23 Feb, 2020, 2:07 AM Chris Johns, wrote: > Hi > > How did you test this patch? > As I already told the search field works without this patch in sphinx versions newer than v1.6.4. This is a bug with all version of sphinx between v1.6.4 and v.1.5.0 So to reproduce this bug in my

Re: [PATCH] RTEMS Docs: Fix search field

We could also fix this issue by updating sphinx to a newer version. But this patch will not break anything even if updated to the newer version. On Sat, Feb 22, 2020 at 5:35 PM G S Niteesh Babu wrote: > This patch fixes the search field which previously was not working > due to this commit

Re: Loading RTEMS applications from u-boot on Raspberry Pi 2

; What is the relation between both, if any? > That's just the syntax for bootm. bootm ${kernel_addr} - ${fdt_addr} But, bootm ${kernel_addr} ${fdt_addr} should also work I guess but I am not sure. Can you try that and please let me know? Thank you, Niteesh. Regards, > Cláudio > > &

Re: Loading RTEMS applications from u-boot on Raspberry Pi 2

Hii, Regarding loading RTEMS images using U-Boot. It is necessary that you provide a DTB file. So, your commands should be $ mkimage -A arm -O linux -T kernel -a 0x20 -e 0x200080 -d kernel.img -C none rtems.img Can you please let me know if -O rtems works for you. I have tried using it but

<    1   2