> 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
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
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
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
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
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
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
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
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
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 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/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 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
13 matches
Mail list logo
