Re: ZynqMP APU RAM Start

[Kinsey Moore]

On Tue, May 14, 2024 at 10:39 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 14.05.24 17:11, Kinsey Moore wrote:
> > On Tue, May 14, 2024 at 1:28 AM Chris Johns  > > wrote:
> >
> > On 14/5/2024 4:04 pm, Sebastian Huber wrote:
> >  > Hello,
> >  >
> >  > the ZynqMP APU RAM start addresses are far away from 0x0:
> >  >
> >  > cat spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
> >  > SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> >  > actions:
> >  > - get-integer: null
> >  > - assert-uint32: null
> >  > - env-assign: null
> >  > - format-and-define: null
> >  > build-type: option
> >  > copyrights:
> >  > - Copyright (C) 2020 On-Line Applications Research (OAR)
> >  > default:
> >  > - enabled-by:
> >  >   - aarch64/xilinx_zynqmp_lp64_a53
> >  >   - aarch64/xilinx_zynqmp_ilp32_zu3eg
> >  >   - aarch64/xilinx_zynqmp_lp64_cfc400x
> >  >   - aarch64/xilinx_zynqmp_lp64_zu3eg
> >  >   value: 0x1000
> >  > - enabled-by: true
> >  >   value: 0x40018000
> >  > description: |
> >  >   base address of memory area available to the BSP
> >  > enabled-by: true
> >  > format: '{:#010x}'
> >  > links: []
> >  > name: BSP_XILINX_ZYNQMP_RAM_BASE
> >  > type: build
> >  >
> >  > What is the rationale for doing this? Any objections to change
> > the start address
> >  > to 0x0?
> > Not from me but existing workflows will break. Some things to keep
> > in mind:
> >
> > What is the default address used by Linux on this board and what
> > uboot expects?
> >
> > What do the Xilinx tools default to?
> >
> > The load addresses here were taken from other examples when I was first
> > writing this port.
> >
> > The QEMU load address is largely irrelevant since it reads it from the
> > ELF headers and locates it appropriately without other constraints.
> >
> > The address used on hardware is due to u-boot typically loading at
> > 0x800, the RTEMS ELF being initially loaded in lower RAM space, and
> > then u-boot unpacking RTEMS into 0x1000. Everything can be moved
> > around, of course.
>
> Since the RPU cannot access the DDR RAM at 0x0, I suggest to locate the
> APU RAM at 0x0 and use half the size of the DDR RAM for the APU by
> default in the linker command file.
>

So the default RAM would be 256MB instead of the current 512MB. This seems
reasonable and should be sufficient for any tests I'm aware of.

Regarding moving the code to 0x0, that would break null pointer detection.
The vector table is currently mapped RWX due to AArch64 leaving room for 32
instructions per vector entry and the vector target being stored in that
space alongside the vector entry preamble. This could be made RX, but that
is work to be done.


> >
> >  > What is the MMU page size used by the BSPs? Would it be possible
> > to add a NULL
> >  > pointer protection page?
> > The MMU translation table page size is 4KB (0x1000) and the granularity
> > is also 4KB. This will likely need to become more flexible for modern
> > chips that drop 4K page size support as 16KB and 64KB become more
> > common. The 0x0 area is unmapped by default and so throws data aborts on
> > attempted access.
>
> Since these boards usually have lots of DDR RAM available, I would
> switch to a 64KiB page size to reduce the amount of page table reloads
> from RAM. This would waste 64KiB for the NULL pointer protection and up
> to 128KiB at the text/read-only and read-only/read-write boundaries.
>

The page table reloads required depend on how granular the mappings are.
Large block mappings will only consume a few upper level entries instead of
mapping each individual 4KB granule. RTEMS doesn't generally modify
mappings, so mappings generated by translation table walks will only rarely
be invalidated from the TLB. That said, supporting 64KB translation
granules is worth the effort given the direction newer chips are going.

Be aware that we can't move everything over to 64KB blindly as there is no
guarantee of support for any particular translation granule size; 4KB,
16KB, and 64KB are optionally and independently supported so any
combination could exist. ZynqMP in particular supports 4KB and 64KB
translation granules and I'm aware of at least 1 chip that only supports
16KB for practical purposes. QEMU's support for Cortex-A53 cores
contradicts the Cortex-A53 TRM on many points of MMU support suggesting
support of all granule sizes, wrong ASID size, and other issues though I'm
sure QEMU does actually support those modes of operation.

If support for dynamic detection and configuration of granule size is
desired, operation on QEMU will be even less representative of the ability
to run on real hardware.

Kinsey
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Fwd: GCC 13.3 Release Candidate available from gcc.gnu.org

[Joel Sherrill]

GCC is getting closer to a real release. When this drops, we need to switch
the RSB to it for 6 tools.

--joel

-- Forwarded message -
From: Jakub Jelinek via Gcc 
Date: Tue, May 14, 2024, 11:33 AM
Subject: GCC 13.3 Release Candidate available from gcc.gnu.org
To: 


The first release candidate for GCC 13.3 is available from

 https://gcc.gnu.org/pub/gcc/snapshots/13.3.0-RC-20240514/
 ftp://gcc.gnu.org/pub/gcc/snapshots/13.3.0-RC-20240514/

and shortly its mirrors.  It has been generated from git commit
r13-8774-g1db45e83021a8a.

I have so far bootstrapped and tested the release candidate on
x86_64-linux.
Please test it and report any issues to bugzilla.

If all goes well, we'd like to release 13.3 on Thursday, May 21st.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: ZynqMP APU RAM Start

[Sebastian Huber]

On 14.05.24 17:11, Kinsey Moore wrote:
On Tue, May 14, 2024 at 1:28 AM Chris Johns > wrote:


On 14/5/2024 4:04 pm, Sebastian Huber wrote:
 > Hello,
 >
 > the ZynqMP APU RAM start addresses are far away from 0x0:
 >
 > cat spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
 > SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
 > actions:
 > - get-integer: null
 > - assert-uint32: null
 > - env-assign: null
 > - format-and-define: null
 > build-type: option
 > copyrights:
 > - Copyright (C) 2020 On-Line Applications Research (OAR)
 > default:
 > - enabled-by:
 >   - aarch64/xilinx_zynqmp_lp64_a53
 >   - aarch64/xilinx_zynqmp_ilp32_zu3eg
 >   - aarch64/xilinx_zynqmp_lp64_cfc400x
 >   - aarch64/xilinx_zynqmp_lp64_zu3eg
 >   value: 0x1000
 > - enabled-by: true
 >   value: 0x40018000
 > description: |
 >   base address of memory area available to the BSP
 > enabled-by: true
 > format: '{:#010x}'
 > links: []
 > name: BSP_XILINX_ZYNQMP_RAM_BASE
 > type: build
 >
 > What is the rationale for doing this? Any objections to change
the start address
 > to 0x0?
Not from me but existing workflows will break. Some things to keep
in mind:

What is the default address used by Linux on this board and what
uboot expects?

What do the Xilinx tools default to?

The load addresses here were taken from other examples when I was first 
writing this port.


The QEMU load address is largely irrelevant since it reads it from the 
ELF headers and locates it appropriately without other constraints.


The address used on hardware is due to u-boot typically loading at 
0x800, the RTEMS ELF being initially loaded in lower RAM space, and 
then u-boot unpacking RTEMS into 0x1000. Everything can be moved 
around, of course.


Since the RPU cannot access the DDR RAM at 0x0, I suggest to locate the 
APU RAM at 0x0 and use half the size of the DDR RAM for the APU by 
default in the linker command file.




 > What is the MMU page size used by the BSPs? Would it be possible
to add a NULL
 > pointer protection page?

I am not sure.


The MMU translation table page size is 4KB (0x1000) and the granularity 
is also 4KB. This will likely need to become more flexible for modern 
chips that drop 4K page size support as 16KB and 64KB become more 
common. The 0x0 area is unmapped by default and so throws data aborts on 
attempted access.


Since these boards usually have lots of DDR RAM available, I would 
switch to a 64KiB page size to reduce the amount of page table reloads 
from RAM. This would waste 64KiB for the NULL pointer protection and up 
to 128KiB at the text/read-only and read-only/read-write boundaries.


--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: ZynqMP APU RAM Start

[Kinsey Moore]

On Tue, May 14, 2024 at 1:28 AM Chris Johns  wrote:

> On 14/5/2024 4:04 pm, Sebastian Huber wrote:
> > Hello,
> >
> > the ZynqMP APU RAM start addresses are far away from 0x0:
> >
> > cat spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
> > SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> > actions:
> > - get-integer: null
> > - assert-uint32: null
> > - env-assign: null
> > - format-and-define: null
> > build-type: option
> > copyrights:
> > - Copyright (C) 2020 On-Line Applications Research (OAR)
> > default:
> > - enabled-by:
> >   - aarch64/xilinx_zynqmp_lp64_a53
> >   - aarch64/xilinx_zynqmp_ilp32_zu3eg
> >   - aarch64/xilinx_zynqmp_lp64_cfc400x
> >   - aarch64/xilinx_zynqmp_lp64_zu3eg
> >   value: 0x1000
> > - enabled-by: true
> >   value: 0x40018000
> > description: |
> >   base address of memory area available to the BSP
> > enabled-by: true
> > format: '{:#010x}'
> > links: []
> > name: BSP_XILINX_ZYNQMP_RAM_BASE
> > type: build
> >
> > What is the rationale for doing this? Any objections to change the start
> address
> > to 0x0?
> Not from me but existing workflows will break. Some things to keep in mind:
>
> What is the default address used by Linux on this board and what uboot
> expects?
>
> What do the Xilinx tools default to?
>
> The load addresses here were taken from other examples when I was first
writing this port.

The QEMU load address is largely irrelevant since it reads it from the ELF
headers and locates it appropriately without other constraints.

The address used on hardware is due to u-boot typically loading at
0x800, the RTEMS ELF being initially loaded in lower RAM space, and
then u-boot unpacking RTEMS into 0x1000. Everything can be moved
around, of course.



> > What is the MMU page size used by the BSPs? Would it be possible to add
> a NULL
> > pointer protection page?
>
> I am not sure.
>

The MMU translation table page size is 4KB (0x1000) and the granularity is
also 4KB. This will likely need to become more flexible for modern chips
that drop 4K page size support as 16KB and 64KB become more common. The 0x0
area is unmapped by default and so throws data aborts on attempted access.

Kinsey
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

[Michal Lenc]

Hello Christian,

thank you for the thorough review. I am currently at the international
CAN Conference at Baden-Baden, so I will address this once I return by
the end of the week.

Best regards,

Michal Lenc

On 14. 05. 24 10:10, Christian MAUDERER wrote:
> On 2024-05-13 17:40, Christian MAUDERER wrote:
>> Hello Pavel and Michal,
>>
>> sorry for the late reply. I was on vacation last week.
>>
>> On 2024-05-06 11:27, Pavel Pisa wrote:
>>> Dear Christian,
>>>
>>> On Tuesday 30 of April 2024 08:40:43 Christian MAUDERER wrote:
> For others, code under review hosted in CTU university GitLab
> server
>     https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd
> Documentation
>    
> https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/can/can-html/can.html
>    
> https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/index.html
>
> Main developer behind extension to CAN FD and switch to RTEMS
> is Michal Lenc.
>
> The intention is to (hopefully) reach state when it meets criteria
> to mainlining int RTEMS CPU kit under
>
>     cpukit/dev/can
>>> ...
> I agree, that it is compromise. But adding yet another file
> descriptor
> like multiplexor for queues to each file descriptor seems to me as
> too much complexity. But it can be added. even later as IOCTL to
> remove
> individual queues based on CAN ID matches or queues IDs if create
> is modified to return internal queue IDs...

 I somehow missed that you can open the device multiple times and get
 independent queues. With that, it's completely OK and should be
 flexible
 enough for most applications.

 It's great that you already have put some thought into how it could be
 extended later if some application needs more flexibility.
>>> ...
>> Did you check with
>> some other hardware controller, whether the whole structures /
>> defines
>> / flags close to the hardware do work well for other controllers
>> too?
>
> The code/concept is based on my previous LinCAN and OrtCAN work
>
> https://ortcan.sourceforge.net/lincan/
>>> ...
 I didn't want to doubt your competence. Like I said it's some trap
 that
 I have fallen into often enough myself (like when guiding Prashanths
 GSoC project). But it's clear that you have put a lot of thought into
 that. So I would expect that there shouldn't be much trouble with most
 controllers. Maybe except for the ones where a semiconductor vendor
 thought it would be a good idea to create a completely different
 concept. But these are always difficult.
>>>
>>> I agree with discussion and searching for hard arguments.
>>>
>>> The solution is compromise and in general CAN bus concept
>>> is optimized for direct replacement of wires in car
>>> going between distinc units and its use as general
>>> communication solution has some difficulties and requires
>>> some compromises.
>>>
>>> For small devices with predefined purpose and Autosar,
>>> it is ideal to allocate for each CAN ID (wire signal)
>>> to be sent one communication object on the controller.
>>> Same for each received signal value or their set in the
>>> single frame. The most controllers are equipped by filters
>>> and mechanism to do so including selection of the
>>> Tx message object for physical bus-link arbitration
>>> according to the priority. Then sending side updates
>>> signal value in corresponding Tx object and receiving
>>> side sees most actual one usually on the best effort basis,
>>> older unread frames are overwritten by updated value.
>>>
>>> But even in simple ECU, there are obstacles to use this
>>> principle in all kind of the communication. CAN bus is used
>>> for firmware updates and general configuration. In this
>>> case, the reliable delivery of all messages with given
>>> CAN ID is required because whole sequence has to be
>>> received and processed and the state evolution is associated
>>> to the sequence. If a single message is lost, then all
>>> data are unusable. Because sequence requires exact ordering
>>> it is typical that only single Tx object is used. On Rx
>>> side there can be problem to capture all frames without
>>> overwrite by single Rx object so some controllers ad FIFO
>>> which can be attached to each object or some mechanism
>>> how to allocate more Rx objects and pass them to the user
>>> in FIFO order.
>>>
>>> That works for small ECUs with single purpose firmware.
>>> But on general purpose operating system which should
>>> allow even complete monitoring of the CAN bus, allows
>>> dynamically started applications and even whole virtual
>>> CAN/CANopen nodes, allocation the controller Tx/Rx message
>>> objects for each specific purpose is impossible.
>>>
>>> That is why all generic CAN subsystems which I know
>>> (CAN4Linux, LinCAN, SockteCAN, NuttX char device CAN,
>>> windows Peak's drivers etc.) define API based on
>>> 

Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation

[Christian MAUDERER]

On 2024-05-13 17:40, Christian MAUDERER wrote:

Hello Pavel and Michal,

sorry for the late reply. I was on vacation last week.

On 2024-05-06 11:27, Pavel Pisa wrote:

Dear Christian,

On Tuesday 30 of April 2024 08:40:43 Christian MAUDERER wrote:

For others, code under review hosted in CTU university GitLab
server
    https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd
Documentation

https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/can/can-html/can.html

https://otrees.pages.fel.cvut.cz/rtems/rtems-canfd/doc/doxygen/html/index.html


Main developer behind extension to CAN FD and switch to RTEMS
is Michal Lenc.

The intention is to (hopefully) reach state when it meets criteria
to mainlining int RTEMS CPU kit under

    cpukit/dev/can

...

I agree, that it is compromise. But adding yet another file descriptor
like multiplexor for queues to each file descriptor seems to me as
too much complexity. But it can be added. even later as IOCTL to remove
individual queues based on CAN ID matches or queues IDs if create
is modified to return internal queue IDs...


I somehow missed that you can open the device multiple times and get
independent queues. With that, it's completely OK and should be flexible
enough for most applications.

It's great that you already have put some thought into how it could be
extended later if some application needs more flexibility.

...

Did you check with
some other hardware controller, whether the whole structures / defines
/ flags close to the hardware do work well for other controllers too?


The code/concept is based on my previous LinCAN and OrtCAN work

https://ortcan.sourceforge.net/lincan/

...

I didn't want to doubt your competence. Like I said it's some trap that
I have fallen into often enough myself (like when guiding Prashanths
GSoC project). But it's clear that you have put a lot of thought into
that. So I would expect that there shouldn't be much trouble with most
controllers. Maybe except for the ones where a semiconductor vendor
thought it would be a good idea to create a completely different
concept. But these are always difficult.


I agree with discussion and searching for hard arguments.

The solution is compromise and in general CAN bus concept
is optimized for direct replacement of wires in car
going between distinc units and its use as general
communication solution has some difficulties and requires
some compromises.

For small devices with predefined purpose and Autosar,
it is ideal to allocate for each CAN ID (wire signal)
to be sent one communication object on the controller.
Same for each received signal value or their set in the
single frame. The most controllers are equipped by filters
and mechanism to do so including selection of the
Tx message object for physical bus-link arbitration
according to the priority. Then sending side updates
signal value in corresponding Tx object and receiving
side sees most actual one usually on the best effort basis,
older unread frames are overwritten by updated value.

But even in simple ECU, there are obstacles to use this
principle in all kind of the communication. CAN bus is used
for firmware updates and general configuration. In this
case, the reliable delivery of all messages with given
CAN ID is required because whole sequence has to be
received and processed and the state evolution is associated
to the sequence. If a single message is lost, then all
data are unusable. Because sequence requires exact ordering
it is typical that only single Tx object is used. On Rx
side there can be problem to capture all frames without
overwrite by single Rx object so some controllers ad FIFO
which can be attached to each object or some mechanism
how to allocate more Rx objects and pass them to the user
in FIFO order.

That works for small ECUs with single purpose firmware.
But on general purpose operating system which should
allow even complete monitoring of the CAN bus, allows
dynamically started applications and even whole virtual
CAN/CANopen nodes, allocation the controller Tx/Rx message
objects for each specific purpose is impossible.

That is why all generic CAN subsystems which I know
(CAN4Linux, LinCAN, SockteCAN, NuttX char device CAN,
windows Peak's drivers etc.) define API based on
opening driver and presenting received messages
in FIFO order to application (with options for software
filtering but usually not propagated to controller,
HW - LinCAN has some option to union user FIFOs to
mask and ID propagated to HW, but you usually end with
fully end with need to receve all anyway and it has not been
used at the end). The Tx FIFO order is required for messages
with same ID or even sometimes between same stream of mesages
even wit altering ID for correct realization of some higher
level protocols.

The result is that even on hardware equipped with multiple
Tx objects but without special Tx FIFO order preserving
cyclic queue only single Tx object is used to realize
transmission of all messages, for 

Re: ZynqMP APU RAM Start

[Chris Johns]

On 14/5/2024 4:04 pm, Sebastian Huber wrote:
> Hello,
> 
> the ZynqMP APU RAM start addresses are far away from 0x0:
> 
> cat spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
> SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> actions:
> - get-integer: null
> - assert-uint32: null
> - env-assign: null
> - format-and-define: null
> build-type: option
> copyrights:
> - Copyright (C) 2020 On-Line Applications Research (OAR)
> default:
> - enabled-by:
>   - aarch64/xilinx_zynqmp_lp64_a53
>   - aarch64/xilinx_zynqmp_ilp32_zu3eg
>   - aarch64/xilinx_zynqmp_lp64_cfc400x
>   - aarch64/xilinx_zynqmp_lp64_zu3eg
>   value: 0x1000
> - enabled-by: true
>   value: 0x40018000
> description: |
>   base address of memory area available to the BSP
> enabled-by: true
> format: '{:#010x}'
> links: []
> name: BSP_XILINX_ZYNQMP_RAM_BASE
> type: build
> 
> What is the rationale for doing this? Any objections to change the start 
> address
> to 0x0?
Not from me but existing workflows will break. Some things to keep in mind:

What is the default address used by Linux on this board and what uboot expects?

What do the Xilinx tools default to?

> What is the MMU page size used by the BSPs? Would it be possible to add a NULL
> pointer protection page?

I am not sure.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

ZynqMP APU RAM Start

[Sebastian Huber]

Hello,

the ZynqMP APU RAM start addresses are far away from 0x0:

cat spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
actions:
- get-integer: null
- assert-uint32: null
- env-assign: null
- format-and-define: null
build-type: option
copyrights:
- Copyright (C) 2020 On-Line Applications Research (OAR)
default:
- enabled-by:
  - aarch64/xilinx_zynqmp_lp64_a53
  - aarch64/xilinx_zynqmp_ilp32_zu3eg
  - aarch64/xilinx_zynqmp_lp64_cfc400x
  - aarch64/xilinx_zynqmp_lp64_zu3eg
  value: 0x1000
- enabled-by: true
  value: 0x40018000
description: |
  base address of memory area available to the BSP
enabled-by: true
format: '{:#010x}'
links: []
name: BSP_XILINX_ZYNQMP_RAM_BASE
type: build

What is the rationale for doing this? Any objections to change the start 
address to 0x0?


What is the MMU page size used by the BSPs? Would it be possible to add 
a NULL pointer protection page?


--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel