On Feb 20, 2017, at 14:38 , Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote:On 19/02/17 01:29, dufa...@hda.com wrote:On Feb 19, 2017, at 07:55 , Joel Sherrill <j...@rtems.org <mailto:j...@rtems.org>> wrote:On Feb 18, 2017 4:03 PM, "Peter Dufault" <dufa...@
> On Feb 19, 2017, at 07:55 , Joel Sherrill <j...@rtems.org> wrote:
>
>
>
> On Feb 18, 2017 4:03 PM, "Peter Dufault" <dufa...@hda.com
> <mailto:dufa...@hda.com>> wrote:
>> On Feb 14, 2017, at 22:08 , Sebastian Huber
>> <sebastian.
> On Sep 30, 2016, at 01:49 , Sebastian Huber
> <sebastian.hu...@embedded-brains.de> wrote:
>
> Hello Peter,
>
> On 30/09/16 00:13, Peter Dufault wrote:
>> I’m moving an older application to 4.12 and having performance issues
>> compared to “4.11” (aka “4
gt; <mailto:sebastian.hu...@embedded-brains.de>> wrote:
>>>
>>> Hello Peter,
>>>
>>> On 30/09/16 00:13, Peter Dufault wrote:
>>>> I’m moving an older application to 4.12 and having performance
>>>> issues compared to “4.11” (aka “4.10.9
has been
paying attention to this and knows whether or not it’s really being supported.
> On Feb 11, 2018, at 12:08 , Joel Sherrill <j...@rtems.org> wrote:
>
>
>
> On Feb 11, 2018 11:29 AM, "Peter Dufault" <dufa...@hda.com
> <mailto:dufa...@hda.com>&
, whether the ATSAMA5 meets all of your
> expectations.
>
>
> Kind regards,
>
> Thomas.
>
> - Ursprüngliche Mail -
> Von: "Peter Dufault"
> An: "Development"
> Gesendet: Sonntag, 25. November 2018 18:38:19
> Betreff: BSP for Microchi
nbination (USB+SDRAM) was also available on
>>> Microchip's evaluation board, but obviously was not tested together at
>>> Microchips labs...
>>>
>>> So: I recommend you to tripple check, whether the ATSAMA5 meets all of
>>> your expectations.
>>>
>>
n 10/05/2019 13:58, Gedare Bloom wrote:
>>>> On Tue, May 7, 2019 at 5:03 AM Peter Dufault>>> <mailto:dufa...@hda.com>> wrote:
>>>>> What is best practice to change build behavior? e.g. I need to use
>>>>> --whole-archive/--no-whole-arc
> On May 10, 2019, at 08:07 , Sebastian Huber
> wrote:
>
> On 10/05/2019 13:58, Gedare Bloom wrote:
>> On Tue, May 7, 2019 at 5:03 AM Peter Dufault wrote:
>>> What is best practice to change build behavior? e.g. I need to use
>>> --whole-archive/--no
()
at
/home/dufault/development/rtems/kernel/rtems/c/src/../../cpukit/libdl/rtl-allocator.c:119
119 rtl->allocator.allocator (RTEMS_RTL_ALLOC_LOCK,
(gdb) print rtl->allocator.allocator
$469 = (rtems_rtl_allocator) 0x1357c5
(gdb)
> On Apr 26, 2019, at 17:35 , Peter Dufault wrot
ld be tested, otherwise we should remove
> it from the build to make it a little faster and reduce the maintenance costs
> of libbsd.
It is used. The use may be removed (this is a port from vxWorks) but as part
of a baseline it is used.
Peter
-
Peter Dufault
HD Associa
or ELF
>> files /rtems_rtl_alloc_lock() /calls /rtem_rtl_alloc_heap() /and that
>> calls /_RTEMS_Lock_allocator()/ which locks the heap. Then RTL calls /read()
>> /and the NFS threads try to use the heap.
>>
>> (gdb) up
>> #1 0x00135394 in rtems_rtl_alloc_lock ()
>&g
.LC0 format
strings will be “BAR %s\n”. I’ll read-up on ELF but the “Num” field appears to
be what would make those .LC0 easily unique.
Zynq dufault@gen6 fubar]$ cat foo.c
#include
extern void foo(void);
void foo(void)
{
printf("FOO %s\n", "Foo 1");
}
Zynq dufault@ge
LOCAL DEFAULT3 .LC2
45: 014c 0 NOTYPE LOCAL DEFAULT3 .LC3
47: 0164 0 NOTYPE LOCAL DEFAULT3 .LC4
> On Apr 25, 2019, at 07:56 , Peter Dufault wrote:
>
> I’m porting a large vxWorks application and I’m trying to download “ld -r”
> files as you can
installed.
>> devtoolset-7-binutils.x86_64 2.28-11.el7
>> @centos-sclo-rh
>>
>> That will give you gcc 7.3.1 and friends:
This is the CentOS version of the formal Red Hat way to get required newer
tools on existing systems, so it’s a good way to go.
Peter
> On Jul 17, 2019, at 01:48 , Sebastian Huber
> wrote:
>
> Hello Peter,
>
> On 16/07/2019 19:58, Peter Dufault wrote:
>> I have a build failure with the MVME5500 “beatnik” BSP. Therefore I tried to
>> build the “psim” BSP and have the same failure: the
sses for BSP (CHRPxxx and PREPxxx are from libcpu/io.h) */
#define _IO_BASE0xe000 /* Motload's PCI IO base */
#define _ISA_MEM_BASE CHRP_ISA_MEM_BASE
/* address of our ram on the PCI bus */
#define PCI_DRAM_OFFSET CHRP_PCI_DRAM_OFFSET
Peter
-
Peter Dufault
than I want to do.
The other code that can’t be checked is end-user code that includes but
not . That’s always an issue, though.
Peter
-----
Peter Dufault
HD Associates, Inc. Software and System Engineering
This email is delivered through the public internet using protocols subjec
One thing I should have said is that “rtems" and "rtems-tester" are the master
branches, "rtems-tester" is updated as of yesterday, and “rtems” is recent.
> On Sep 20, 2019, at 15:46 , Peter Dufault wrote:
>
> I’m bringing up the rtems-tester for the PowerP
t; master branches, "rtems-tester" is updated as of yesterday, and “rtems” is
> > recent.
>
> Thanks.
>
> >
> >> On Sep 20, 2019, at 15:46 , Peter Dufault wrote:
> >>
> >> I’m bringing up the rtems-tester for the PowerPC “beatnik” bsp. I’m
> &g
> On Sep 21, 2019, at 11:03 , Joel Sherrill wrote:
>
>
>
> On Sat, Sep 21, 2019, 9:55 AM Peter Dufault wrote:
> I’ve searched but can’t find anywhere. I’d like to see the results of the
> tests on all architectures to compare to what I see on PowerPC-beatnik.
>
>
> On Sep 21, 2019, at 11:44 , Joel Sherrill wrote:
>
>
>
> On Sat, Sep 21, 2019, 10:09 AM Peter Dufault wrote:
> Most of the failures I see on “beatnik” are detected by
> “rtems_test_assert()”. That prints the assertion and calls exit, e.g. on
> beatnik:
>
> On Sep 21, 2019, at 17:49 , wrote:
>
>
>
>> On Sep 21, 2019, at 16:41 , Chris Johns wrote:
>>
>> On 22/9/19 1:18 am, dufa...@hda.com wrote:
>>>> On Sep 21, 2019, at 11:03 , Joel Sherrill wrote:
>>>> On Sat, Sep 21, 2019, 9:55 AM P
> On Sep 21, 2019, at 17:04 , Chris Johns wrote:
>
> On 22/9/19 2:39 am, dufa...@hda.com wrote:
>>> On Sep 21, 2019, at 11:44 , Joel Sherrill wrote:
>>> On Sat, Sep 21, 2019, 10:09 AM Peter Dufault wrote:
>>> Most of the failures I see on “beatnik” are
> On Sep 21, 2019, at 16:41 , Chris Johns wrote:
>
> On 22/9/19 1:18 am, dufa...@hda.com wrote:
>>> On Sep 21, 2019, at 11:03 , Joel Sherrill wrote:
>>> On Sat, Sep 21, 2019, 9:55 AM Peter Dufault wrote:
>>> I’ve searched but can’t find an
BSP, .*|.*
RTEMS_FATAL_SOURCE_ASSERT, .*|.* RTEMS_FATAL_SOURCE_STACK_CHECKER, .*|.*
RTEMS_FATAL_SOURCE_EXCEPTION, .*|.* RTEMS_FATAL_SOURCE_SMP, .*|.*
RTEMS_FATAL_SOURCE_PANIC, .*|.* RTEMS_FATAL_SOURCE_INVALID_HEAP_FREE, .*
Peter
-
Peter Dufault
HD Associates, Inc.
r 3 (0x3)
(...)
] executing thread ID = 0x0a01034f, name = ai45
] Stack Trace:
] IP: 0x98a0, LR: 0x98ac
] --^ 0x500c--^ 0x0001d27c--^ 0x0001d488--^ 0xf73c--^ 0xa4fc
] --^ 0x98ac--^ 0x500c--^ 0x0001d27c--^ 0x0001d488--^ 0xf73c
] --^ 0xa4fc--^ 0x983c--^ 0x
> On Sep 24, 2019, at 17:41 , Joel Sherrill wrote:
>
> On Tue, Sep 24, 2019 at 4:29 PM Peter Dufault wrote:
>>
>> I've started testing the PowerPC MVME5500 "beatnik" BSP on the mainline.
>> I've run through the majority of the RTEMS tests, with some
regular expressions but an "outside of the current tester's framework" failure
regular expression.
These RTEMS_FATAL_FUBAR errors mean:
- The test has failed, and the test is going to reset the board momentarily.
There's no need for the tester to do a reset, the tester can fail thi
P_uart_termios_isr_com1
#else
0
#endif
},
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
This email is delivered through the public internet using protocols subject to
interception and tampering.
___
#define CONFIGURE_POSIX_INIT_THREAD_ENTRY_POINT _POSIX_Init
#define CONFIGURE_POSIX_INIT_THREAD_TABLE
#define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
#define CONFIGURE_INIT
#include
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
This email is delivered t
so I'm a bit
surprised on this errata entry.
I don't say that this issue written in errata does not exist. (If someone uses
the embedded xtal oscillator, it will exist, I can confirm.)
But people may try using external clock and benefit from the MCU's power.
Peter
-
Peter
on
It is convenient for me if the ATSAME70Q21 is usable, but I need to think
carefully and test before risking that.
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
This email is delivered through the public internet using protocols subject to
LIAS ("REGION_DATA", SDRAM);
> REGION_ALIAS ("REGION_DATA_LOAD", QSPIFLASH);
> REGION_ALIAS ("REGION_FAST_TEXT", ITCM);
> REGION_ALIAS ("REGION_FAST_TEXT_LOAD", QSPIFLASH);
> REGION_ALIAS ("REGION_FAST_DATA",
size by figuring out how to get rid of "libblock" (it isn't needed
in the non libbsd case);
- figure out how to set things up so that "openocd" works using the SDRAM;
- or relocate everything needed prior to initializing SDRAM to be in the
internal flash.
This is still an ev
roject the same as the one in "grisp" but
>> not slimmed down?
>
> No. It's a different one because there is a completely different boot
> concept. On GRiSP the boot is done from a SD card. For this customer the
> bootloader can update the program in the XIP area and start it from th
(i = 0; i < GMAC_QUEUE_COUNT; i++) {
gmacd_setup_queue(gmacd, i,
DUMMY_BUFFERS, dummy_buffer, dummy_rx_desc,
DUMMY_BUFFERS, dummy_buffer, dummy_tx_desc,
NULL);
}
So, as I said:
Is it possible that the latest "SAMV71 "Xplained" Ultra&q
mpatible.
> I think that discussion popped up two or three times on the list. It
> would be great if someone would have the time for an upgrade.
>
>>
>>for (i = 0; i < GMAC_QUEUE_COUNT; i++) {
>>gmacd_setup_queue(gmacd, i,
>>DUMMY_BUFFERS,
> 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 doi
Actually I'm told the plan now is it will be NXP i.MX RT1060.
> On Jan 27, 2020, at 16:28 , Peter Dufault wrote:
>
> I'm evaluating porting RTEMS to the NXP i.MX RT1020. What will take me the
> longest is if the ethernet peripheral isn't supported.
> It's referred to as t
at this is how NXP internal SW development works.
This must be what's exported to be convenient for the pointers and clickers.
Does anyone know of a source of NXP code for recent platforms other than
installing the IDE?
Peter
-
Peter Dufault
HD Associates, Inc. Software and
> On Feb 9, 2020, at 09:33 , Christian Mauderer wrote:
>
> Hello Peter,
>
> On 08/02/2020 21:16, Peter Dufault wrote:
>> I will begin working on a BSP for the i.MX RT 10xx family. I require
>> support for a 1052 but will be developing on a 1064 so those two varia
o commit them early
> so that we don't have double work and merge conflicts.
>
> Best regards
>
> Christian
>
Thank you, Christian.
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
This email is delivered through the public interne
fic code. Target specific code *can't* be required for this
since I can cut-and-paste "add-symbol-file" auto-generated output from the
SLAC/RTEMS gdb-stub into generic GDB and then everything works.
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engin
> On Jan 20, 2020, at 17:37 , Chris Johns wrote:
>
> Hi Peter,
>
> Happy new year.
>
> On 17/1/20 9:01 am, Peter Dufault wrote:
>> I'm trying to hook the SLAC / Til Straumann PowerPC remote debugger stub in
>> to what's loaded by "libdl&
ot;mmap" anything.
We should define the goal of protected stacks. My goal is increased robustness
at the expense of additional application setup complexity, but the application
setup should be 100% POSIX compliant.
Peter
-
Peter Dufault
HD Associates, Inc. Softw
Sherrill wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Mar 2, 2020 at 10:12 AM Gedare Bloom wrote:
>>>>>>>>
>>>>>>>> On Mon, Mar 2, 2020 at 9:05 AM Joel Sherrill wrote
> requires an MMU to implement such mappings so if there is just an MPU
> then things may break (or work in weird ways).
>
>
The decision about memory protection unit versus memory management unit is
essential to decide how this shoul
s
That looks very promising. But what does this part mean? Is it that anything
that is a shell environment should have the unique magic number derived from
"rtems_build_name" that evaluates to SENV? So all shell environments will have
the magic number SENV? If I interpret t
> On Mar 13, 2020, at 08:42 , Sebastian Huber
> wrote:
Thanks for replying.
>
> On 12/03/2020 21:44, Peter Dufault wrote:
>
>> I've added an 8-port RS232 PCI Mezzanine Card to the "beatnik" BSP. The
>> console (aka serial port) code is confusin
where
>>> premature optimization will be acceptable.) Tagged TLB architectures
>>> or those with "superpages" may incur less overhead if you can
>>> selectively shoot-down the entry (entries) used for task stacks.
>>
>>
>> Added to my TO-DO list.
>>
gt;
> That doesn't count timer_service_routine, the one for signals, etc.
>
> I'm not opposed and now is the time if there is consensus. I have reached the
> point where I acknowledge the long history and mostly am concerned about how
> changes impact user code more than the idea of change
My thought is that it matches what is needed and is expected to be optimized.
> On Jul 3, 2020, at 24:37 , Utkarsh Rai wrote:
>
>
>
> On Fri, Jul 3, 2020 at 1:32 AM Peter Dufault wrote:
> I finally have gotten to reviewing Utkarsh's work in GSOC. One item th
> On Jan 29, 2021, at 13:59 , Gedare Bloom wrote:
>
>
>
> On Fri, Jan 29, 2021 at 11:38 AM Joel Sherrill
> wrote:
>
>
> On Fri, Jan 29, 2021, 12:28 PM Sebastian Huber
> wrote:
> On 29/01/2021 18:33, Peter Dufault wrote:
>
> >>> Do not
alization to avoid using stack since I'm calling some NXP functions. I'd
like a small amount of stack available in the context of bsp_start_hook_0() to
set up the external RAM.
- What's going on in the shared ARM _start with bsp_start_hook_0_done and the
branch to bsp_start_hook_0()?
Pet
I'll put it in at compile time but looking at the code that won't make a
difference.
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
This email is delivered through the public internet using protocols subject to
interception and tampering.
signature
> On Jun 11, 2021, at 08:07 , Christian Mauderer wrote:
>
> Hello Peter,
>
> On 11/06/2021 13:23, Peter Dufault wrote:
>> I tried to build the "minimal" buildset for the IMXRT BSP and I get
>> undefined INET6 references - _bsd_inet6_pfil_hook, _bsd_ip
e.
Peter
-----
Peter Dufault
HD Associates, Inc. Software and System Engineering
This email is delivered through the public internet using protocols subject to
interception and tampering.
signature.asc
Description: Message signed wit
d bootstrap properly but evidently not.
Do you need to use multiple prefixes to support multiple build sets? I wanted
to try the minimal one first before installing.
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
This email is delivered through t
ootstrap properly but evidently not.
>
> Do you need to use multiple prefixes to support multiple build sets? I
> wanted to try the minimal one first before installing.
>
I removed the installed "imxrt1052" BSP and then it worked.
Peter
-
Peter Dufault
HD
override what to use as "cmake" in RSB to specify "cmake3"?
> >>
> >>> On Apr 30, 2021, at 04:41 , Peter Dufault wrote:
> >>>
> >>> I verified my environment is squeaky-clean with a simple path and no
> >>> environment va
From: Peter Dufault
When the PowerPC shared console baud rate starts at anything other than
9600 the termios code will set it to 9600 at the first open.
---
bsps/powerpc/shared/console/uart.c | 4
1 file changed, 4 insertions(+)
diff --git a/bsps/powerpc/shared/console/uart.c
b/bsps
From: Peter Dufault
The "powerpc/shared/console" code has the start-up console value fixed
at 9600 baud. This changes the hard-wired constant "9600" in the code
to the configuration setting "BSP_CONSOLE_BAUD" and adds configuration
support in both the "waf&qu
From: Peter Dufault
With these two changes the "powerpc/shared/console" code supports a
configurable baud rate.
Peter Dufault (2):
powerpc/shared/console: Make console baud rate configurable.
powerpc/shared/console: "termios" first open sets console baud to 9600
From: Peter Dufault
The "powerpc/shared/console" code has the start-up console value fixed
at 9600 baud. This changes the hard-wired constant "9600" in the code
to the configuration setting "BSP_CONSOLE_BAUD" and adds configuration
support in both the "waf&qu
From: Peter Dufault
With these two changes the "powerpc/shared/console" code supports a
configurable baud rate.
- Remove hard-wired start-up baud of 9600.
- Fix "termios" first-open that resets baud rate to 9600.
Peter Dufault (2):
powerpc/shared/console: Make console ba
From: Peter Dufault
When the PowerPC shared console baud rate starts at anything other than
9600 the termios code will set it to 9600 at the first open.
---
bsps/powerpc/shared/console/uart.c | 4
1 file changed, 4 insertions(+)
diff --git a/bsps/powerpc/shared/console/uart.c
b/bsps
I forgot to specify V2. I'll try again, sorry for the noise.
> On Apr 27, 2021, at 13:40 , wrote:
>
> From: Peter Dufault
>
> With these two changes the "powerpc/shared/console" code supports a
> configurable baud rate.
>
> - Remove hard-wired start-up bau
> On Apr 30, 2021, at 05:03 , dufa...@hda.com wrote:
>
> Can I override what to use as "cmake" in RSB to specify "cmake3"?
>
>> On Apr 30, 2021, at 04:41 , Peter Dufault wrote:
>>
>> I verified my environment is squeaky-clean with
I lied. I had /usr/local/bin in my path to pick up "cmake3" instead of the
system "cmake". I thought I repeated the test with PATH set to just /usr/bin
and /usr/sbin, but I hadn't.
Can I override what to use as "cmake" in RSB to specify "cmake3"?
>
o.
> "Get" was already used. This is a "Get" when we know the identifier is valid.
> Do you have a better verb?
>
Valid_ID_Get? Or is that getting too wordy?
I like "_ValID_" (i.e. use "ValID" in interface names for validated IDs) but
that mu
g deal, and "Get_*_by_id" can be used going forward to
imply the ID needs validation as opposed to getting it from a valid
Thread_Control.
I have to research the RTEMS naming convention. I know it must be well-defined
and not Random_case.
Peter
-
Peter
Actually, replying to myself:
I bet the context-switching code is broken for platforms that use the SPE via a
Freescale library. That's something I'll need to look at.
> On Jan 22, 2021, at 14:26 , Peter Dufault wrote:
>
> Signed PGP part
> The PowerPC Signal Processing Engine
I re-read Joel's mail and I agree, the priority should be left ridiculously low
(as it is now) or maybe set in the middle (but why bother?).
I was thinking about matching classic RTEMS behavior. I don't think it matters
in POSIX.
> On Feb 23, 2021, at 17:12 , Peter Dufault wrote:
>
&g
"powerpc/{beatnik/haleakala,motorola_powerpc,mvme3100,mvme5500}/bsp*.yml}"
files to add the build-dependency on "uid: ../../optconsolebaud" can I put it
in the "spec/build/bsps/powerpc/grp.yml" file?
Peter
-
Peter Dufault
HD Associates, Inc. Software an
the BSPs
>> in "ARCH".
>
> This is the wrong level for BSP-specific options. You have to look for:
>
> spec/build/bsps/ARCH/FAMILY/grp.yml
This won't work, "powerpc/shared/console" is shared across powerpc FAMILYs:
[dufault@gen6 powerpc]$ grep -r shared
tally signed that looked
odd.
At any rate, this patch should at least be received properly.
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
This email is delivered through the public internet using protocols subject to
interception and tampering.
_
From: Peter Dufault
The "powerpc/shared/console" code has the start-up console value fixed
at 9600 baud. This changes the hard-wired constant "9600" in the code
to the configuration setting "BSP_CONSOLE_BAUD" and adds configuration
support in both the "waf&qu
From: Peter Dufault
The "powerpc/shared/console" code has the start-up console value fixed
at 9600 baud. This changes the hard-wired constant "9600" in the code
to the configuration setting "BSP_CONSOLE_BAUD" and adds configuration
support in both the "waf&qu
From: Peter Dufault
When the PowerPC shared console baud rate starts at anything other than
9600 the termios code will set it to 9600 at the first open.
---
bsps/powerpc/shared/console/uart.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/bsps/powerpc/shared/console/uart.c
b/bsps
for an eight port PMC serial port card. Some of the
files will need to be shuffled around.
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
This email is delivered through the public internet using protocols subject to
i
> On Apr 9, 2021, at 11:53 , Peter Dufault wrote:
>
> The "powerpc/shared/console" code has the start-up console value fixed
> at 9600 baud. This changes the hard-wired constant "9600" in the code
> to the configuration setting "BSP_CONSOLE_BAUD&q
of BSP_uart_termios_set().
Is this a different patch (since it is a separate issue) or a [2/2] patch to
the "Make console baud rate configurable" patch (since the issue didn't show up
as the start-up baud rate was fixed at 9600 anyway)?
Peter
-
Peter Dufault
HD Associa
use the English name for our organization as well.
>
> The answer might take some time, though.
>
>
>
> Best regards,
>
>
>
> Jan
>
>
>
> From: Joel Sherrill
> Sent: Monday, February 15, 2021 9:41 PM
> To: Peter Dufault
> Cc: Sommer,
e discussion:
testsuites/fstests/fsdosfsname01/create_files.cs
It's full of Unicode.
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
This email is delivered through the public internet using protocols subject to
interception and tampe
From: Peter Dufault
- Fix detection of timeout in rtems_shell_term_wait_for().
- Use the "termios" VTIME inter-character timeout.
The previous version depends on the BSP clock tick and can be long.
- Add debugging regarding terminal size sequences.
Updates #4763
---
cpukit/lib
From: Peter Dufault
- safe_pause_us() and safe_pause_ms() depend on the clock tick. Use DELAY().
---
freebsd/sys/dev/e1000/e1000_osdep.h | 12
1 file changed, 12 insertions(+)
diff --git a/freebsd/sys/dev/e1000/e1000_osdep.h
b/freebsd/sys/dev/e1000/e1000_osdep.h
index 70db294
From: Peter Dufault
This is my first submission of a patch using format-patch and
send-email from my Linux system. Let me know if anything is wrong.
Peter Dufault (1):
libmisc/shell: Fix timeout in getting terminal size
cpukit/libmisc/shell/shell.c | 101
From: Peter Dufault
- Fix detection of timeout in rtems_shell_term_wait_for().
- Switch to using "termios" VTIME inter-character timeout.
The previous implementation is dependent on the BSP clock tick value.
Updates #4763
---
cpukit/libmisc/shell/she
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
an appropriate constant (which Sebastian provides).
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
writing to MPC55XX flash.
I sent it July 14 2014. Do I open a bug as well?
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
fully understand
the issue. I could just describe the bug as NFS does not honor nfsStBlksize
and submit it as that.
Does this make sense or is there a more fundamental bug at a different level?
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
On Sep 10, 2014, at 09:53 , Peter Dufault dufa...@hda.com wrote:
My client is having problems similar to that described here:
http://www.rtems.org/rtems/maillistArchives/rtems-users/2011/march/msg00228.html
I don't understand the details, or why one needs to limit the I/O size based
On Sep 11, 2014, at 07:47 , Peter Dufault dufa...@hda.com wrote:
So currently:
- I/O is not limited to the file system block size;
- The mounted block size is ignored and nfsStBlksize is used, which defaults
to 4K.
I meant 8K above. Anyway, looking through the code and the associated
8K can end up with
memory corruption. 512B works, 1K works, 2K and 4K corrupt things. The
changes are minor (attached).
If it's a bug for transfers to be larger than 4K when fa-blocksize=4K I can
look at that, that's easy to trap when it happens.
Peter
-
Peter Dufault
HD
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
/tinyxml2.o
textdata bss dec hex filename
41616 4 0 41620a294
/home/dufault/scratch/powerpc-unknown-rtems/phycore_mpc5554/tpsw/tinyxml2/tinyxml2.o
[dufault@litho9099 tinyxml2]$
OK, that's huge on some systems, but not on what I work on anymore.
- Url:
http
#elif MPC55XX_CHIP_FAMILY == 556
#define MPC55XX_IRQ_MAX 360U
#elif MPC55XX_CHIP_FAMILY == 567
#define MPC55XX_IRQ_MAX 479U
#else
#error unsupported chip type
#endif
The code will go on and step on a reserved area.
-
Peter Dufault
HD Associates, Inc
On Oct 13, 2014, at 15:22 , Peter Dufault dufa...@hda.com wrote:
This looks like an issue in the header. I downloaded the MPC5674F Reference
Manual and it does specify 479 interrupt request sources. See table 9-2,
INTC Memory Map
Base + (0x0040–0x0219) INTC_PSRn—INTC priority select
1 - 100 of 254 matches
Mail list logo
