On Fri, Dec 18, 2020, 2:55 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 18/12/2020 20:51, Ryan Long wrote:
>
> > Can someone explain this?
> These are link register values. The least significant bit determines if
> a bx instruction continues in ARM or Thumb mode.
>
I guess
On 18/12/20 10:24 pm, Sebastian Huber wrote:
> On 18/12/2020 11:35, Chris Johns wrote:
>
>>> Since all parts of RTEMS build now with waf I think it is possible to build
>>> RTEMS applications on Windows without having to install MSYS2/MinGW. It
>>> should work with only a Python installation, but
On 12/18/20 5:15 PM, Robin Müller wrote:
> Hi Jiri,
>
> Okay, I commented out that header on my Windows 10 machine (Version 20H2,
> 19042.685) and it compiled.
>
> That error was on a different Linux machine when cross compiling the cross
> toolchain for Windows (i686 rtems6-arm worked now, so t
On 18/12/2020 20:51, Ryan Long wrote:
Timestamp Channel CPU Event
type Contents TID Prio
PID Source
18:00:06.483 017 719 stream_0 0
FUNCTION_ENTRY code=0x104ec7 167837716
On 18/12/2020 20:51, Ryan Long wrote:
Can someone explain this?
These are link register values. The least significant bit determines if
a bx instruction continues in ARM or Thumb mode.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@emb
Hi,
We turned on gcc instrumentation with a test function, and got the following
records.
Timestamp Channel CPU Event type
Contents TID PrioPID
Source
18:00:06.483 017 719 stream
Hi Jiri,
Okay, I commented out that header on my Windows 10 machine (Version 20H2,
19042.685) and it compiled.
That error was on a different Linux machine when cross compiling the cross
toolchain for Windows (i686 rtems6-arm worked now, so that's nice). Maybe
this #define is also derived from the
On 12/18/20 2:10 PM, Robin Müller wrote:
> In case you're interested, this is the fail report for the SIS Cxc build on
> Linux (failed both for i686 and x86_64).
>
> I think it fails because _WIN32_WINNT (windows version) is not defined,
> causing winsock2.h to exclude requires sections.
>
> Bui
In case you're interested, this is the fail report for the SIS Cxc build on
Linux (failed both for i686 and x86_64).
I think it fails because _WIN32_WINNT (windows version) is not defined,
causing winsock2.h to exclude requires sections.
Build command was:
../source-builder/sb-set-builder
--pref
If I understand correctly, the BSPs can be installed with waf only if the
tool suite for the given architecture has been installed.
Problem is, the RSB build will fail even if a tiny component is
problematic.
I thought the tool suite itself is installed using the build commands
required by the sour
Hi,
I updated the RTEMS tickets with the patches for the Quick Start guide
(also neat that there is the comparison view):
BSP tests:
https://devel.rtems.org/ticket/4188
Python Encoding Error:
https://devel.rtems.org/ticket/4183
Some version 5/6 improvements / clarifications, also added how to w
On 18/12/2020 11:35, Chris Johns wrote:
Since all parts of RTEMS build now with waf I think it is possible to build
RTEMS applications on Windows without having to install MSYS2/MinGW. It should
work with only a Python installation, but I haven't tested this yet.
This maybe true In theory but
> On 18 Dec 2020, at 5:54 pm, Sebastian Huber
> wrote:
>
> Hello Robin,
>
> my experience over the years with MSYS2 is that building GCC is always
> painful and a waste of time.
This is a bit harsh and I do not fully agree it is a waste of time. MSYS has
proven to be an OK solution. Not pe
13 matches
Mail list logo
