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

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

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

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

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

[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

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

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

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

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

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.