Re: [PATCH] bsps/raspberrypi/console: Fix default console device

t; I'm pretty busy right now, but I'll see if I can continue testing in > > the next few days. I want to try loading from u-boot next. > > > > Alan > > > > > > On Thu, May 20, 2021 at 12:52 AM Niteesh G. S. > wrote: > > > > > > ping. > &

Re: [PATCH] bsps/raspberrypi/console: Fix default console device

ping. On Tue, May 11, 2021 at 1:09 AM Niteesh G. S. wrote: > Hello Gedare, > > On Mon, May 10, 2021 at 8:57 PM Gedare Bloom wrote: > >> On Thu, May 6, 2021 at 8:49 AM Niteesh G. S. >> wrote: >> > >> > Hi Alan, >> > >> > On Thu, M

Re: [PATCH] bsps/raspberrypi/console: Fix default console device

Hello Gedare, On Mon, May 10, 2021 at 8:57 PM Gedare Bloom wrote: > On Thu, May 6, 2021 at 8:49 AM Niteesh G. S. wrote: > > > > Hi Alan, > > > > On Thu, May 6, 2021 at 6:12 PM Alan Cudmore > wrote: > >> > >> Hi Niteesh, > >> >

Re: [PATCH] bsps/raspberrypi/console: Fix default console device

0 rtems.img bootm 0x20 - 0x1000 Thanks, Niteesh > Thanks, > Alan > > On Thu, May 6, 2021 at 10:48 AM Niteesh G. S. > wrote: > > > > Hi Alan, > > > > On Thu, May 6, 2021 at 6:12 PM Alan Cudmore > wrote: > >> > >> Hi Niteesh, >

Re: [PATCH v3] bsps/shared/ofw: Fix coverity defects

On Fri, May 7, 2021 at 4:16 AM Vijay Kumar Banerjee wrote: > On Thu, May 6, 2021 at 10:57 AM Gedare Bloom wrote: > > > > ok, Vijay please push > > Pushed. Thanks. > Thanks for pushing. > > > > > On Thu, May 6, 2021 at 2:06 AM G S Niteesh Babu > wrote: > > > > > > This patch adds asserts to

Re: [PATCH] bsps/raspberrypi/console: Fix default console device

w from RTEMS 5. Thanks, Niteesh. > Thanks, > > Alan > > > > *From: *Niteesh G. S. > *Sent: *Thursday, May 6, 2021 4:29 AM > *To: *Joel Sherrill ; Christian Mauderer > > *Cc: *rtems-de...@rtems.org > *Subject: *Re: [PATCH] bsps/raspberrypi/console: Fix

Re: [PATCH] bsps/raspberrypi/console: Fix default console device

ping. On Sat, May 1, 2021 at 9:47 PM Niteesh G. S. wrote: > On Sat, May 1, 2021 at 8:31 PM Joel Sherrill wrote: > >> >> >> On Sat, May 1, 2021, 8:53 AM Niteesh G. S. wrote: >> >>> Just to provide more context, >>> When the CONFIGURE

Re: [PATCH v2] bsps/shared/ofw: Fix coverity defects

lib 436e475) > executing thread ID: 0x089010001 > executing thread name: IDLE > U-Boot SPL 2018.09-2-g0b54a51eee (Sep 10 2018 - 19:41:39 -0500) > Trying to boot from MMC2 > Loading Environment from EXT4... > ** Unable to use mmc 0:1 for loading the env ** > > ``` > > B

Re: [PATCH v2] bsps/shared/ofw: Fix coverity defects

On Mon, May 3, 2021 at 11:23 PM Gedare Bloom wrote: > Hi Niteesh, > > This looks good to me. What/how did you test it? > I tested it using the ofw01 test https://git.rtems.org/rtems/tree/testsuites/libtests/ofw01/init.c and read EEPROM using i2c. > Gedare > > On Sat, May 1, 2021 at 6:31 AM G S

Re: [PATCH] bsps/raspberrypi/console: Fix default console device

On Sat, May 1, 2021 at 8:31 PM Joel Sherrill wrote: > > > On Sat, May 1, 2021, 8:53 AM Niteesh G. S. wrote: > >> Just to provide more context, >> When the CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER option is used >> and no --console option is provided, the co

Re: [PATCH] bsps/raspberrypi/console: Fix default console device

Just to provide more context, When the CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER option is used and no --console option is provided, the console driver defaults to PL011. In raspberry pi 3 and other models whose primary UART is not PL011, we get no output. This patch fixes that by linking the

Re: [PATCH] bsps/shared/ofw: Fix coverity defects

On Thu, Apr 29, 2021 at 9:25 PM Gedare Bloom wrote: > On Wed, Apr 28, 2021 at 9:04 PM Niteesh G. S. > wrote: > > > > > > > > On Thu, Apr 29, 2021 at 12:50 AM Gedare Bloom wrote: > >> > >> On Wed, Apr 28, 2021 at 11:30 AM G S Niteesh Babu >

Re: [PATCH] bsps/shared/ofw: Fix coverity defects

On Thu, Apr 29, 2021 at 12:50 AM Gedare Bloom wrote: > On Wed, Apr 28, 2021 at 11:30 AM G S Niteesh Babu > wrote: > > > > This patch adds asserts to fix coverity defects > > 1) CID 1474437 (Out-of-bounds access) > > 2) CID 1474436 (Out-of-bounds access) > > > > From manual inspection, out of

Re: [PATCH RTEMS v2 0/1] bsp/beagle: Refactored i2c driver and Updated

Hello Christian, On Thu, Apr 22, 2021 at 10:24 PM Christian Mauderer wrote: > Hello Niteesh, > > thanks for the reminder and the patches. I pushed them. > Thanks for pushing them Thank you, Niteesh. > > Best regards > > Christian > > On 22/04/2021 05:54,

Re: [PATCH RTEMS v2 0/1] bsp/beagle: Refactored i2c driver and Updated

dnesday if I > didn't push it by then. > > Best regards > > Christian > > On 18/04/2021 17:19, Niteesh G. S. wrote: > > Hello Christian, > > > > On Sun, Apr 18, 2021 at 4:54 PM Christian Mauderer > <mailto:o...@c-mauderer.de>> wrote: > > &

Re: [PATCH libBSD] iicbus/rtems-i2c.c: Add rtems, path as an additional bus path

Hello Christian, On Mon, Apr 19, 2021 at 10:18 PM Christian Mauderer wrote: > Hello Niteesh, > > On 19/04/2021 18:45, Niteesh G. S. wrote: > > > > > > On Mon, Apr 19, 2021 at 9:55 PM Gedare Bloom > <mailto:ged...@rtems.org>> wrote: > > > >

Re: [PATCH libBSD] iicbus/rtems-i2c.c: Add rtems, path as an additional bus path

On Mon, Apr 19, 2021 at 9:55 PM Gedare Bloom wrote: > On Sun, Apr 18, 2021 at 9:12 AM G S Niteesh Babu > wrote: > > > > Adds "rtems,path" as an additional bus path for the i2c driver. > > Previously the bus path was provided in "rtems,i2c-path" property > > only. > > --- > >

Re: [PATCH RTEMS v2 0/1] bsp/beagle: Refactored i2c driver and Updated

solution. Patches that are pending are: 1) https://lists.rtems.org/pipermail/devel/2021-April/066458.html 2) https://lists.rtems.org/pipermail/devel/2021-April/066460.html 3) https://lists.rtems.org/pipermail/devel/2021-April/066629.html Thanks, Niteesh. > Best regards >

Re: [PATCH RTEMS v2 0/1] bsp/beagle: Refactored i2c driver and Updated

ping. On Sun, Apr 11, 2021 at 12:45 AM G S Niteesh Babu wrote: > The following two patches update the Beagle BSP i2c driver to use > device tree based initialization and the documentation related to > it. > > G S Niteesh Babu (1): > bsps/beagle: Refactored i2c driver > >

Re: [PATCH RTEMS] bsps/beagle: Refactored i2c driver

Hello Vijay, On Sun, Mar 28, 2021 at 1:42 AM Vijay Kumar Banerjee wrote: > Hi Niteesh, > > Thanks for the patch. I have some questions below. > > On Mon, Mar 22, 2021 at 11:48 AM G S Niteesh Babu > wrote: > > > > Refactored the i2c driver to parse register values from the device > > tree

Re: [PATCH RTEMS] bsps/beagle: Refactored i2c driver

Hii, I have tested this patch by reading out the values from the EEPROM in i2c-0 and also reading out data from a sensor connected to i2c-1. For reading data from the sensor, I used RTEMS Shell with i2cget and i2cset. All this was done on a PocketBeagle. Thanks, Niteesh. On Mon, Mar 22, 2021 at

Re: [PATCH] rtems-fdt/rtems-fdt.c: Fix bug in loop termination

istian > > On 21/03/2021 08:04, Niteesh G. S. wrote: > > > > > > On Sat, Mar 20, 2021 at 11:39 AM Gedare Bloom > <mailto:ged...@rtems.org>> wrote: > > > > This looks good to me. Is the bug also on 5? If so, a ticket should > be > >

Re: [PATCH] rtems-fdt/rtems-fdt.c: Fix bug in loop termination

On Sat, Mar 20, 2021 at 11:39 AM Gedare Bloom wrote: > This looks good to me. Is the bug also on 5? If so, a ticket should be > opened and a patch filed for 5.2. > This bug is also present in 5. I have filed a ticket for this https://devel.rtems.org/ticket/4350 > If someone cares to push this

Re: [PATCH 2/5] rtems-fdt.c: Fix Resource leak (CID #1437645)

On Thu, Mar 18, 2021 at 1:01 AM Chris Johns wrote: > I do not know. Maybe ask or post a patch? > I have sent a patch please take a look at it https://lists.rtems.org/pipermail/devel/2021-March/065610.html > > On 18 Mar 2021, at 2:14 am, Niteesh G. S. wrote: > >  > > &

Re: [PATCH 2/5] rtems-fdt.c: Fix Resource leak (CID #1437645)

On Tue, 16 Mar 2021, 1:37 am Gedare Bloom, wrote: > This one looks ok to me, Niteesh? > +1 The below question is not related to this patch. Out of interest, I started going through the code and I am a bit confused in the following statement

Re: [PATCH 4/4] bsp/beagle: Ported Beagle pinmux driver to RTEMS

Hello, I tested this patch by removing the pinmux initialization code from the Beagle I2C driver and letting this driver do the initialization. I then used the I2C driver to read the EEPROM in the pocket beagle using the I2C driver. The initialization of the pinmux settings was also confirmed

Re: [PATCH v2 0/4] bsps/shared/ofw: Bug and Coverity defect fixes

Hello, Thank's to both of you for reviewing and pushing the patches :) On Tue, Feb 9, 2021 at 2:02 AM Joel Sherrill wrote: > > > On Mon, Feb 8, 2021, 2:27 PM Christian Mauderer wrote: > >> Hello Gedare and Niteesh, >> >> the patches look fine. I pushed them. >> >> @Niteesh: Thanks for

Re: [PATCH 2/4] bsps/shared/ofw: Use memcpy instead of strncpy

On Fri, Feb 5, 2021 at 11:52 PM Gedare Bloom wrote: > > > On Fri, Feb 5, 2021 at 10:41 AM G S Niteesh Babu > wrote: > >> Changed rtems_ofw_get_prop to use memcpy instead of strncpy >> --- >> bsps/shared/ofw/ofw.c | 10 +- >> 1 file changed, 9 insertions(+), 1 deletion(-) >> >> diff

Re: [PATCH 2/4] bsps/shared/ofw: Use memcpy instead of strncpy

Hello Christian, On Sat, Feb 6, 2021 at 2:33 AM Christian Mauderer wrote: > On 05/02/2021 19:22, Gedare Bloom wrote: > > > > > > On Fri, Feb 5, 2021 at 10:41 AM G S Niteesh Babu > > wrote: > > > > Changed rtems_ofw_get_prop to use memcpy instead of strncpy > >

Re: [PATCH 3/4] bsps/shared/ofw: Make rtems_ofw_get_effective_phandle iterative

Hello Gedare, On Fri, Feb 5, 2021 at 11:53 PM Gedare Bloom wrote: > > > On Fri, Feb 5, 2021 at 10:41 AM G S Niteesh Babu > wrote: > >> Refactored recursive rtems_ofw_get_effective_phandle into a >> iterative function. >> --- >> bsps/shared/ofw/ofw.c | 9 + >> 1 file changed, 5

Re: [PATCH v3] bsps/shared/ofw: Fix coverity reported defects

On Fri, Feb 5, 2021 at 12:22 AM Christian Mauderer wrote: > > > On 04/02/2021 17:34, Gedare Bloom wrote: > > > > > > On Thu, Feb 4, 2021 at 1:58 AM Niteesh G. S. > <mailto:niteesh...@gmail.com>> wrote: > > > > > > > >

Re: [PATCH v3] bsps/shared/ofw: Fix coverity reported defects

On Thu, Feb 4, 2021 at 1:21 AM Gedare Bloom wrote: > > > On Wed, Feb 3, 2021 at 2:48 AM G S Niteesh Babu > wrote: > >> Fixed use after free and null pointer dereference defects >> >> FIXES: >> 1) CID 1472601 (NULL_RETURNS) >> 2) CID 1472600 (USE_AFTER_FREE) >> 3) CID 1472599 (USE_AFTER_FREE) >>

Re: [PATCH docs] user: remove old build system cmd

On Wed, Feb 3, 2021 at 11:13 PM Joel Sherrill wrote: > Was there a mkdir b-erc32 near there in those instructions? > No. All references to the build system in the GSoC section refer to the new build system Though there is an unnecessary instruction to create a dir in the manual BSP build section

Re: [PATCH v3] bsps/shared/ofw: Fix coverity reported defects

On Wed, Feb 3, 2021 at 11:05 PM Gedare Bloom wrote: > Is this second patch ok to check? > Yes, please go through this patch. Again adding a link to the patch to avoid confusion https://lists.rtems.org/pipermail/devel/2021-February/064203.html Thanks, Niteesh. > On Wed, Feb 3, 2021 at 2:48 AM

Re: Unable to use make command to build "Hello world" Program

Hello, > Actually I followed this document > > https://docs.rtems.org/branches/master/user/start/bsp-build.html#quickstartbspbuild-manual > to > build bsp manually > as mentioned in the "GSoc getting started" blog. > > Also yes when I run "./waf" command "Waf: Leaving directory >

Re: [PATCH v2] bsps/shared/ofw: Fix coverity reported defects

Hello, Please ignore this patch. Thanks, Niteesh. On Wed, Feb 3, 2021 at 3:14 PM G S Niteesh Babu wrote: > Fixed use after free and null pointer dereference defects > > FIXES: > 1) CID 1472601 (NULL_RETURNS) > 2) CID 1472600 (USE_AFTER_FREE) > 3) CID 1472599 (USE_AFTER_FREE) > 4) CID 1472598

Re: [PATCH] bsps/shared/ofw: Fix coverity reported defects

Hello Christian, On Fri, Jan 29, 2021 at 1:47 PM Christian MAUDERER < christian.maude...@embedded-brains.de> wrote: > Hello Niteesh, > > Am 29.01.21 um 07:33 schrieb Niteesh G. S.: > > Hello, > > > > https://lists.rtems.org/pipermail/devel/2021-January/064115.

Re: [patch libBSD] dev/ofw: Use RTEMS OFW FDT implementation

Hello Christian, On Thu, Jan 28, 2021 at 1:15 PM Christian MAUDERER < christian.maude...@embedded-brains.de> wrote: > Am 28.01.21 um 06:28 schrieb Chris Johns: > > On 28/1/21 4:12 am, Niteesh G. S. wrote: > >> Hello Christian, > >> > >> On Wed,

Re: [PATCH] bsps/shared/ofw: Fix coverity reported defects

Hello, https://lists.rtems.org/pipermail/devel/2021-January/064115.html I have fixed defects reported in the above thread except CID 1472595, 1472597 (ARRAY_VS_SINGLETON) Along with the buffer we also take the size of the buffer this makes sure that we don't read more than the buffer capacity.

Re: devel Digest, Vol 110, Issue 38

approach? On Thu, Jan 28, 2021 at 11:10 AM Chris Johns wrote: > On 28/1/21 4:25 am, Niteesh G. S. wrote: > > Date: Fri, 22 Jan 2021 04:28:37 +1100 > > From: Chris Johns mailto:chr...@rtems.org>> > > To: devel@rtems.org <mailto:devel@rtems.org> > >

Re: devel Digest, Vol 110, Issue 38

> > Date: Fri, 22 Jan 2021 04:28:37 +1100 > From: Chris Johns > To: devel@rtems.org > Subject: Re: [patch libBSD] dev/ofw: Use RTEMS OFW FDT implementation > Message-ID: > Content-Type: text/plain; charset=utf-8 > > On 20/1/21 7:31 pm, G S Niteesh Babu wrote: > > This commit modifies the OFW

Re: [patch libBSD] dev/ofw: Use RTEMS OFW FDT implementation

er received that mail, maybe Chris forgot to add me to the CC list. I'll answer his question in that thread. Thanks, Niteesh. > > Best regards > > Christian > > Am 27.01.21 um 11:14 schrieb Niteesh G. S.: > > ping. > > > > > > On Wed, Jan 20, 2021 at 2

Re: [patch libBSD] dev/ofw: Use RTEMS OFW FDT implementation

ping. On Wed, Jan 20, 2021 at 2:01 PM G S Niteesh Babu wrote: > This commit modifies the OFW interface to the RTEMS FDT > implementation instead of the default FreeBSD. > --- > freebsd/sys/dev/ofw/openfirm.c| 2 ++ > freebsd/sys/dev/ofw/openfirm.h| 9

Re: [PATCH] Implement FreeBSD helper structures

Hello Sebastian, On Wed, Jan 20, 2021 at 10:47 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello Niteesh, > > On 19/01/2021 17:20, G S Niteesh Babu wrote: > > The following structures and functions have been implemented to > > make porting of driver from FreeBSD easier. >

Re: [PATCH] Implement FreeBSD helper structures

Hello Gedare, On Wed, Jan 20, 2021 at 4:32 AM Gedare Bloom wrote: > Does this have a ticket? > It doesn't have a specific ticket for itself, but the rationale behind this patch is to support ticket #3782 . > I may have missed some email about this idea. It

Re: [PATCH v3 2/2] libtests/ofw01: Added a test for RTEMS OFW

Hello Christian, On Sun, Dec 27, 2020 at 2:39 PM Christian Mauderer wrote: > Hello Niteesh, > > I pushed the two patches. > Thanks for pushing the patches. Thanks, Niteesh. > Best regards > > Christian > > On 22/12/2020 19:01, Niteesh G. S. wrote: > > Hello

Re: [PATCH v3 2/2] libtests/ofw01: Added a test for RTEMS OFW

Hello Christian, On Tue, Dec 22, 2020 at 6:33 PM Christian Mauderer wrote: > Hello Niteesh, > > On 19/12/2020 16:57, Niteesh G. S. wrote: > > Hello Christian, > > > > On Sat, Dec 19, 2020 at 7:11 PM Christian Mauderer > <mailto:o...@c-mauderer.de&g

Re: [PATCH v3 2/2] libtests/ofw01: Added a test for RTEMS OFW

Thanks, Niteesh. > > Best regards > > Christian > > On 17/12/2020 12:15, Niteesh G. S. wrote: > > ping. > > > > > > On Fri, Dec 4, 2020 at 1:41 PM G S Niteesh Babu > <mailto:niteesh...@gmail.com>> wrote: > > > > This co

Re: [PATCH v3 2/2] libtests/ofw01: Added a test for RTEMS OFW

01.yml > @@ -0,0 +1,21 @@ > +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause > +build-type: test-program > +cflags: [] > +copyrights: > +- Copyright (C) 2020 Niteesh G S > +cppflags: [] > +cxxflags: [] > +enabled-by: true > +features: c cprogram > +includes

Re: [PATCH v3 1/2] bsps/shared/ofw: Implement RTEMS OFW interface

Hello, In this set of patches, I have added a test header which allows us to reinitialize the OFW API with test FDT. Other than that, I have also added a few explicit casts to suppress warnings. Thanks, Niteesh On Fri, Dec 4, 2020 at 1:41 PM G S Niteesh Babu wrote: > RTEMS OFW is a FDT only

Re: [PATCH v2 2/2] libtests/ofw01: Added a test for RTEMS OFW

rtemstest > > diff --git a/spec/build/testsuites/libtests/ofw01.yml > b/spec/build/testsuites/libtests/ofw01.yml > > new file mode 100644 > > index 000000..8517c58bad > > --- /dev/null > > +++ b/spec/build/testsuites/libtests/ofw01.yml > > @@ -0,0 +1,21 @@ > &g

Re: [PATCH v2 1/2] bsps/shared/ofw: Implement RTEMS OFW interface

Hello Christian, On Tue, Nov 17, 2020 at 12:10 AM Christian Mauderer wrote: > Hello, > > sorry for the long delay. I tested it on xilinx-zynq-a9-qemu (which > doesn't have a FDT) and the test seems to run fine. So I'm OK with the > patches. If no one objects in the next two days, I'll commit

Re: [PATCH v2 2/2] libtests/ofw01: Added a test for RTEMS OFW

ed to make sure you saw these patches. Thanks, Niteesh. > Best regards > > Christian > > On 09/11/2020 04:45, Niteesh G. S. wrote: > > Hello, > > > > Pinging again incase this patch missed your attention. > > > > Thanks, > > Niteesh. > >

Re: [PATCH v2 2/2] libtests/ofw01: Added a test for RTEMS OFW

l > +++ b/spec/build/testsuites/libtests/ofw01.yml > @@ -0,0 +1,21 @@ > +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause > +build-type: test-program > +cflags: [] > +copyrights: > +- Copyright (C) 2020 Niteesh G S > +cppflags: [] > +cxxflags: [] > +enabled-by:

Re: [PATCH v1 1/2] bsps/shared/ofw: Implement RTEMS OFW interface

ping. On Thu, Sep 24, 2020 at 9:00 AM Niteesh G. S. wrote: > Hello, > > On Sat, Sep 19, 2020 at 4:13 PM Christian Mauderer > wrote: > >> Hello Niteesh, >> >> sorry for adding another delay: I think the new build system needs a bit >> of time to sett

Re: Beagle SPI driver update

Hello, Update: I got the condition in the while loop wrong. After fixing this it works now. I'll try to post a working patch of the SPI driver as soon as possible. Thanks, Niteesh On Wed, Oct 14, 2020 at 12:39 PM Niteesh G. S. wrote: > Hello, > > First of all really sorry for the l

Beagle SPI driver update

Hello, First of all really sorry for the long delay, I am preparing for a robotics competition and it eats up most of my free time. I finally got a logic analyzer and tested the SPI driver using it. And as expected the waveforms weren't right. To understand the device better and also to narrow

Re: [PATCH v1 1/2] bsps/shared/ofw: Implement RTEMS OFW interface

it arrives I'll start verifying the previous drivers and finish refactoring the other ones. Thanks, Niteesh. > > Best regards > > Christian > > [1] https://devel.rtems.org/wiki/Release/6/Waf%20BSP%20Checklist > > On 16/09/2020 19:05, Niteesh G. S. wrote: > > Hello, > &

Re: [PATCH v1 1/2] bsps/shared/ofw: Implement RTEMS OFW interface

Hello, Sorry for the delay, I was a bit occupied with my university work. Now since the new build system is merged I would like to get my GSoC work merged too. The goal of this series patches is to implement the OFW API into RTEMS and modify libBSD to use this RTEMS API instead of its own.

Re: GSoC 2020: Final Report (Beagle BSP: Add FDT based initialization)

Gedare Bloom wrote: > looks great > > On Sun, Aug 30, 2020 at 6:55 AM Christian Mauderer > wrote: > > > > On 30/08/2020 14:38, Niteesh G. S. wrote: > > > Hello, > > > > > > On Sun, Aug 30, 2020 at 4:12 PM Christian Mauderer > > <mail

Re: GSoC 2020: Final Report (Beagle BSP: Add FDT based initialization)

Hello, On Sun, Aug 30, 2020 at 4:12 PM Christian Mauderer wrote: > Hello Niteesh, > > On 30/08/2020 08:58, Niteesh G. S. wrote: > > Hello, > > > > I have updated the blog to contain the links to the commits > > instead of the branches. Please have a look again.

Re: GSoC 2020: Final Report (Beagle BSP: Add FDT based initialization)

take a look and let me know if you would like to change anything. Thanks, Niteesh. On Sun, Aug 30, 2020 at 2:24 AM Gedare Bloom wrote: > On Sat, Aug 29, 2020 at 8:31 AM Christian Mauderer > wrote: > > > > > > > > On 29/08/2020 15:04, Niteesh G. S. wrote: > >

Re: GSoC 2020: Final Report (Beagle BSP: Add FDT based initialization)

Hello, On Sat, Aug 29, 2020 at 2:54 PM Christian Mauderer wrote: > Hello Niteesh > > On 29/08/2020 11:22, Niteesh G. S. wrote: > > On Sat, Aug 29, 2020 at 1:02 PM Christian Mauderer > <mailto:o...@c-mauderer.de>> wrote: > > > > On 29/08/2020 05:57, Nit

Re: GSoC 2020: Final Report (Beagle BSP: Add FDT based initialization)

On Sat, Aug 29, 2020 at 1:02 PM Christian Mauderer wrote: > On 29/08/2020 05:57, Niteesh G. S. wrote: > > On Sat, Aug 29, 2020 at 4:19 AM Gedare Bloom > <mailto:ged...@rtems.org>> wrote: > > > > Are "Links to commits" 1-4 all the code you (a

Re: GSoC 2020: Final Report (Beagle BSP: Add FDT based initialization)

On Sat, Aug 29, 2020 at 4:19 AM Gedare Bloom wrote: > Are "Links to commits" 1-4 all the code you (are claiming you) wrote? > I just want to make sure. It looks fine to me. > Yes, all the code in the commits is written by me. > On Fri, Aug 28, 2020 at 12:07 PM

GSoC 2020: Final Report (Beagle BSP: Add FDT based initialization)

Hello, I have prepared my final report for my project. You can have a look at it here https://gs-niteesh.github.io/finalreport/. Please kindly review the report. Thanks, Niteesh. ___ devel mailing list devel@rtems.org

Re: [PATCH v2] bsps/shared/ofw: Implement RTEMS OFW interface

On Mon, Aug 24, 2020 at 9:53 PM Gedare Bloom wrote: > On Mon, Aug 24, 2020 at 8:42 AM Niteesh G. S. > wrote: > > > > ping. > > > pong. Most of us don't volunteer our time on the weekends. Some people > and open-source projects may, and I understand that the timelin

Re: [PATCH v2] bsps/shared/ofw: Implement RTEMS OFW interface

ping. On Sat, Aug 22, 2020 at 10:15 PM Niteesh G. S. wrote: > Hello, > > I went through the history of the OF implementation in NetBSD and FreeBSD. > I have summarized the things I have found out below. > > The first OF implementation seems to come from NetBSD this i

Re: [PATCH v2] bsps/shared/ofw: Implement RTEMS OFW interface

they would come under BSD-2 license. Thanks, Niteesh. On Sat, Aug 22, 2020 at 7:23 PM Gedare Bloom wrote: > On Fri, Aug 21, 2020 at 11:26 AM Niteesh G. S. > wrote: > > > > > > > > On Fri, Aug 21, 2020 at 9:38 PM Gedare Bloom wrote: > >> > >> Hi Nite

Re: [PATCH v2] bsps/shared/ofw: Implement RTEMS OFW interface

Hello, On Fri, Aug 21, 2020 at 10:58 PM Niteesh G. S. wrote: > >> diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c >> new file mode 100644 >> index 00..481b29553b >> --- /dev/null >> +++ b/bsps/shared/ofw/ofw.c >> @@ -0,0 +1,670 @@ >&

Re: [PATCH v2] bsps/shared/ofw: Implement RTEMS OFW interface

On Thu, Aug 20, 2020 at 1:22 PM G S Niteesh Babu wrote: > RTEMS OFW is a FDT only implementation of the OpenFirmWare > interface. This API is created to be compatible with FreeBSD > OpenFirmWare interface. The main intention is to make > porting of FreeBSD drivers to RTEMS easier. > > Most

Re: [PATCH v2] bsps/shared/ofw: Implement RTEMS OFW interface

On Fri, Aug 21, 2020 at 9:38 PM Gedare Bloom wrote: > Hi Niteesh, > > Can you explain how you developed the new code in a way that ensures > that we do not have any of the previously 4-BSD licensed code left? > The FDT implementation of the OF interface present is ofw_fdt.c is, fortunately,

Re: [PATCH] bsps/shared/ofw: Implement RTEMS OFW interface

On Tue, Aug 18, 2020 at 8:26 PM Christian Mauderer wrote: > On 18/08/2020 11:25, Niteesh G. S. wrote: > > How can we make this API FreeBSD compatible? We have to declare > > defines for the OFW functions > > Eg. #define OF_finddevice rtems_ofw_find_device > > I thin

Re: [PATCH] bsps/shared/ofw: Implement RTEMS OFW interface

for which this cannot be done. Eg: OF_device_from_xref For this, we will have to use the implementation present in openfirm.c On Tue, Aug 18, 2020 at 7:57 AM Chris Johns wrote: > On 17/8/20 2:57 pm, Niteesh G. S. wrote: > > On Mon, Aug 17, 2020 at 3:49 AM Chris Johns > <mailto:c

Re: [PATCH] bsps/shared/ofw: Implement RTEMS OFW interface

On Mon, Aug 17, 2020 at 3:49 AM Chris Johns wrote: > On 16/8/20 11:19 pm, Niteesh G. S. wrote: > > > > On Sun, Aug 16, 2020 at 2:25 PM Chris Johns > <mailto:chr...@rtems.org>> wrote: > > > > On 16/8/20 4:49 am, G S Niteesh Babu wrote: > >

Re: [PATCH] bsps/shared/ofw: Implement RTEMS OFW interface

On Sun, Aug 16, 2020 at 2:25 PM Chris Johns wrote: > On 16/8/20 4:49 am, G S Niteesh Babu wrote: > > --- > > > + > > +#ifdef HAVE_CONFIG_H > > +#include "config.h" > > +#endif > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +const void

Re: [PATCH] bsps/shared/ofw: Implement RTEMS OFW interface

Hello, This patch adds the FDT implementation of the OpenFirmWare interface to RTEMS. This patch is compilable and has been tested on real hardware using the following test. https://github.com/gs-niteesh/rtems/commit/163160bae483d2e12bb7ab9208228989adf01e66 Sorry for sending in a large patch.

Re: [PATCH] bsps/shared/ofw: Added and Documented RTEMS OFW interface

Hello, On Thu, Aug 13, 2020 at 12:09 PM Christian Mauderer < christian.maude...@embedded-brains.de> wrote: > Hello Niteesh, > > On 13/08/2020 07:05, Niteesh G. S. wrote: > > On Thu, Aug 13, 2020 at 12:36 AM Gedare Bloom > <mailto:ged...@rtems.org>> wrote: > &

Re: [PATCH] bsps/shared/ofw: Added and Documented RTEMS OFW interface

On Thu, Aug 13, 2020 at 12:36 AM Gedare Bloom wrote: > I make a few comments below for you to consider. At a high level, I > think the interface looks reasonable, although plainly mimics the > freebsd naming conventions. I wonder if we should prefer our naming > conventions, which is to aim to

Re: [PATCH] bsps/shared/ofw: Added and Documented RTEMS OFW interface

Hello, I have resent the patches onto the mailing list as per Gedare's suggestion in the IRC. The current implementation is not 100% OF compliant. I have avoided a few functions like OF_call, OF_write etc since these don't have a valid implementation in the FDT implementation of OF interface.

Re: GSoC2020: RTEMS OpenFirmWare FDT Implementation (outline)

Ping. Sorry for pinging so quickly but please understand that this is hampering my progress. Thanks, Niteesh. On Sun, Aug 9, 2020 at 12:52 AM Niteesh G. S. wrote: > Hello, > > I have created a basic outline of how the RTEMS openfirm API would > look like. The implementation

GSoC2020: RTEMS OpenFirmWare FDT Implementation (outline)

Hello, I have created a basic outline of how the RTEMS openfirm API would look like. The implementation is inspired by the openfirm.h implementation in FreeBSD. Please a have look at the last 2 commits https://github.com/gs-niteesh/rtems/commits/ofw-rtems6-fdt-implementation-v1 Since we are

Re: GSoC 2020: OFW Import To RTEMS License Issue

/c07cb50dbbf88e174e93f344a820fff68d24778d/sys/dev/ofw/openfirm.c#L119 On Fri, Aug 7, 2020 at 6:28 PM Gedare Bloom wrote: > On Fri, Aug 7, 2020 at 3:25 AM Niteesh G. S. wrote: > > > > On Wed, Aug 5, 2020 at 2:16 AM Gedare Bloom wrote: > >> > >> On Tue, Aug 4, 2020 at 12:38 PM Christian M

Re: [PATCH RTEMS 7/7] libtests/openfirmware: Added a testsuite for openfirmware

On Sat, Aug 8, 2020 at 1:54 PM Chris Johns wrote: > On 8/8/20 6:01 pm, Niteesh G. S. wrote: > > ping. > > I am sorry about the delay in answering. It is the weekend so things can be > slow. I will add some input to see if we can figure this out. I have not > followe

Re: [PATCH RTEMS 7/7] libtests/openfirmware: Added a testsuite for openfirmware

re: Like Niteesh said: There have been some different > directions in the past. Which one should be the target? > > Best regards > > Christian > > On 04/08/2020 20:36, Niteesh G. S. wrote: > > Ping. > > > > On Sun, Aug 2, 2020 at 2:44 PM Niteesh G. S. > <mai

Re: GSoC 2020: OFW Import To RTEMS License Issue

compat by providing macros i.e: #define OF_finddevice rtems_ofw_find_device This redefinition should be in RTEMS, right? because if we have it libBSD we will need to have two redefinitions one in RTEMS to support the imported drivers and others in libBSD. > > Gedare > > > On 04/08/202

Re: [PATCH RTEMS 7/7] libtests/openfirmware: Added a testsuite for openfirmware

Ping. On Sun, Aug 2, 2020 at 2:44 PM Niteesh G. S. wrote: > Hello, > > I went through some of my previous conversations to summarize the various > directories > suggested by people. Maybe this will help to come up with a conclusion. > > In my first porting commit, I p

Re: GSoC 2020: OFW Import To RTEMS License Issue

ping. On Sat, Aug 1, 2020 at 2:11 PM Niteesh G. S. wrote: > > > On Sat, Aug 1, 2020 at 1:37 AM Joel Sherrill wrote: > >> >> >> On Fri, Jul 31, 2020 at 2:16 PM Niteesh G. S. >> wrote: >> >>> Hello, >>> >>> In a recent rev

Re: [PATCH RTEMS 7/7] libtests/openfirmware: Added a testsuite for openfirmware

ldflags: > > >>>>>> - -Wl,--wrap=printf > > >>>>>> - -Wl,--wrap=puts > > >>>>>> +- -Wl,--wrap=bsp_fdt_get > > >>>>>> links: > > >>>>>> - role: build-dependency > > >>&

Re: GSoC 2020: OFW Import To RTEMS License Issue

On Sat, Aug 1, 2020 at 1:37 AM Joel Sherrill wrote: > > > On Fri, Jul 31, 2020 at 2:16 PM Niteesh G. S. > wrote: > >> Hello, >> >> In a recent review of these patches >> https://lists.rtems.org/pipermail/devel/2020-July/060653.html >> Geda

GSoC 2020: OFW Import To RTEMS License Issue

Hello, In a recent review of these patches https://lists.rtems.org/pipermail/devel/2020-July/060653.html Gedare mentioned that we cannot use these patches with the current license. More details regarding the conversation can be found in the following archive.

Re: [PATCH RTEMS 2/7] libfreebsd: Import OFW files from FreeBSD.

On Wed, Jul 29, 2020 at 9:24 PM Gedare Bloom wrote: > I'm a little concerned about namespace pollution. > Can you please explain about namespace pollution? > On Wed, Jul 15, 2020 at 12:32 AM G S Niteesh Babu > wrote: > > > > freebsd head: b8c57b4 > > > > The following files have been

Re: [PATCH RTEMS 3/7] libfreebsd: Added ofw_if.h

On Wed, Jul 29, 2020 at 9:29 PM Gedare Bloom wrote: > On Wed, Jul 15, 2020 at 12:32 AM 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 header file that maps the > > OF_function calls to their

Re: [PATCH RTEMS 1/7] bsp/fdt.h: Move bsp/fdt.h to cpukit

Hello, Please review this series of patches. Thanks, Niteesh. On Wed, Jul 15, 2020 at 3:14 PM Niteesh G. S. wrote: > Hello, > > I would like to add some more information regarding these patches here. > > These patches are currently not meant to replace the OpenFirmWare AP

Re: [PATCH] bsp/fdt.h: Move bsp/fdt.h to cpukit

r and may be located > in a > - * memory area that is used by the program. The low-level initialization > - * should copy the FDT for later use. > + * @ingroup RTEMSBSPsShared > * > - * The copy can be accessed by bsp_fdt_get(). > - * > - * @param[in] src The source FD

Re: GSoC 2020 PATCH: Import OpenFirmWare API to RTEMS

Hello Sebastian, On Wed, Jul 15, 2020 at 3:27 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello Niteesh, > > I have currently no time to review this work. I am busy with the > preparations to integrate the new build system. A broken ARM compiler > delayed my testing a bit

Re: [PATCH RTEMS 1/7] bsp/fdt.h: Move bsp/fdt.h to cpukit

SPsShared > * > - * The copy can be accessed by bsp_fdt_get(). > - * > - * @param[in] src The source FDT. > */ > -void bsp_fdt_copy(const void *src); > > -/** > - * @brief Returns the FDT of the BSP. > - * > - * @return The FDT of the BSP. > +/* >

Re: GSoC 2020: Location for FreeBSD files in RTEMS

Hello Christian, On Sat, Jul 11, 2020 at 10:12 PM Christian Mauderer wrote: > Hello Niteesh, > > On 11/07/2020 18:22, Niteesh G. S. wrote: > > Hello, > > > > I acknowledge that 2 days is very little time for a reminder mail but > > please understand >

Re: GSoC 2020: Location for FreeBSD files in RTEMS

Hello, I acknowledge that 2 days is very little time for a reminder mail but please understand that this is hampering my progress. Thanks, Niteesh. On Thu, Jul 9, 2020 at 7:32 PM Niteesh G. S. wrote: > Hello, > > The current directory structure I have been using in my GSo

GSoC 2020: Location for FreeBSD files in RTEMS

Hello, The current directory structure I have been using in my GSoC project for the FreeBSD drivers is giving me troubles while installing/including the headers. The current structure of the drivers is as follows cpukit/libfreebsd/freebsd --> After this we follow the FreeBSD file structure Eg:

  1   2   >