Re: Ticket #3515

On Thu, 30 Jan 2020 at 05:52, Chris Johns wrote: > > On 29/1/20 7:03 pm, Bran S wrote: > > Hi Guys, > > > > I am trying to solve #3515 > > https://devel.rtems.org/ticket/3515 > > Nice and thanks. > > > For this issue covoar is required. > > > > So I cloned htt

Re: Need to disable "atsamv" watchdog to avoid reset

> On Jan 31, 2020, at 15:22 , Peter Dufault wrote: > > I noticed this while tracking down the GMAC transmit initialization on > non-revA SAMV71 chips and wanted to send it as heads-up and to see if anyone > understands what's happening. > > If I left the board doing nothing then after about

Need to disable "atsamv" watchdog to avoid reset

I noticed this while tracking down the GMAC transmit initialization on non-revA SAMV71 chips and wanted to send it as heads-up and to see if anyone understands what's happening. If I left the board doing nothing then after about fifteen or twenty minutes (I never characterized it) I would see "

Re: Requirement Document generator tool

On Fri, Jan 31, 2020 at 12:39 AM Christian Mauderer wrote: > > On 30/01/2020 23:13, Chris Johns wrote: > > On 30/1/20 8:35 pm, Christian Mauderer wrote: > >> On 29/01/2020 23:48, Chris Johns wrote: > >>> On 29/1/20 7:40 pm, Christian Mauderer wrote: > On 28/01/2020 23:15, Chris Johns wrote: >

[PATCH 0/3] [rtems-libbsd] Fix compilation for i386

Hello, I assembled a patch set which enabled building rtems-libbsd for i386-based BSPs again (currently without dev_nic_e1000 enabled). It's my first patch set for rtems-libbsd, but I tried to follow the contribute guidelines as close as possible I also have a similar patchset for amd64 in pre

[PATCH 1/3] i386: Add missing files from FreeBSD

- Files needed to make rtems-libbsd build again for i386 --- freebsd/sys/i386/include/machine/bus.h| 6 + .../sys/x86/include/machine/intr_machdep.h| 175 freebsd/sys/x86/include/machine/legacyvar.h | 73 freebsd/sys/x86/include/machine/metadata.h| 57 +++ freeb

[PATCH 2/3] i386: Add to build

--- libbsd.py | 7 +-- waf_libbsd.py | 2 +- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/libbsd.py b/libbsd.py index bd24cd61..3823c03f 100644 --- a/libbsd.py +++ b/libbsd.py @@ -1556,6 +1556,8 @@ class dev_nic(builder.Module): 'sys/i386/include/specialr

[PATCH 3/3] i386: Port to RTEMS

- Update imported files to compile rtems-libbsd for i386 based BSPs - Currently does not support the option "dev_nic_e1000 = on" --- freebsd/sbin/sysctl/sysctl.c | 10 +- freebsd/sys/dev/pci/pci_pci.c |2 + freebsd/sys/i386/i386/legacy.c | 381 ---

Re: About Beaglebone Black device tree

On Fri, Jan 31, 2020 at 9:59 PM Christian Mauderer wrote: > On 31/01/2020 17:25, Christian Mauderer wrote: > > On 31/01/2020 16:04, Vijay Kumar Banerjee wrote: > >> Hi, > >> > >> While trying to run an rtems-littlevgl app on BBB, I found that the > device > >> tree generated from the freebsd sour

Re: About Beaglebone Black device tree

On 31/01/2020 17:25, Christian Mauderer wrote: > On 31/01/2020 16:04, Vijay Kumar Banerjee wrote: >> Hi, >> >> While trying to run an rtems-littlevgl app on BBB, I found that the device >> tree generated from the freebsd source matching the freebsd-org >> HEAD commit doesn't work with the app and f

Re: About Beaglebone Black device tree

On 31/01/2020 16:04, Vijay Kumar Banerjee wrote: > Hi, > > While trying to run an rtems-littlevgl app on BBB, I found that the device > tree generated from the freebsd source matching the freebsd-org > HEAD commit doesn't work with the app and framebuffer device fails > to open. This is most likel

About Beaglebone Black device tree

Hi, While trying to run an rtems-littlevgl app on BBB, I found that the device tree generated from the freebsd source matching the freebsd-org HEAD commit doesn't work with the app and framebuffer device fails to open. This is most likely due to the changes in the freebsd dts sources because of wh

Re: "atsamv" BSP legacy network driver status

On 31/01/2020 13:39, dufa...@hda.com wrote: > > >> On Jan 31, 2020, at 01:31 , Christian Mauderer >> wrote: >> >> On 30/01/2020 22:12, dufa...@hda.com wrote: >>> >>> On Jan 30, 2020, at 01:24 , Christian Mauderer wrote: The SDRAM initialization is done in bsp_start_hook_0.

Re: "atsamv" BSP legacy network driver status

> On Jan 31, 2020, at 01:31 , Christian Mauderer > wrote: > > On 30/01/2020 22:12, dufa...@hda.com wrote: >> >> >>> On Jan 30, 2020, at 01:24 , Christian Mauderer >>> wrote: >>> >>> The SDRAM initialization is done in bsp_start_hook_0. Most >>> initialization is done in bsp_start_hook_1.