Re: [PATCH] Arm/raspberrypi.h: Added relevant headers for the bcm2711
Joel, I don't think we need to commit the file now.
Some suggestions:
- Let's not put RPI2 or RPI3 defines or ifdefs in the file if it's only
going to be for the Aarch64 RPI4 BSP
- If it will be only used for the RPI4, it might be confusing to have the
BCM2836 defines rather than using BCM2711
- If we really can share most of the defines between the RPI2 and RPI4
bsps, is there any way we can have a common include in the bsps/shared
directory? Something like bcm_soc.h that has common defines for all
raspberry Pi models? That would require changes to the Raspberry Pi 1 and 2
BSPs but it would avoid duplication of code.
I also wonder if we can end up taking advantage of shared drivers such as
the pl011 serial driver.
Another source of info that may be helpful is the RT-Thread RTOS. They have
RPI 2, 3, and 4 BSPs. The RPI4 has 32 and 64 bit versions. In addition the
RTOS is Apache 2.0 licensed, so that may be easier to re-use (Please
correct me if I'm wrong on the license usage!)
https://github.com/RT-Thread/rt-thread/tree/master/bsp/raspberry-pi/raspi4-64
Thanks,
Alan
On Thu, Jul 21, 2022 at 2:01 PM Joel Sherrill wrote:
>
>
> On Thu, Jul 21, 2022 at 12:32 PM Noor Aman wrote:
>
>> I dont think this would be visible to any other application until or
>> unless user explicitly include this header 'raspberrypi.h' in their
>> application. And as of now, this header is only placed in
>> bsps/arm/raspberrypi/includes.
>>
>
> Sorry. My mistake. I was thinking it was in bsp.h. :(
>
>
>> For my project I'm thinking of using this header with my project with
>> bcm2711 addresses included. For my project, this header will go under
>> bsps/aarch64/raspberrypi/includes. So I don't think this will create any
>> problem for other BSPs.
>>
>
> This will be ok. A file has to explicitly include it.
>
> If you think it is ready to commit, I'm happy to do it if Alan or someone
> else also acks.
>
> --joel
>
>>
>> On Thu, Jul 21, 2022, 10:16 PM Joel Sherrill wrote:
>>
>>> This looks generally ok but is all this visible to any application that
>>> includes bsp.h?
>>>
>>> It might all need to be moved into a separate header to avoid
>>> contaminating everyone's namespace.
>>>
>>> On Thu, Jul 21, 2022, 10:56 AM Noor Aman wrote:
>>>
A brief gist of what i found compatible with the older code
---COMPATIBLE HEADER---
- BCM2835 timer
- GPIO
- AUX
- GPU timer
---DIDNT CHECK---
- SPI
- I2C
---MINOR CHNAGE---
- IRQ
- FIQ
---NOT SURE ABOUT---
- Watchdog
- Power management
- Mailbox register
I didnt get any info about power management or watchdog or mailboxes.
(It isnt in the BCM2835 Documention too I think??)
And to answer your question Alan about if the Aarch64 would require a
DTB or not which you asked me quite earlier. I can say now, you dont,
because every address is defined here already so no need for the DTB.
diff --git a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
index eeb48c42f1..a4ed2a01d1 100644
--- a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
+++ b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
@@ -52,15 +52,23 @@
* @{
*/
-#if (BSP_IS_RPI2 == 1)
- #define RPI_PERIPHERAL_BASE0x3F00
+#if (RPI_BSP == RPI2)
+ #define RPI_PERIPHERAL_BASE0X3F00
#define BASE_OFFSET0X3F00
+
+#elif (RPI_BSP == RPI4)
+ #define RPI_PERIPHERAL_BASE 0xFE00
+ #define BASE_OFFSET 0xFE00
+ #define RPI_PERIPHERAL_SIZE0x0180
+
#else
#define RPI_PERIPHERAL_BASE0x2000
#define BASE_OFFSET0X5E00
+
#endif
-#define RPI_PERIPHERAL_SIZE 0x0100
+#ifndef RPI_PERIPHERAL_SIZE
+#define RPI_PERIPHERAL_SIZE 0x0100
/**
* @name Bus to Physical address translation
@@ -543,6 +551,188 @@
#define BCM2836_IRQ_SOURCE_PMU0x0200
#define BCM2836_IRQ_SOURCE_LOCAL_TIMER0x0800
+
+
+/**
+ * @name Raspberry Pi 4 ARM_LOCAL registers
+ *
+ * @{
+ */
+
+#define BCM2711_LOCAL_REGS_BASE 0x4C000
+
+#define BCM2711_LOCAL_ARM_CONTROL (BCM2711_LOCAL_REGS_BASE + 0x00)
+#define BCM2711_LOCAL_CORE_IRQ_CONTROL (BCM2711_LOCAL_REGS_BASE + 0x0c)
+#define BCM2711_LOCAL_PMU_CONTROL_SET (BCM2711_LOCAL_REGS_BASE + 0x10)
+#define BCM2711_LOCAL_PMU_CONTROL_CLR (BCM2711_LOCAL_REGS_BASE + 0x14)
+#define BCM2711_LOCAL_PERI_IRQ_ROUTE0 (BCM2711_LOCAL_REGS_BASE + 0x24)
+#define BCM2711_LOCAL_AXI_QUIET_TIME (BCM2711_LOCAL_REGS_BASE + 0x30)
+#define BCM2711_LOCAL_LOCAL_TIMER_CONTROL (BCM2711_LOCAL_REGS_BASE +
0x34)
+#define BCM2711_LOCAL_LOCAL_TIMER_IRQ (BCM2711_LOCAL_REGS_BASE +
0x38)
+
Re: [PATCH] Arm/raspberrypi.h: Added relevant headers for the bcm2711
Sorry for that. I wanted a review for this so that's why included the gist too. I think instead of writing as a patch, I'll be using review. Thank you for the info. On Fri, Jul 22, 2022, 8:14 AM Chris Johns wrote: > On 22/7/2022 12:42 pm, Chris Johns wrote: > > On 22/7/2022 1:55 am, Noor Aman wrote: > >> A brief gist of what i found compatible with the older code > >> ---COMPATIBLE HEADER--- > >> - BCM2835 timer > >> - GPIO > >> - AUX > >> - GPU timer > >> ---DIDNT CHECK--- > >> - SPI > >> - I2C > >> ---MINOR CHNAGE--- > >> - IRQ > >> - FIQ > >> ---NOT SURE ABOUT--- > >> - Watchdog > >> - Power management > >> - Mailbox register > >> > >> I didnt get any info about power management or watchdog or mailboxes. > (It isnt > >> in the BCM2835 Documention too I think??) > >> > >> And to answer your question Alan about if the Aarch64 would require a > DTB or not > >> which you asked me quite earlier. I can say now, you dont, because > every address > >> is defined here already so no need for the DTB. > > > > Is this a commit message? > > > > Is not think a conversation suites a commit message. > > Sorry, that should read "I do not think ..." > > Chris > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Arm/raspberrypi.h: Added relevant headers for the bcm2711
On 22/7/2022 12:42 pm, Chris Johns wrote: > On 22/7/2022 1:55 am, Noor Aman wrote: >> A brief gist of what i found compatible with the older code >> ---COMPATIBLE HEADER--- >> - BCM2835 timer >> - GPIO >> - AUX >> - GPU timer >> ---DIDNT CHECK--- >> - SPI >> - I2C >> ---MINOR CHNAGE--- >> - IRQ >> - FIQ >> ---NOT SURE ABOUT--- >> - Watchdog >> - Power management >> - Mailbox register >> >> I didnt get any info about power management or watchdog or mailboxes. (It >> isnt >> in the BCM2835 Documention too I think??) >> >> And to answer your question Alan about if the Aarch64 would require a DTB or >> not >> which you asked me quite earlier. I can say now, you dont, because every >> address >> is defined here already so no need for the DTB. > > Is this a commit message? > > Is not think a conversation suites a commit message. Sorry, that should read "I do not think ..." Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Arm/raspberrypi.h: Added relevant headers for the bcm2711
On 22/7/2022 1:55 am, Noor Aman wrote: > A brief gist of what i found compatible with the older code > ---COMPATIBLE HEADER--- > - BCM2835 timer > - GPIO > - AUX > - GPU timer > ---DIDNT CHECK--- > - SPI > - I2C > ---MINOR CHNAGE--- > - IRQ > - FIQ > ---NOT SURE ABOUT--- > - Watchdog > - Power management > - Mailbox register > > I didnt get any info about power management or watchdog or mailboxes. (It isnt > in the BCM2835 Documention too I think??) > > And to answer your question Alan about if the Aarch64 would require a DTB or > not > which you asked me quite earlier. I can say now, you dont, because every > address > is defined here already so no need for the DTB. Is this a commit message? Is not think a conversation suites a commit message. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip] README: Add build instruction
On 22/7/2022 8:59 am, Vijay Kumar Banerjee wrote: > Patch pushed. The repository is working, and I see the commit email in vc. Nice. Thanks for the feedback. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip] README: Add build instruction
Patch pushed. The repository is working, and I see the commit email in vc. Thanks, Vijay On Thu, Jul 21, 2022 at 2:06 PM Vijay Kumar Banerjee wrote: > > I will push this patch. The main intention of this patch is to test > the new top-level repo, but it also provides some essential build > instructions which will certainly be handy. > > On Thu, Jul 21, 2022 at 2:05 PM Vijay Kumar Banerjee wrote: > > > > Hi Kinsey, > > > > thanks for the review > > > > On Thu, Jul 21, 2022 at 1:50 PM Kinsey Moore > > wrote: > > > > > > Looks good to me. I never realized that the list of BSPs and tools > > > directory could be omitted if things were installed in particular > > > locations. > > > > > Yes, it picks up all the installed BSPs if there is that option is not > > used. using the BSP argument only builds the mentioned bsps. > > > > > > Best regards, > > Vijay > > > On 7/21/2022 14:16, Vijay Kumar Banerjee wrote: > > > > --- > > > > README | 18 ++ > > > > 1 file changed, 18 insertions(+) > > > > > > > > diff --git a/README b/README > > > > index 91e42ae..99800bf 100644 > > > > --- a/README > > > > +++ b/README > > > > @@ -12,3 +12,21 @@ The sources presented here originate in one of > > > > several locations described by > > > > the ORIGIN.* files and whose license is described by the COPYING.* > > > > files. > > > > Commits adding such files should include the hash of the target > > > > repository if > > > > applicable. > > > > + > > > > +Installation Instructions > > > > +- > > > > +1. Populate the git submodules: > > > > + > > > > +``` > > > > +git submodule init > > > > +git submodule update > > > > +``` > > > > +2. Configure and build > > > > +``` > > > > +./waf configure --prefix=INSTALL_PREFIX > > > > +./waf > > > > +./waf install > > > > +``` > > > > + > > > > +More `waf` arguments can be found by using: > > > > +`./waf --help` > > > ___ > > > devel mailing list > > > devel@rtems.org > > > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v1 3/5] cpukit/libdl: Add support for AArch64
On 22/7/2022 1:11 am, Ryan Long wrote:
> On 7/20/2022 11:39 PM, Chris Johns wrote:
>> On 21/7/2022 7:36 am, Ryan Long wrote:
>>> rtl-mdreloc-aarch64.c and elf_machdep.h came from NetBSD.
>>> +bool
>>> +rtems_rtl_elf_unwind_deregister (rtems_rtl_obj* obj)
>>> +{
>>> + obj->loader = NULL;
>> You cannot touch this field. It belongs to the format loader.
> I copied this method from rtl-mdreloc-arm.c, and it's the same way there.
I think it is wrong in both places.
Should these calls also be moved to rtl-unwind-arm.[ch]?
>>> +_Unwind_Ptr __gnu_Unwind_Find_exidx (_Unwind_Ptr return_address,
>>> + int* nrec)
>>> +{
>>> + rtems_rtl_data* rtl;
>>> + rtems_chain_node* node;
>>> + __EIT_entry* exidx_start = &__exidx_start;
>>> + __EIT_entry* exidx_end = &__exidx_end;
>>> +
>>> + rtl = rtems_rtl_lock ();
>>> +
>>> + node = rtems_chain_first (>objects);
>>> + while (!rtems_chain_is_tail (>objects, node)) {
>>> + rtems_rtl_obj* obj = (rtems_rtl_obj*) node;
>>> + if (rtems_rtl_obj_text_inside (obj, (void*) return_address)) {
>>> + exidx_start = (__EIT_entry*) obj->eh_base;
>>> + exidx_end = (__EIT_entry*) (obj->eh_base + obj->eh_size);
>>> + break;
>>> + }
>>> + node = rtems_chain_next (node);
>>> + }
>> Can the RTL chain iterator be used here?
> I got this from rtl-mdreloc-arm.c.
I think using the iterator would a good change once the code moves.
>>> +
>>> + rtems_rtl_unlock ();
>>> +
>>> + *nrec = exidx_end - exidx_start;
>>> +
>>> + return (_Unwind_Ptr) exidx_start;
>>> +}
>> Can this exception unwind support be placed in rtl-unwind-arm.[ch]?
>>
>> I suppose you will need to reference the call from here to bring the symbol
>> into
>> the link and override the weak version in gcc?
>>
>> Chris
> Is it alright if I implement this and take it out of rtl-mdreloc-aarch64.c and
> rtl-mdreloc-arm.c in a follow up patch?
Of course and thanks.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip] README: Add build instruction
I will push this patch. The main intention of this patch is to test the new top-level repo, but it also provides some essential build instructions which will certainly be handy. On Thu, Jul 21, 2022 at 2:05 PM Vijay Kumar Banerjee wrote: > > Hi Kinsey, > > thanks for the review > > On Thu, Jul 21, 2022 at 1:50 PM Kinsey Moore wrote: > > > > Looks good to me. I never realized that the list of BSPs and tools > > directory could be omitted if things were installed in particular locations. > > > Yes, it picks up all the installed BSPs if there is that option is not > used. using the BSP argument only builds the mentioned bsps. > > > Best regards, > Vijay > > On 7/21/2022 14:16, Vijay Kumar Banerjee wrote: > > > --- > > > README | 18 ++ > > > 1 file changed, 18 insertions(+) > > > > > > diff --git a/README b/README > > > index 91e42ae..99800bf 100644 > > > --- a/README > > > +++ b/README > > > @@ -12,3 +12,21 @@ The sources presented here originate in one of several > > > locations described by > > > the ORIGIN.* files and whose license is described by the COPYING.* > > > files. > > > Commits adding such files should include the hash of the target > > > repository if > > > applicable. > > > + > > > +Installation Instructions > > > +- > > > +1. Populate the git submodules: > > > + > > > +``` > > > +git submodule init > > > +git submodule update > > > +``` > > > +2. Configure and build > > > +``` > > > +./waf configure --prefix=INSTALL_PREFIX > > > +./waf > > > +./waf install > > > +``` > > > + > > > +More `waf` arguments can be found by using: > > > +`./waf --help` > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip] README: Add build instruction
Hi Kinsey, thanks for the review On Thu, Jul 21, 2022 at 1:50 PM Kinsey Moore wrote: > > Looks good to me. I never realized that the list of BSPs and tools > directory could be omitted if things were installed in particular locations. > Yes, it picks up all the installed BSPs if there is that option is not used. using the BSP argument only builds the mentioned bsps. Best regards, Vijay > On 7/21/2022 14:16, Vijay Kumar Banerjee wrote: > > --- > > README | 18 ++ > > 1 file changed, 18 insertions(+) > > > > diff --git a/README b/README > > index 91e42ae..99800bf 100644 > > --- a/README > > +++ b/README > > @@ -12,3 +12,21 @@ The sources presented here originate in one of several > > locations described by > > the ORIGIN.* files and whose license is described by the COPYING.* files. > > Commits adding such files should include the hash of the target > > repository if > > applicable. > > + > > +Installation Instructions > > +- > > +1. Populate the git submodules: > > + > > +``` > > +git submodule init > > +git submodule update > > +``` > > +2. Configure and build > > +``` > > +./waf configure --prefix=INSTALL_PREFIX > > +./waf > > +./waf install > > +``` > > + > > +More `waf` arguments can be found by using: > > +`./waf --help` > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip] README: Add build instruction
Looks good to me. I never realized that the list of BSPs and tools directory could be omitted if things were installed in particular locations. On 7/21/2022 14:16, Vijay Kumar Banerjee wrote: --- README | 18 ++ 1 file changed, 18 insertions(+) diff --git a/README b/README index 91e42ae..99800bf 100644 --- a/README +++ b/README @@ -12,3 +12,21 @@ The sources presented here originate in one of several locations described by the ORIGIN.* files and whose license is described by the COPYING.* files. Commits adding such files should include the hash of the target repository if applicable. + +Installation Instructions +- +1. Populate the git submodules: + +``` +git submodule init +git submodule update +``` +2. Configure and build +``` +./waf configure --prefix=INSTALL_PREFIX +./waf +./waf install +``` + +More `waf` arguments can be found by using: +`./waf --help` ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip] README: Add build instruction
On 7/21/2022 14:16, Vijay Kumar Banerjee wrote: --- README | 18 ++ 1 file changed, 18 insertions(+) diff --git a/README b/README index 91e42ae..99800bf 100644 --- a/README +++ b/README @@ -12,3 +12,21 @@ The sources presented here originate in one of several locations described by the ORIGIN.* files and whose license is described by the COPYING.* files. Commits adding such files should include the hash of the target repository if applicable. + +Installation Instructions +- +1. Populate the git submodules: + +``` +git submodule init +git submodule update +``` +2. Configure and build +``` +./waf configure --prefix=INSTALL_PREFIX Can this be run without specifying which BSPs it's being configured for? I've only ever configured it with an explicit list. +./waf +./waf install +``` + +More `waf` arguments can be found by using: +`./waf --help` ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-lwip] README: Add build instruction
--- README | 18 ++ 1 file changed, 18 insertions(+) diff --git a/README b/README index 91e42ae..99800bf 100644 --- a/README +++ b/README @@ -12,3 +12,21 @@ The sources presented here originate in one of several locations described by the ORIGIN.* files and whose license is described by the COPYING.* files. Commits adding such files should include the hash of the target repository if applicable. + +Installation Instructions +- +1. Populate the git submodules: + +``` +git submodule init +git submodule update +``` +2. Configure and build +``` +./waf configure --prefix=INSTALL_PREFIX +./waf +./waf install +``` + +More `waf` arguments can be found by using: +`./waf --help` -- 2.34.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Arm/raspberrypi.h: Added relevant headers for the bcm2711
On Thu, Jul 21, 2022 at 12:32 PM Noor Aman wrote:
> I dont think this would be visible to any other application until or
> unless user explicitly include this header 'raspberrypi.h' in their
> application. And as of now, this header is only placed in
> bsps/arm/raspberrypi/includes.
>
Sorry. My mistake. I was thinking it was in bsp.h. :(
> For my project I'm thinking of using this header with my project with
> bcm2711 addresses included. For my project, this header will go under
> bsps/aarch64/raspberrypi/includes. So I don't think this will create any
> problem for other BSPs.
>
This will be ok. A file has to explicitly include it.
If you think it is ready to commit, I'm happy to do it if Alan or someone
else also acks.
--joel
>
> On Thu, Jul 21, 2022, 10:16 PM Joel Sherrill wrote:
>
>> This looks generally ok but is all this visible to any application that
>> includes bsp.h?
>>
>> It might all need to be moved into a separate header to avoid
>> contaminating everyone's namespace.
>>
>> On Thu, Jul 21, 2022, 10:56 AM Noor Aman wrote:
>>
>>> A brief gist of what i found compatible with the older code
>>> ---COMPATIBLE HEADER---
>>> - BCM2835 timer
>>> - GPIO
>>> - AUX
>>> - GPU timer
>>> ---DIDNT CHECK---
>>> - SPI
>>> - I2C
>>> ---MINOR CHNAGE---
>>> - IRQ
>>> - FIQ
>>> ---NOT SURE ABOUT---
>>> - Watchdog
>>> - Power management
>>> - Mailbox register
>>>
>>> I didnt get any info about power management or watchdog or mailboxes.
>>> (It isnt in the BCM2835 Documention too I think??)
>>>
>>> And to answer your question Alan about if the Aarch64 would require a
>>> DTB or not which you asked me quite earlier. I can say now, you dont,
>>> because every address is defined here already so no need for the DTB.
>>>
>>>
>>>
>>> diff --git a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
>>> b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
>>> index eeb48c42f1..a4ed2a01d1 100644
>>> --- a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
>>> +++ b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
>>> @@ -52,15 +52,23 @@
>>> * @{
>>> */
>>>
>>> -#if (BSP_IS_RPI2 == 1)
>>> - #define RPI_PERIPHERAL_BASE0x3F00
>>> +#if (RPI_BSP == RPI2)
>>> + #define RPI_PERIPHERAL_BASE0X3F00
>>>#define BASE_OFFSET0X3F00
>>> +
>>> +#elif (RPI_BSP == RPI4)
>>> + #define RPI_PERIPHERAL_BASE 0xFE00
>>> + #define BASE_OFFSET 0xFE00
>>> + #define RPI_PERIPHERAL_SIZE0x0180
>>> +
>>> #else
>>>#define RPI_PERIPHERAL_BASE0x2000
>>>#define BASE_OFFSET0X5E00
>>> +
>>> #endif
>>>
>>> -#define RPI_PERIPHERAL_SIZE 0x0100
>>> +#ifndef RPI_PERIPHERAL_SIZE
>>> +#define RPI_PERIPHERAL_SIZE 0x0100
>>>
>>> /**
>>> * @name Bus to Physical address translation
>>> @@ -543,6 +551,188 @@
>>> #define BCM2836_IRQ_SOURCE_PMU0x0200
>>> #define BCM2836_IRQ_SOURCE_LOCAL_TIMER0x0800
>>>
>>> +
>>> +
>>> +/**
>>> + * @name Raspberry Pi 4 ARM_LOCAL registers
>>> + *
>>> + * @{
>>> + */
>>> +
>>> +#define BCM2711_LOCAL_REGS_BASE 0x4C000
>>> +
>>> +#define BCM2711_LOCAL_ARM_CONTROL (BCM2711_LOCAL_REGS_BASE + 0x00)
>>> +#define BCM2711_LOCAL_CORE_IRQ_CONTROL (BCM2711_LOCAL_REGS_BASE + 0x0c)
>>> +#define BCM2711_LOCAL_PMU_CONTROL_SET (BCM2711_LOCAL_REGS_BASE + 0x10)
>>> +#define BCM2711_LOCAL_PMU_CONTROL_CLR (BCM2711_LOCAL_REGS_BASE + 0x14)
>>> +#define BCM2711_LOCAL_PERI_IRQ_ROUTE0 (BCM2711_LOCAL_REGS_BASE + 0x24)
>>> +#define BCM2711_LOCAL_AXI_QUIET_TIME (BCM2711_LOCAL_REGS_BASE + 0x30)
>>> +#define BCM2711_LOCAL_LOCAL_TIMER_CONTROL (BCM2711_LOCAL_REGS_BASE +
>>> 0x34)
>>> +#define BCM2711_LOCAL_LOCAL_TIMER_IRQ (BCM2711_LOCAL_REGS_BASE +
>>> 0x38)
>>> +
>>> +#define BCM2711_LOCAL_TIMER_CNTRL0 (BCM2711_LOCAL_REGS_BASE +
>>> 0x40)
>>> +#define BCM2711_LOCAL_TIMER_CNTRL1 (BCM2711_LOCAL_REGS_BASE + 0x44)
>>> +#define BCM2711_LOCAL_TIMER_CNTRL2 (BCM2711_LOCAL_REGS_BASE + 0x48)
>>> +#define BCM2711_LOCAL_TIMER_CNTRL3 (BCM2711_LOCAL_REGS_BASE + 0x4c)
>>> +
>>> +#define BCM2711_LOCAL_MAILBOX_CNTRL0 (BCM2711_LOCAL_REGS_BASE + 0x50)
>>> +#define BCM2711_LOCAL_MAILBOX_CNTRL1 (BCM2711_LOCAL_REGS_BASE + 0x54)
>>> +#define BCM2711_LOCAL_MAILBOX_CNTRL2 (BCM2711_LOCAL_REGS_BASE + 0x58)
>>> +#define BCM2711_LOCAL_MAILBOX_CNTRL3 (BCM2711_LOCAL_REGS_BASE + 0x5c)
>>> +
>>> +#define BCM2711_LOCAL_IRQ_SOURCE0 (BCM2711_LOCAL_REGS_BASE + 0x60)
>>> +#define BCM2711_LOCAL_IRQ_SOURCE1 (BCM2711_LOCAL_REGS_BASE + 0x64)
>>> +#define BCM2711_LOCAL_IRQ_SOURCE2 (BCM2711_LOCAL_REGS_BASE + 0x68)
>>> +#define BCM2711_LOCAL_IRQ_SOURCE3 (BCM2711_LOCAL_REGS_BASE + 0x6c)
>>> +
>>> +#define BCM2711_LOCAL_FIQ_SOURCE0 (BCM2711_LOCAL_REGS_BASE + 0x70)
>>> +#define BCM2711_LOCAL_FIQ_SOURCE1 (BCM2711_LOCAL_REGS_BASE + 0x74)
>>> +#define BCM2711_LOCAL_FIQ_SOURCE2 (BCM2711_LOCAL_REGS_BASE + 0x78)
>>> +#define BCM2711_LOCAL_FIQ_SOURCE3 (BCM2711_LOCAL_REGS_BASE + 0x7c)
>>> +
>>> +
>>> +/**
>>> + * @name Raspberry Pi 4 ARM_C FIQ and IRQ
Re: [PATCH] Arm/raspberrypi.h: Added relevant headers for the bcm2711
I dont think this would be visible to any other application until or unless
user explicitly include this header 'raspberrypi.h' in their application.
And as of now, this header is only placed in bsps/arm/raspberrypi/includes.
For my project I'm thinking of using this header with my project with
bcm2711 addresses included. For my project, this header will go under
bsps/aarch64/raspberrypi/includes. So I don't think this will create any
problem for other BSPs.
On Thu, Jul 21, 2022, 10:16 PM Joel Sherrill wrote:
> This looks generally ok but is all this visible to any application that
> includes bsp.h?
>
> It might all need to be moved into a separate header to avoid
> contaminating everyone's namespace.
>
> On Thu, Jul 21, 2022, 10:56 AM Noor Aman wrote:
>
>> A brief gist of what i found compatible with the older code
>> ---COMPATIBLE HEADER---
>> - BCM2835 timer
>> - GPIO
>> - AUX
>> - GPU timer
>> ---DIDNT CHECK---
>> - SPI
>> - I2C
>> ---MINOR CHNAGE---
>> - IRQ
>> - FIQ
>> ---NOT SURE ABOUT---
>> - Watchdog
>> - Power management
>> - Mailbox register
>>
>> I didnt get any info about power management or watchdog or mailboxes. (It
>> isnt in the BCM2835 Documention too I think??)
>>
>> And to answer your question Alan about if the Aarch64 would require a DTB
>> or not which you asked me quite earlier. I can say now, you dont, because
>> every address is defined here already so no need for the DTB.
>>
>>
>>
>> diff --git a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
>> b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
>> index eeb48c42f1..a4ed2a01d1 100644
>> --- a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
>> +++ b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
>> @@ -52,15 +52,23 @@
>> * @{
>> */
>>
>> -#if (BSP_IS_RPI2 == 1)
>> - #define RPI_PERIPHERAL_BASE0x3F00
>> +#if (RPI_BSP == RPI2)
>> + #define RPI_PERIPHERAL_BASE0X3F00
>>#define BASE_OFFSET0X3F00
>> +
>> +#elif (RPI_BSP == RPI4)
>> + #define RPI_PERIPHERAL_BASE 0xFE00
>> + #define BASE_OFFSET 0xFE00
>> + #define RPI_PERIPHERAL_SIZE0x0180
>> +
>> #else
>>#define RPI_PERIPHERAL_BASE0x2000
>>#define BASE_OFFSET0X5E00
>> +
>> #endif
>>
>> -#define RPI_PERIPHERAL_SIZE 0x0100
>> +#ifndef RPI_PERIPHERAL_SIZE
>> +#define RPI_PERIPHERAL_SIZE 0x0100
>>
>> /**
>> * @name Bus to Physical address translation
>> @@ -543,6 +551,188 @@
>> #define BCM2836_IRQ_SOURCE_PMU0x0200
>> #define BCM2836_IRQ_SOURCE_LOCAL_TIMER0x0800
>>
>> +
>> +
>> +/**
>> + * @name Raspberry Pi 4 ARM_LOCAL registers
>> + *
>> + * @{
>> + */
>> +
>> +#define BCM2711_LOCAL_REGS_BASE 0x4C000
>> +
>> +#define BCM2711_LOCAL_ARM_CONTROL (BCM2711_LOCAL_REGS_BASE + 0x00)
>> +#define BCM2711_LOCAL_CORE_IRQ_CONTROL (BCM2711_LOCAL_REGS_BASE + 0x0c)
>> +#define BCM2711_LOCAL_PMU_CONTROL_SET (BCM2711_LOCAL_REGS_BASE + 0x10)
>> +#define BCM2711_LOCAL_PMU_CONTROL_CLR (BCM2711_LOCAL_REGS_BASE + 0x14)
>> +#define BCM2711_LOCAL_PERI_IRQ_ROUTE0 (BCM2711_LOCAL_REGS_BASE + 0x24)
>> +#define BCM2711_LOCAL_AXI_QUIET_TIME (BCM2711_LOCAL_REGS_BASE + 0x30)
>> +#define BCM2711_LOCAL_LOCAL_TIMER_CONTROL (BCM2711_LOCAL_REGS_BASE +
>> 0x34)
>> +#define BCM2711_LOCAL_LOCAL_TIMER_IRQ (BCM2711_LOCAL_REGS_BASE +
>> 0x38)
>> +
>> +#define BCM2711_LOCAL_TIMER_CNTRL0 (BCM2711_LOCAL_REGS_BASE + 0x40)
>> +#define BCM2711_LOCAL_TIMER_CNTRL1 (BCM2711_LOCAL_REGS_BASE + 0x44)
>> +#define BCM2711_LOCAL_TIMER_CNTRL2 (BCM2711_LOCAL_REGS_BASE + 0x48)
>> +#define BCM2711_LOCAL_TIMER_CNTRL3 (BCM2711_LOCAL_REGS_BASE + 0x4c)
>> +
>> +#define BCM2711_LOCAL_MAILBOX_CNTRL0 (BCM2711_LOCAL_REGS_BASE + 0x50)
>> +#define BCM2711_LOCAL_MAILBOX_CNTRL1 (BCM2711_LOCAL_REGS_BASE + 0x54)
>> +#define BCM2711_LOCAL_MAILBOX_CNTRL2 (BCM2711_LOCAL_REGS_BASE + 0x58)
>> +#define BCM2711_LOCAL_MAILBOX_CNTRL3 (BCM2711_LOCAL_REGS_BASE + 0x5c)
>> +
>> +#define BCM2711_LOCAL_IRQ_SOURCE0 (BCM2711_LOCAL_REGS_BASE + 0x60)
>> +#define BCM2711_LOCAL_IRQ_SOURCE1 (BCM2711_LOCAL_REGS_BASE + 0x64)
>> +#define BCM2711_LOCAL_IRQ_SOURCE2 (BCM2711_LOCAL_REGS_BASE + 0x68)
>> +#define BCM2711_LOCAL_IRQ_SOURCE3 (BCM2711_LOCAL_REGS_BASE + 0x6c)
>> +
>> +#define BCM2711_LOCAL_FIQ_SOURCE0 (BCM2711_LOCAL_REGS_BASE + 0x70)
>> +#define BCM2711_LOCAL_FIQ_SOURCE1 (BCM2711_LOCAL_REGS_BASE + 0x74)
>> +#define BCM2711_LOCAL_FIQ_SOURCE2 (BCM2711_LOCAL_REGS_BASE + 0x78)
>> +#define BCM2711_LOCAL_FIQ_SOURCE3 (BCM2711_LOCAL_REGS_BASE + 0x7c)
>> +
>> +
>> +/**
>> + * @name Raspberry Pi 4 ARM_C FIQ and IRQ registers
>> + *
>> + * @{
>> + */
>> +
>> +#define BCM2711_ARMC_REGS_BASE (RPI_PERIPHERAL_BASE + 0xB200)
>> +
>> +#define BCM2711_ARMC_IRQ0_PENDING0 (BCM2711_ARMC_REGS_BASE + 0x00)
>> +#define BCM2711_ARMC_IRQ0_PENDING1 (BCM2711_ARMC_REGS_BASE + 0x04)
>> +#define BCM2711_ARMC_IRQ0_PENDING2 (BCM2711_ARMC_REGS_BASE + 0x08)
>> +#define BCM2711_ARMC_IRQ0_SET_EN_0 (BCM2711_ARMC_REGS_BASE + 0x10)
>> +#define
Re: [PATCH] Arm/raspberrypi.h: Added relevant headers for the bcm2711
This looks generally ok but is all this visible to any application that
includes bsp.h?
It might all need to be moved into a separate header to avoid contaminating
everyone's namespace.
On Thu, Jul 21, 2022, 10:56 AM Noor Aman wrote:
> A brief gist of what i found compatible with the older code
> ---COMPATIBLE HEADER---
> - BCM2835 timer
> - GPIO
> - AUX
> - GPU timer
> ---DIDNT CHECK---
> - SPI
> - I2C
> ---MINOR CHNAGE---
> - IRQ
> - FIQ
> ---NOT SURE ABOUT---
> - Watchdog
> - Power management
> - Mailbox register
>
> I didnt get any info about power management or watchdog or mailboxes. (It
> isnt in the BCM2835 Documention too I think??)
>
> And to answer your question Alan about if the Aarch64 would require a DTB
> or not which you asked me quite earlier. I can say now, you dont, because
> every address is defined here already so no need for the DTB.
>
>
>
> diff --git a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
> b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
> index eeb48c42f1..a4ed2a01d1 100644
> --- a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
> +++ b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
> @@ -52,15 +52,23 @@
> * @{
> */
>
> -#if (BSP_IS_RPI2 == 1)
> - #define RPI_PERIPHERAL_BASE0x3F00
> +#if (RPI_BSP == RPI2)
> + #define RPI_PERIPHERAL_BASE0X3F00
>#define BASE_OFFSET0X3F00
> +
> +#elif (RPI_BSP == RPI4)
> + #define RPI_PERIPHERAL_BASE 0xFE00
> + #define BASE_OFFSET 0xFE00
> + #define RPI_PERIPHERAL_SIZE0x0180
> +
> #else
>#define RPI_PERIPHERAL_BASE0x2000
>#define BASE_OFFSET0X5E00
> +
> #endif
>
> -#define RPI_PERIPHERAL_SIZE 0x0100
> +#ifndef RPI_PERIPHERAL_SIZE
> +#define RPI_PERIPHERAL_SIZE 0x0100
>
> /**
> * @name Bus to Physical address translation
> @@ -543,6 +551,188 @@
> #define BCM2836_IRQ_SOURCE_PMU0x0200
> #define BCM2836_IRQ_SOURCE_LOCAL_TIMER0x0800
>
> +
> +
> +/**
> + * @name Raspberry Pi 4 ARM_LOCAL registers
> + *
> + * @{
> + */
> +
> +#define BCM2711_LOCAL_REGS_BASE 0x4C000
> +
> +#define BCM2711_LOCAL_ARM_CONTROL (BCM2711_LOCAL_REGS_BASE + 0x00)
> +#define BCM2711_LOCAL_CORE_IRQ_CONTROL (BCM2711_LOCAL_REGS_BASE + 0x0c)
> +#define BCM2711_LOCAL_PMU_CONTROL_SET (BCM2711_LOCAL_REGS_BASE + 0x10)
> +#define BCM2711_LOCAL_PMU_CONTROL_CLR (BCM2711_LOCAL_REGS_BASE + 0x14)
> +#define BCM2711_LOCAL_PERI_IRQ_ROUTE0 (BCM2711_LOCAL_REGS_BASE + 0x24)
> +#define BCM2711_LOCAL_AXI_QUIET_TIME (BCM2711_LOCAL_REGS_BASE + 0x30)
> +#define BCM2711_LOCAL_LOCAL_TIMER_CONTROL (BCM2711_LOCAL_REGS_BASE + 0x34)
> +#define BCM2711_LOCAL_LOCAL_TIMER_IRQ (BCM2711_LOCAL_REGS_BASE +
> 0x38)
> +
> +#define BCM2711_LOCAL_TIMER_CNTRL0 (BCM2711_LOCAL_REGS_BASE + 0x40)
> +#define BCM2711_LOCAL_TIMER_CNTRL1 (BCM2711_LOCAL_REGS_BASE + 0x44)
> +#define BCM2711_LOCAL_TIMER_CNTRL2 (BCM2711_LOCAL_REGS_BASE + 0x48)
> +#define BCM2711_LOCAL_TIMER_CNTRL3 (BCM2711_LOCAL_REGS_BASE + 0x4c)
> +
> +#define BCM2711_LOCAL_MAILBOX_CNTRL0 (BCM2711_LOCAL_REGS_BASE + 0x50)
> +#define BCM2711_LOCAL_MAILBOX_CNTRL1 (BCM2711_LOCAL_REGS_BASE + 0x54)
> +#define BCM2711_LOCAL_MAILBOX_CNTRL2 (BCM2711_LOCAL_REGS_BASE + 0x58)
> +#define BCM2711_LOCAL_MAILBOX_CNTRL3 (BCM2711_LOCAL_REGS_BASE + 0x5c)
> +
> +#define BCM2711_LOCAL_IRQ_SOURCE0 (BCM2711_LOCAL_REGS_BASE + 0x60)
> +#define BCM2711_LOCAL_IRQ_SOURCE1 (BCM2711_LOCAL_REGS_BASE + 0x64)
> +#define BCM2711_LOCAL_IRQ_SOURCE2 (BCM2711_LOCAL_REGS_BASE + 0x68)
> +#define BCM2711_LOCAL_IRQ_SOURCE3 (BCM2711_LOCAL_REGS_BASE + 0x6c)
> +
> +#define BCM2711_LOCAL_FIQ_SOURCE0 (BCM2711_LOCAL_REGS_BASE + 0x70)
> +#define BCM2711_LOCAL_FIQ_SOURCE1 (BCM2711_LOCAL_REGS_BASE + 0x74)
> +#define BCM2711_LOCAL_FIQ_SOURCE2 (BCM2711_LOCAL_REGS_BASE + 0x78)
> +#define BCM2711_LOCAL_FIQ_SOURCE3 (BCM2711_LOCAL_REGS_BASE + 0x7c)
> +
> +
> +/**
> + * @name Raspberry Pi 4 ARM_C FIQ and IRQ registers
> + *
> + * @{
> + */
> +
> +#define BCM2711_ARMC_REGS_BASE (RPI_PERIPHERAL_BASE + 0xB200)
> +
> +#define BCM2711_ARMC_IRQ0_PENDING0 (BCM2711_ARMC_REGS_BASE + 0x00)
> +#define BCM2711_ARMC_IRQ0_PENDING1 (BCM2711_ARMC_REGS_BASE + 0x04)
> +#define BCM2711_ARMC_IRQ0_PENDING2 (BCM2711_ARMC_REGS_BASE + 0x08)
> +#define BCM2711_ARMC_IRQ0_SET_EN_0 (BCM2711_ARMC_REGS_BASE + 0x10)
> +#define BCM2711_ARMC_IRQ0_SET_EN_1 (BCM2711_ARMC_REGS_BASE + 0x14)
> +#define BCM2711_ARMC_IRQ0_SET_EN_2 (BCM2711_ARMC_REGS_BASE + 0x18)
> +#define BCM2711_ARMC_IRQ0_CLR_EN_0 (BCM2711_ARMC_REGS_BASE + 0x20)
> +#define BCM2711_ARMC_IRQ0_CLR_EN_1 (BCM2711_ARMC_REGS_BASE + 0x24)
> +#define BCM2711_ARMC_IRQ0_CLR_EN_2 (BCM2711_ARMC_REGS_BASE + 0x28)
> +
> +#define BCM2711_ARMC_IRQ_STATUS0 (BCM2711_ARMC_REGS_BASE + 0x30)
> +#define BCM2711_ARMC_IRQ_STATUS1 (BCM2711_ARMC_REGS_BASE + 0x34)
> +#define BCM2711_ARMC_IRQ_STATUS2 (BCM2711_ARMC_REGS_BASE + 0x38)
> +
> +#define BCM2711_ARMC_IRQ1_PENDING0 (BCM2711_ARMC_REGS_BASE + 0x40)
> +#define
[PATCH] Arm/raspberrypi.h: Added relevant headers for the bcm2711
A brief gist of what i found compatible with the older code
---COMPATIBLE HEADER---
- BCM2835 timer
- GPIO
- AUX
- GPU timer
---DIDNT CHECK---
- SPI
- I2C
---MINOR CHNAGE---
- IRQ
- FIQ
---NOT SURE ABOUT---
- Watchdog
- Power management
- Mailbox register
I didnt get any info about power management or watchdog or mailboxes. (It
isnt in the BCM2835 Documention too I think??)
And to answer your question Alan about if the Aarch64 would require a DTB
or not which you asked me quite earlier. I can say now, you dont, because
every address is defined here already so no need for the DTB.
diff --git a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
index eeb48c42f1..a4ed2a01d1 100644
--- a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
+++ b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h
@@ -52,15 +52,23 @@
* @{
*/
-#if (BSP_IS_RPI2 == 1)
- #define RPI_PERIPHERAL_BASE0x3F00
+#if (RPI_BSP == RPI2)
+ #define RPI_PERIPHERAL_BASE0X3F00
#define BASE_OFFSET0X3F00
+
+#elif (RPI_BSP == RPI4)
+ #define RPI_PERIPHERAL_BASE 0xFE00
+ #define BASE_OFFSET 0xFE00
+ #define RPI_PERIPHERAL_SIZE0x0180
+
#else
#define RPI_PERIPHERAL_BASE0x2000
#define BASE_OFFSET0X5E00
+
#endif
-#define RPI_PERIPHERAL_SIZE 0x0100
+#ifndef RPI_PERIPHERAL_SIZE
+#define RPI_PERIPHERAL_SIZE 0x0100
/**
* @name Bus to Physical address translation
@@ -543,6 +551,188 @@
#define BCM2836_IRQ_SOURCE_PMU0x0200
#define BCM2836_IRQ_SOURCE_LOCAL_TIMER0x0800
+
+
+/**
+ * @name Raspberry Pi 4 ARM_LOCAL registers
+ *
+ * @{
+ */
+
+#define BCM2711_LOCAL_REGS_BASE 0x4C000
+
+#define BCM2711_LOCAL_ARM_CONTROL (BCM2711_LOCAL_REGS_BASE + 0x00)
+#define BCM2711_LOCAL_CORE_IRQ_CONTROL (BCM2711_LOCAL_REGS_BASE + 0x0c)
+#define BCM2711_LOCAL_PMU_CONTROL_SET (BCM2711_LOCAL_REGS_BASE + 0x10)
+#define BCM2711_LOCAL_PMU_CONTROL_CLR (BCM2711_LOCAL_REGS_BASE + 0x14)
+#define BCM2711_LOCAL_PERI_IRQ_ROUTE0 (BCM2711_LOCAL_REGS_BASE + 0x24)
+#define BCM2711_LOCAL_AXI_QUIET_TIME (BCM2711_LOCAL_REGS_BASE + 0x30)
+#define BCM2711_LOCAL_LOCAL_TIMER_CONTROL (BCM2711_LOCAL_REGS_BASE + 0x34)
+#define BCM2711_LOCAL_LOCAL_TIMER_IRQ (BCM2711_LOCAL_REGS_BASE +
0x38)
+
+#define BCM2711_LOCAL_TIMER_CNTRL0 (BCM2711_LOCAL_REGS_BASE + 0x40)
+#define BCM2711_LOCAL_TIMER_CNTRL1 (BCM2711_LOCAL_REGS_BASE + 0x44)
+#define BCM2711_LOCAL_TIMER_CNTRL2 (BCM2711_LOCAL_REGS_BASE + 0x48)
+#define BCM2711_LOCAL_TIMER_CNTRL3 (BCM2711_LOCAL_REGS_BASE + 0x4c)
+
+#define BCM2711_LOCAL_MAILBOX_CNTRL0 (BCM2711_LOCAL_REGS_BASE + 0x50)
+#define BCM2711_LOCAL_MAILBOX_CNTRL1 (BCM2711_LOCAL_REGS_BASE + 0x54)
+#define BCM2711_LOCAL_MAILBOX_CNTRL2 (BCM2711_LOCAL_REGS_BASE + 0x58)
+#define BCM2711_LOCAL_MAILBOX_CNTRL3 (BCM2711_LOCAL_REGS_BASE + 0x5c)
+
+#define BCM2711_LOCAL_IRQ_SOURCE0 (BCM2711_LOCAL_REGS_BASE + 0x60)
+#define BCM2711_LOCAL_IRQ_SOURCE1 (BCM2711_LOCAL_REGS_BASE + 0x64)
+#define BCM2711_LOCAL_IRQ_SOURCE2 (BCM2711_LOCAL_REGS_BASE + 0x68)
+#define BCM2711_LOCAL_IRQ_SOURCE3 (BCM2711_LOCAL_REGS_BASE + 0x6c)
+
+#define BCM2711_LOCAL_FIQ_SOURCE0 (BCM2711_LOCAL_REGS_BASE + 0x70)
+#define BCM2711_LOCAL_FIQ_SOURCE1 (BCM2711_LOCAL_REGS_BASE + 0x74)
+#define BCM2711_LOCAL_FIQ_SOURCE2 (BCM2711_LOCAL_REGS_BASE + 0x78)
+#define BCM2711_LOCAL_FIQ_SOURCE3 (BCM2711_LOCAL_REGS_BASE + 0x7c)
+
+
+/**
+ * @name Raspberry Pi 4 ARM_C FIQ and IRQ registers
+ *
+ * @{
+ */
+
+#define BCM2711_ARMC_REGS_BASE (RPI_PERIPHERAL_BASE + 0xB200)
+
+#define BCM2711_ARMC_IRQ0_PENDING0 (BCM2711_ARMC_REGS_BASE + 0x00)
+#define BCM2711_ARMC_IRQ0_PENDING1 (BCM2711_ARMC_REGS_BASE + 0x04)
+#define BCM2711_ARMC_IRQ0_PENDING2 (BCM2711_ARMC_REGS_BASE + 0x08)
+#define BCM2711_ARMC_IRQ0_SET_EN_0 (BCM2711_ARMC_REGS_BASE + 0x10)
+#define BCM2711_ARMC_IRQ0_SET_EN_1 (BCM2711_ARMC_REGS_BASE + 0x14)
+#define BCM2711_ARMC_IRQ0_SET_EN_2 (BCM2711_ARMC_REGS_BASE + 0x18)
+#define BCM2711_ARMC_IRQ0_CLR_EN_0 (BCM2711_ARMC_REGS_BASE + 0x20)
+#define BCM2711_ARMC_IRQ0_CLR_EN_1 (BCM2711_ARMC_REGS_BASE + 0x24)
+#define BCM2711_ARMC_IRQ0_CLR_EN_2 (BCM2711_ARMC_REGS_BASE + 0x28)
+
+#define BCM2711_ARMC_IRQ_STATUS0 (BCM2711_ARMC_REGS_BASE + 0x30)
+#define BCM2711_ARMC_IRQ_STATUS1 (BCM2711_ARMC_REGS_BASE + 0x34)
+#define BCM2711_ARMC_IRQ_STATUS2 (BCM2711_ARMC_REGS_BASE + 0x38)
+
+#define BCM2711_ARMC_IRQ1_PENDING0 (BCM2711_ARMC_REGS_BASE + 0x40)
+#define BCM2711_ARMC_IRQ1_PENDING1 (BCM2711_ARMC_REGS_BASE + 0x44)
+#define BCM2711_ARMC_IRQ1_PENDING2 (BCM2711_ARMC_REGS_BASE + 0x48)
+#define BCM2711_ARMC_IRQ1_SET_EN_0 (BCM2711_ARMC_REGS_BASE + 0x50)
+#define BCM2711_ARMC_IRQ1_SET_EN_1 (BCM2711_ARMC_REGS_BASE + 0x54)
+#define BCM2711_ARMC_IRQ1_SET_EN_2 (BCM2711_ARMC_REGS_BASE + 0x58)
+#define BCM2711_ARMC_IRQ1_CLR_EN_0 (BCM2711_ARMC_REGS_BASE + 0x60)
+#define BCM2711_ARMC_IRQ1_CLR_EN_1 (BCM2711_ARMC_REGS_BASE + 0x64)
+#define
Re: [PATCH v1 3/5] cpukit/libdl: Add support for AArch64
On 7/20/2022 11:39 PM, Chris Johns wrote:
On 21/7/2022 7:36 am, Ryan Long wrote:
rtl-mdreloc-aarch64.c and elf_machdep.h came from NetBSD.
Updates #4682
---
cpukit/libdl/rtl-mdreloc-aarch64.c| 598 ++
.../cpu/aarch64/include/machine/elf_machdep.h | 256
spec/build/cpukit/objdl.yml | 2 +
spec/build/cpukit/objdlaarch64.yml| 15 +
spec/build/cpukit/optlibdl.yml| 1 +
5 files changed, 872 insertions(+)
create mode 100644 cpukit/libdl/rtl-mdreloc-aarch64.c
create mode 100644 cpukit/score/cpu/aarch64/include/machine/elf_machdep.h
create mode 100644 spec/build/cpukit/objdlaarch64.yml
diff --git a/cpukit/libdl/rtl-mdreloc-aarch64.c
b/cpukit/libdl/rtl-mdreloc-aarch64.c
new file mode 100644
index 00..ded73ad46b
--- /dev/null
+++ b/cpukit/libdl/rtl-mdreloc-aarch64.c
@@ -0,0 +1,598 @@
+/*
+ * Taken from NetBSD and stripped of the relocations not needed on RTEMS.
+ */
+
+/* $NetBSD: mdreloc.c,v 1.14 2020/06/16 21:01:30 joerg Exp $ */
+
+/*-
+ * Copyright (c) 2014 The NetBSD Foundation, Inc.
+ * All rights reserved.
+ *
+ * This code is derived from software contributed to The NetBSD Foundation
+ * by Matt Thomas of 3am Software Foundry.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
+ * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
+ * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+ * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
+ * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/*-
+ * Copyright (c) 2014-2015 The FreeBSD Foundation
+ * All rights reserved.
+ *
+ * Portions of this software were developed by Andrew Turner
+ * under sponsorship from the FreeBSD Foundation.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include
+#ifndef lint
+__RCSID("$NetBSD: mdreloc.c,v 1.14 2020/06/16 21:01:30 joerg Exp $");
+#endif /* not lint */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include "rtl-elf.h"
+#include "rtl-error.h"
+#include
+#include "rtl-unwind.h"
+
+typedef unsigned _Unwind_Word __attribute__((__mode__(__word__)));
+typedef _Unwind_Word _uw;
+
+struct tls_data {
+ size_t td_tlsindex;
+ Elf_Addrtd_tlsoffs;
+};
+
+rtems_rtl_elf_rel_status
+rtems_rtl_elf_reloc_rela (
+ rtems_rtl_obj*obj,
+ const Elf_Rela* rela,
+ const rtems_rtl_obj_sect* sect,
+ const char* symname,
+ const Elf_Bytesyminfo,
+ const Elf_Wordsymvalue,
+ const boolparsing
+);
+
+#define __BITS(hi,lo)((~((~(Elf_Addr)0)<<((hi)+1)))&((~(Elf_Addr)0)<<(lo)))
Re: [Feedback needed] Proposal for ADC API
Hello Sebastian, On Tue, 2022-07-19 at 14:00 +0200, Sebastian Huber wrote: > Hello, > > we should also consider to use existing APIs and implementations for > stuff we do not yet have in RTEMS, for example: > > https://docs.zephyrproject.org/latest/hardware/peripherals/adc.html > > The Zephyr project uses device trees to statically configure device > drivers: > > https://docs.zephyrproject.org/latest/build/dts/index.html > > This is quite interesting for lower end targets. > Can you please explain more about your thoughts and maybe some directions for me? Do you mean we should find ways to change the way our current APIs work with static constructions instead of adding new APIs? Thank you, Duc Doan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] score: Remove PRIORITY_PSEUDO_ISR thread priority
On Thu, Jul 21, 2022 at 12:53 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello Gedare and Joel, > > On 15.07.22 10:43, Sebastian Huber wrote: > > The uniprocessor schedulers had some special case logic for the > > PRIORITY_PSEUDO_ISR priority. Tasks with a priority of > PRIORITY_PSEUDO_ISR > > were allowed to preempt a not preemptible task. If other higher > priority task > > are made ready while a PRIORITY_PSEUDO_ISR task preempts a not > preemptible > > task, then the other tasks run before the not preemptible task. This > made the > > RTEMS_NO_PREEMPT mode ineffective. > > > > Remove the PRIORITY_PSEUDO_ISR special case logic. This simplifies the > > uniprocessor schedulers. Move the uniprocessor-specific scheduler > support to > > the new header file . > > > > Close #2365. > I'm guessing that PRIORITY_PSEUDO_ISR wasn't used outside RTEMS itself and likely only historically for the Timer Server Thread. The protection for that thread was reworked as part of the SMP efforts. If it is used outside RTEMS, that would be a user facing breakage and should be documented. If you think all the use cases of PRIORITY_PSEUDO_ISR are accounted for, I'm ok with removing it. > > what is your opinion with respect to this change? It is the second last > item on my score TODO list. The last item is: > > https://lists.rtems.org/pipermail/devel/2022-July/072534.html I'll try to look at that today. > > > -- > embedded brains GmbH > 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
[rtems-docs] user/rsb: Mention --with/without-newlib-tls
Update #4560. --- user/rsb/project-sets.rst | 9 + 1 file changed, 9 insertions(+) diff --git a/user/rsb/project-sets.rst b/user/rsb/project-sets.rst index 54a3f8e..ce839c5 100644 --- a/user/rsb/project-sets.rst +++ b/user/rsb/project-sets.rst @@ -116,6 +116,15 @@ build sets: ``--with-objc`` Attempt to build a C++ compiler. +``--with-newlib-tls`` or ``--without-newlib-tls`` + Enable or disable the ``--enable-newlib-reent-thread-local`` Newlib + configuration option. This option is enabled by default on the aarch64, arm, + nios2, powerpc, riscv, and sparc targets. If this option is enabled, then + each member of the Newlib struct _reent is replaced by a dedicated + thread-local object. The thread-local objects are defined in translation + units which use the corresponding object so that only objects used by the + application are linked in. + The RSB provides build sets for some BSPs. These build sets will build: - Compiler, linker, debugger and RTEMS Tools. -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 0/3] Support --enable-newlib-reent-thread-local Newlib configuration option
On 21.07.22 10:36, Chris Johns wrote: On 21/7/2022 6:30 pm, Sebastian Huber wrote: On 21.07.22 10:27, Chris Johns wrote: On 21/7/2022 6:21 pm, Sebastian Huber wrote: On 21.07.22 10:16, Chris Johns wrote: On 21/7/2022 6:11 pm, Sebastian Huber wrote: On 21.07.22 10:03, Chris Johns wrote: As an aside, does gdb know about TLS variables and so will `errno` be visible? Good question, there seems to be some support missing. For example for arm/xilinx_zynq_a9_qemu: Breakpoint 7, Init (ignored=2118804) at /home/EB/sebastian_h/src/rtems/testsuites/samples/fileio/init.c:1169 1169 TEST_BEGIN(); (gdb) watch _tls_errno Cannot find thread-local variables on this target (gdb) p _tls_errno Cannot find thread-local variables on this target I wonder if we need to configure gdb so it understands how we handle TLS variables? It could be a Qemu issue. In GDB there is a /* Check for the TLS register feature. */ feature = tdesc_find_feature (tdesc, "org.gnu.gdb.arm.tls"); However, this is not provided by Qemu. Is this something in the remote protocol? I would have thought the ABI would define the register? Yes, I guess this is a part of the machine description provided by the server (Qemu). This stuff seems to be quite new (from 2022) added by John Baldwin for FreeBSD. That would only apply if qemu was providing the XML description and it is not normally something I have seen. Most of time the built in XML is used. The only packet I could see in a quick look at the protocol is offsets for TLS variables for dynamically loaded object files. This is needed because the link editor allocates the variables when relocating. Maybe this feature is not included in GDB 12 and earlier? -- embedded brains GmbH 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: [PATCH v2 0/3] Support --enable-newlib-reent-thread-local Newlib configuration option
On 21/7/2022 6:30 pm, Sebastian Huber wrote: > On 21.07.22 10:27, Chris Johns wrote: >> On 21/7/2022 6:21 pm, Sebastian Huber wrote: >>> On 21.07.22 10:16, Chris Johns wrote: On 21/7/2022 6:11 pm, Sebastian Huber wrote: > On 21.07.22 10:03, Chris Johns wrote: >> As an aside, does gdb know about TLS variables and so will `errno` be >> visible? > Good question, there seems to be some support missing. For example for > arm/xilinx_zynq_a9_qemu: > > Breakpoint 7, Init (ignored=2118804) at > /home/EB/sebastian_h/src/rtems/testsuites/samples/fileio/init.c:1169 > 1169 TEST_BEGIN(); > (gdb) watch _tls_errno > Cannot find thread-local variables on this target > (gdb) p _tls_errno > Cannot find thread-local variables on this target I wonder if we need to configure gdb so it understands how we handle TLS variables? >>> It could be a Qemu issue. In GDB there is a >>> >>> /* Check for the TLS register feature. */ >>> feature = tdesc_find_feature (tdesc, "org.gnu.gdb.arm.tls"); >>> >>> However, this is not provided by Qemu. >> Is this something in the remote protocol? I would have thought the ABI would >> define the register? > > Yes, I guess this is a part of the machine description provided by the server > (Qemu). This stuff seems to be quite new (from 2022) added by John Baldwin for > FreeBSD. That would only apply if qemu was providing the XML description and it is not normally something I have seen. Most of time the built in XML is used. The only packet I could see in a quick look at the protocol is offsets for TLS variables for dynamically loaded object files. This is needed because the link editor allocates the variables when relocating. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 0/3] Support --enable-newlib-reent-thread-local Newlib configuration option
On 21.07.22 10:27, Chris Johns wrote: On 21/7/2022 6:21 pm, Sebastian Huber wrote: On 21.07.22 10:16, Chris Johns wrote: On 21/7/2022 6:11 pm, Sebastian Huber wrote: On 21.07.22 10:03, Chris Johns wrote: As an aside, does gdb know about TLS variables and so will `errno` be visible? Good question, there seems to be some support missing. For example for arm/xilinx_zynq_a9_qemu: Breakpoint 7, Init (ignored=2118804) at /home/EB/sebastian_h/src/rtems/testsuites/samples/fileio/init.c:1169 1169 TEST_BEGIN(); (gdb) watch _tls_errno Cannot find thread-local variables on this target (gdb) p _tls_errno Cannot find thread-local variables on this target I wonder if we need to configure gdb so it understands how we handle TLS variables? It could be a Qemu issue. In GDB there is a /* Check for the TLS register feature. */ feature = tdesc_find_feature (tdesc, "org.gnu.gdb.arm.tls"); However, this is not provided by Qemu. Is this something in the remote protocol? I would have thought the ABI would define the register? Yes, I guess this is a part of the machine description provided by the server (Qemu). This stuff seems to be quite new (from 2022) added by John Baldwin for FreeBSD. -- embedded brains GmbH 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: [PATCH v2 0/3] Support --enable-newlib-reent-thread-local Newlib configuration option
On 21/7/2022 6:21 pm, Sebastian Huber wrote: > On 21.07.22 10:16, Chris Johns wrote: >> On 21/7/2022 6:11 pm, Sebastian Huber wrote: >>> On 21.07.22 10:03, Chris Johns wrote: As an aside, does gdb know about TLS variables and so will `errno` be visible? >>> Good question, there seems to be some support missing. For example for >>> arm/xilinx_zynq_a9_qemu: >>> >>> Breakpoint 7, Init (ignored=2118804) at >>> /home/EB/sebastian_h/src/rtems/testsuites/samples/fileio/init.c:1169 >>> 1169 TEST_BEGIN(); >>> (gdb) watch _tls_errno >>> Cannot find thread-local variables on this target >>> (gdb) p _tls_errno >>> Cannot find thread-local variables on this target >> I wonder if we need to configure gdb so it understands how we handle TLS >> variables? > > It could be a Qemu issue. In GDB there is a > > /* Check for the TLS register feature. */ > feature = tdesc_find_feature (tdesc, "org.gnu.gdb.arm.tls"); > > However, this is not provided by Qemu. Is this something in the remote protocol? I would have thought the ABI would define the register? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 0/3] Support --enable-newlib-reent-thread-local Newlib configuration option
On 21.07.22 10:16, Chris Johns wrote: On 21/7/2022 6:11 pm, Sebastian Huber wrote: On 21.07.22 10:03, Chris Johns wrote: As an aside, does gdb know about TLS variables and so will `errno` be visible? Good question, there seems to be some support missing. For example for arm/xilinx_zynq_a9_qemu: Breakpoint 7, Init (ignored=2118804) at /home/EB/sebastian_h/src/rtems/testsuites/samples/fileio/init.c:1169 1169 TEST_BEGIN(); (gdb) watch _tls_errno Cannot find thread-local variables on this target (gdb) p _tls_errno Cannot find thread-local variables on this target I wonder if we need to configure gdb so it understands how we handle TLS variables? It could be a Qemu issue. In GDB there is a /* Check for the TLS register feature. */ feature = tdesc_find_feature (tdesc, "org.gnu.gdb.arm.tls"); However, this is not provided by Qemu. -- embedded brains GmbH 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: [PATCH v2 0/3] Support --enable-newlib-reent-thread-local Newlib configuration option
On 21/7/2022 6:11 pm, Sebastian Huber wrote: > On 21.07.22 10:03, Chris Johns wrote: >> As an aside, does gdb know about TLS variables and so will `errno` be >> visible? > > Good question, there seems to be some support missing. For example for > arm/xilinx_zynq_a9_qemu: > > Breakpoint 7, Init (ignored=2118804) at > /home/EB/sebastian_h/src/rtems/testsuites/samples/fileio/init.c:1169 > 1169 TEST_BEGIN(); > (gdb) watch _tls_errno > Cannot find thread-local variables on this target > (gdb) p _tls_errno > Cannot find thread-local variables on this target I wonder if we need to configure gdb so it understands how we handle TLS variables? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 0/3] Support --enable-newlib-reent-thread-local Newlib configuration option
On 21.07.22 10:03, Chris Johns wrote: As an aside, does gdb know about TLS variables and so will `errno` be visible? Good question, there seems to be some support missing. For example for arm/xilinx_zynq_a9_qemu: Breakpoint 7, Init (ignored=2118804) at /home/EB/sebastian_h/src/rtems/testsuites/samples/fileio/init.c:1169 1169 TEST_BEGIN(); (gdb) watch _tls_errno Cannot find thread-local variables on this target (gdb) p _tls_errno Cannot find thread-local variables on this target -- embedded brains GmbH 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: [PATCH v2 0/3] Support --enable-newlib-reent-thread-local Newlib configuration option
+1 Really great patch and change. I think the performance improvements will be excellent. As an aside, does gdb know about TLS variables and so will `errno` be visible? Chris On 21/7/2022 5:09 pm, Sebastian Huber wrote: > This patch set adds support for the --enable-newlib-reent-thread-local > (_REENT_THREAD_LOCAL_STORAGE) Newlib configuration option. > > By default, Newlib uses a huge object of type struct _reent to store > thread-specific data. This object is returned by __getreent() if the > __DYNAMIC_REENT__ Newlib configuration option is defined. > > The reentrancy structure contains for example errno and the standard input, > output, and error file streams. This means that if an application only uses > errno it has a dependency on the file stream support even if it does not use > it. This is an issue for lower end targets and applications which need to > qualify the software according to safety standards (for example ECSS-E-ST-40C, > ECSS-Q-ST-80C, IEC 61508, ISO 26262, DO-178, DO-330, DO-333). > > If the new _REENT_THREAD_LOCAL configuration option is enabled, then struct > _reent is replaced by dedicated thread-local objects for each struct _reent > member. The thread-local objects are defined in translation units which use > the corresponding object. > > v2: > > * Remove i386, microblaze, and m68k from default enabled list. > > * Support --with-newlib-tls and --without-newlib-tls. > > Sebastian Huber (3): > 6/7: Update Newlib > newlib: Support --with/without-newlib-tls > 6/7: Use TLS in Newlib for some targets by default > > rtems/config/6/rtems-aarch64.bset | 1 + > rtems/config/6/rtems-arm.bset | 1 + > rtems/config/6/rtems-nios2.bset | 1 + > rtems/config/6/rtems-powerpc.bset | 1 + > rtems/config/6/rtems-riscv.bset | 1 + > rtems/config/6/rtems-sparc.bset | 1 + > rtems/config/7/rtems-aarch64.bset | 1 + > rtems/config/7/rtems-arm.bset | 1 + > rtems/config/7/rtems-nios2.bset | 1 + > rtems/config/7/rtems-powerpc.bset | 1 + > rtems/config/7/rtems-riscv.bset | 1 + > rtems/config/7/rtems-sparc.bset | 1 + > .../config/tools/rtems-gcc-10-newlib-head.cfg | 4 +-- > .../tools/rtems-gcc-10.4-newlib-head.cfg | 27 +++ > .../config/tools/rtems-gcc-12-newlib-head.cfg | 5 ++-- > .../tools/rtems-gcc-head-newlib-head.cfg | 4 +-- > source-builder/config/checks.cfg | 9 +++ > source-builder/config/gcc-common-1.cfg| 1 + > 18 files changed, 55 insertions(+), 7 deletions(-) > create mode 100644 rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2 1/3] 6/7: Update Newlib
This makes the --enable-newlib-reent-thread-local (_REENT_THREAD_LOCAL_STORAGE)
Newlib configuration option available.
Update #4560.
---
.../config/tools/rtems-gcc-10-newlib-head.cfg | 4 +--
.../tools/rtems-gcc-10.4-newlib-head.cfg | 27 +++
.../config/tools/rtems-gcc-12-newlib-head.cfg | 5 ++--
.../tools/rtems-gcc-head-newlib-head.cfg | 4 +--
4 files changed, 33 insertions(+), 7 deletions(-)
create mode 100644 rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
diff --git a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
index 1d08b61..07f92d1 100644
--- a/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
+++ b/rtems/config/tools/rtems-gcc-10-newlib-head.cfg
@@ -16,11 +16,11 @@
%patch add newlib -p1
https://devel.rtems.org/raw-attachment/ticket/4510/0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
%hash sha512 0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
7ca237eabfd5b382713186e1fc290dfc999a353315795ecb8dd0d22fcd1ab7f5bf31f4329954adab91ad04c100dcac0e86d406fdbce8f82cf9dc23842c88caf6
-%define newlib_version 27fd806
+%define newlib_version ea99f21
%define newlib_external 1
%define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
%source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz
https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
-%hash sha512 newlib-%{newlib_version}.tar.gz
02fc2a0ffc8bf581f3f98deab582469130cfd6e10983b2be69f9971a326bbc9abedd1e828f990ae69ea984fd5dcad0889345ccab37d83c2f025437f65c53dab6
+%hash sha512 newlib-%{newlib_version}.tar.gz
a4216024740c7d5ae6d21a6ab731dcf0bd7a4d70710bc1e79683e7d819812829216df08cd54d0ce7d61c2a959924419ea89367e4c6fb442e59839cacd85d2c52
%define with_threads 1
%define with_plugin 0
diff --git a/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
b/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
new file mode 100644
index 000..270b5ad
--- /dev/null
+++ b/rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg
@@ -0,0 +1,27 @@
+%include %{_configdir}/checks.cfg
+%include %{_configdir}/base.cfg
+
+%define gcc_version 10.4.0
+%source set gcc
https://ftp.gnu.org/gnu/gcc/gcc-%{gcc_version}/gcc-%{gcc_version}.tar.xz
+%hash sha512 gcc-%{gcc_version}.tar.xz
440c08ca746da450d9a1b35e8fd2305cb27e7e6987cd9d0f7d375f3b1fc9e4b0bd7acb3cd7bf795e72fcbead59cdef5b6c152862f5d35cd9fbfe6902101ce648
+
+%patch add gcc -p1
https://devel.rtems.org/raw-attachment/ticket/4196/0001-Back-port-v8-of-gcov-improvements-to-GCC-10.patch
+%hash sha512 0001-Back-port-v8-of-gcov-improvements-to-GCC-10.patch
c2d1faed68aa0f60bef917365545cc4cc899df428a5d08f178417c06def4fd3cd3a749c1871c8a22552022c29dfae4a3d21161e2b01291e458ea8d670f01887e
+
+%patch add gcc -p1
https://devel.rtems.org/raw-attachment/ticket/4215/0001-nios2-Remove-custom-instruction-warnings.patch
+%hash sha512 0001-nios2-Remove-custom-instruction-warnings.patch
afd8a5e6bdcc5b75d5fbbf558bdf56ccac400521a6eec9d88cc95f6be67c481f2dbf8faa0f6ddc1e4ac7c56a84938714d80e46e9cf80ec4b8fcd739986449881
+
+%patch add newlib -p1
https://devel.rtems.org/raw-attachment/ticket/4510/0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
+%hash sha512 0001-aarch64-Add-ILP32-ABI-support-in-assembly-v2.patch
7ca237eabfd5b382713186e1fc290dfc999a353315795ecb8dd0d22fcd1ab7f5bf31f4329954adab91ad04c100dcac0e86d406fdbce8f82cf9dc23842c88caf6
+
+%define newlib_version ea99f21
+%define newlib_external 1
+%define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
+%source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz
https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
+%hash sha512 newlib-%{newlib_version}.tar.gz
a4216024740c7d5ae6d21a6ab731dcf0bd7a4d70710bc1e79683e7d819812829216df08cd54d0ce7d61c2a959924419ea89367e4c6fb442e59839cacd85d2c52
+
+%define with_threads 1
+%define with_plugin 0
+%define with_iconv 1
+
+%include %{_configdir}/gcc-10.cfg
diff --git a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
index 167b553..086e93b 100644
--- a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
+++ b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
@@ -38,13 +38,12 @@
KEmxHjYOqY4LTXCMZ3I60tbHusbR5GlnP0CLARHPAnhCnovDj9K3U43C1bsMxDDGRqD6fwtrEFoEgqVFX63IuQ==
# Comment above related to #4657 and patches ends here
-%define newlib_version 27fd806
+%define newlib_version ea99f21
%define newlib_external 1
%define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
%source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz \
https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
-%hash sha512 newlib-%{newlib_version}.tar.gz \
-
AvwqD/yL9YHz+Y3qtYJGkTDP1uEJg7K+afmXGjJrvJq+3R6Cj5kK5p6phP1dytCIk0XMqzfYPC8CVDf2XFPatg==
+%hash sha512 newlib-%{newlib_version}.tar.gz
[PATCH v2 3/3] 6/7: Use TLS in Newlib for some targets by default
Use the --enable-newlib-reent-thread-local (_REENT_THREAD_LOCAL_STORAGE) Newlib configuration option on the aarch64, arm, nios2, powerpc, riscv, and sparc targets by default. Update #4560. --- rtems/config/6/rtems-aarch64.bset | 1 + rtems/config/6/rtems-arm.bset | 1 + rtems/config/6/rtems-nios2.bset | 1 + rtems/config/6/rtems-powerpc.bset | 1 + rtems/config/6/rtems-riscv.bset | 1 + rtems/config/6/rtems-sparc.bset | 1 + rtems/config/7/rtems-aarch64.bset | 1 + rtems/config/7/rtems-arm.bset | 1 + rtems/config/7/rtems-nios2.bset | 1 + rtems/config/7/rtems-powerpc.bset | 1 + rtems/config/7/rtems-riscv.bset | 1 + rtems/config/7/rtems-sparc.bset | 1 + 12 files changed, 12 insertions(+) diff --git a/rtems/config/6/rtems-aarch64.bset b/rtems/config/6/rtems-aarch64.bset index e3c91af..99051eb 100644 --- a/rtems/config/6/rtems-aarch64.bset +++ b/rtems/config/6/rtems-aarch64.bset @@ -1,4 +1,5 @@ %define release 1 %define rtems_arch aarch64 %define with_libgomp +%define with_newlib_tls %include 6/rtems-default.bset diff --git a/rtems/config/6/rtems-arm.bset b/rtems/config/6/rtems-arm.bset index 425d66b..c4e6613 100644 --- a/rtems/config/6/rtems-arm.bset +++ b/rtems/config/6/rtems-arm.bset @@ -1,4 +1,5 @@ %define release 1 %define rtems_arch arm %define with_libgomp +%define with_newlib_tls %include 6/rtems-default.bset diff --git a/rtems/config/6/rtems-nios2.bset b/rtems/config/6/rtems-nios2.bset index 522eff5..d45024d 100644 --- a/rtems/config/6/rtems-nios2.bset +++ b/rtems/config/6/rtems-nios2.bset @@ -1,3 +1,4 @@ %define release 1 %define rtems_arch nios2 +%define with_newlib_tls %include 6/rtems-default.bset diff --git a/rtems/config/6/rtems-powerpc.bset b/rtems/config/6/rtems-powerpc.bset index c19327a..3309057 100644 --- a/rtems/config/6/rtems-powerpc.bset +++ b/rtems/config/6/rtems-powerpc.bset @@ -1,4 +1,5 @@ %define release 1 %define rtems_arch powerpc %define with_libgomp +%define with_newlib_tls %include 6/rtems-default.bset diff --git a/rtems/config/6/rtems-riscv.bset b/rtems/config/6/rtems-riscv.bset index ad7cb5b..ec1ab3a 100644 --- a/rtems/config/6/rtems-riscv.bset +++ b/rtems/config/6/rtems-riscv.bset @@ -1,5 +1,6 @@ %define release 1 %define rtems_arch riscv %define with_libgomp +%define with_newlib_tls %include 6/rtems-default.bset devel/sis-2-1 diff --git a/rtems/config/6/rtems-sparc.bset b/rtems/config/6/rtems-sparc.bset index 48d152d..809d47e 100644 --- a/rtems/config/6/rtems-sparc.bset +++ b/rtems/config/6/rtems-sparc.bset @@ -1,6 +1,7 @@ %define release 1 %define rtems_arch sparc %define with_libgomp +%define with_newlib_tls %define gdb-disable-sim 1 %include 6/rtems-default.bset devel/sis-2-1 diff --git a/rtems/config/7/rtems-aarch64.bset b/rtems/config/7/rtems-aarch64.bset index fc794aa..d899dc7 100644 --- a/rtems/config/7/rtems-aarch64.bset +++ b/rtems/config/7/rtems-aarch64.bset @@ -1,4 +1,5 @@ %define release 1 %define rtems_arch aarch64 %define with_libgomp +%define with_newlib_tls %include 7/rtems-default.bset diff --git a/rtems/config/7/rtems-arm.bset b/rtems/config/7/rtems-arm.bset index 7518812..a9bd612 100644 --- a/rtems/config/7/rtems-arm.bset +++ b/rtems/config/7/rtems-arm.bset @@ -1,4 +1,5 @@ %define release 1 %define rtems_arch arm %define with_libgomp +%define with_newlib_tls %include 7/rtems-default.bset diff --git a/rtems/config/7/rtems-nios2.bset b/rtems/config/7/rtems-nios2.bset index 735497f..a56aaeb 100644 --- a/rtems/config/7/rtems-nios2.bset +++ b/rtems/config/7/rtems-nios2.bset @@ -1,3 +1,4 @@ %define release 1 %define rtems_arch nios2 +%define with_newlib_tls %include 7/rtems-default.bset diff --git a/rtems/config/7/rtems-powerpc.bset b/rtems/config/7/rtems-powerpc.bset index 3da8841..4438550 100644 --- a/rtems/config/7/rtems-powerpc.bset +++ b/rtems/config/7/rtems-powerpc.bset @@ -1,4 +1,5 @@ %define release 1 %define rtems_arch powerpc %define with_libgomp +%define with_newlib_tls %include 7/rtems-default.bset diff --git a/rtems/config/7/rtems-riscv.bset b/rtems/config/7/rtems-riscv.bset index 441203e..3f81152 100644 --- a/rtems/config/7/rtems-riscv.bset +++ b/rtems/config/7/rtems-riscv.bset @@ -1,4 +1,5 @@ %define release 1 %define rtems_arch riscv %define with_libgomp +%define with_newlib_tls %include 7/rtems-default.bset diff --git a/rtems/config/7/rtems-sparc.bset b/rtems/config/7/rtems-sparc.bset index a147b8f..3c0d8f0 100644 --- a/rtems/config/7/rtems-sparc.bset +++ b/rtems/config/7/rtems-sparc.bset @@ -1,6 +1,7 @@ %define release 1 %define rtems_arch sparc %define with_libgomp +%define with_newlib_tls %define gdb-disable-sim 1 %include 7/rtems-default.bset devel/sis-2-1 -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2 0/3] Support --enable-newlib-reent-thread-local Newlib configuration option
This patch set adds support for the --enable-newlib-reent-thread-local (_REENT_THREAD_LOCAL_STORAGE) Newlib configuration option. By default, Newlib uses a huge object of type struct _reent to store thread-specific data. This object is returned by __getreent() if the __DYNAMIC_REENT__ Newlib configuration option is defined. The reentrancy structure contains for example errno and the standard input, output, and error file streams. This means that if an application only uses errno it has a dependency on the file stream support even if it does not use it. This is an issue for lower end targets and applications which need to qualify the software according to safety standards (for example ECSS-E-ST-40C, ECSS-Q-ST-80C, IEC 61508, ISO 26262, DO-178, DO-330, DO-333). If the new _REENT_THREAD_LOCAL configuration option is enabled, then struct _reent is replaced by dedicated thread-local objects for each struct _reent member. The thread-local objects are defined in translation units which use the corresponding object. v2: * Remove i386, microblaze, and m68k from default enabled list. * Support --with-newlib-tls and --without-newlib-tls. Sebastian Huber (3): 6/7: Update Newlib newlib: Support --with/without-newlib-tls 6/7: Use TLS in Newlib for some targets by default rtems/config/6/rtems-aarch64.bset | 1 + rtems/config/6/rtems-arm.bset | 1 + rtems/config/6/rtems-nios2.bset | 1 + rtems/config/6/rtems-powerpc.bset | 1 + rtems/config/6/rtems-riscv.bset | 1 + rtems/config/6/rtems-sparc.bset | 1 + rtems/config/7/rtems-aarch64.bset | 1 + rtems/config/7/rtems-arm.bset | 1 + rtems/config/7/rtems-nios2.bset | 1 + rtems/config/7/rtems-powerpc.bset | 1 + rtems/config/7/rtems-riscv.bset | 1 + rtems/config/7/rtems-sparc.bset | 1 + .../config/tools/rtems-gcc-10-newlib-head.cfg | 4 +-- .../tools/rtems-gcc-10.4-newlib-head.cfg | 27 +++ .../config/tools/rtems-gcc-12-newlib-head.cfg | 5 ++-- .../tools/rtems-gcc-head-newlib-head.cfg | 4 +-- source-builder/config/checks.cfg | 9 +++ source-builder/config/gcc-common-1.cfg| 1 + 18 files changed, 55 insertions(+), 7 deletions(-) create mode 100644 rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2 2/3] newlib: Support --with/without-newlib-tls
This RSB option defines if the --enable-newlib-reent-thread-local
(_REENT_THREAD_LOCAL_STORAGE) Newlib configuration option is used or not.
Update #4560.
---
source-builder/config/checks.cfg | 9 +
source-builder/config/gcc-common-1.cfg | 1 +
2 files changed, 10 insertions(+)
diff --git a/source-builder/config/checks.cfg b/source-builder/config/checks.cfg
index 93d4c97..da1c1da 100644
--- a/source-builder/config/checks.cfg
+++ b/source-builder/config/checks.cfg
@@ -23,6 +23,8 @@
%{?without_java:%define enable_java 0}
%{?with_objc:%define enable_objc 1}
%{?without_objc:%define enable_objc 0}
+%{?with_newlib_tls:%define enable_newlib_tls 1}
+%{?without_newlib_tls:%define enable_newlib_tls 0}
#
# Default to C++ on.
@@ -72,3 +74,10 @@
%ifn %{defined enable_obsolete}
%define enable_obsolete 0
%endif
+
+#
+# Default to Newlib thread-local storage instead of struct _reent off.
+#
+%ifn %{defined enable_newlib_tls}
+ %define enable_newlib_tls 0
+%endif
diff --git a/source-builder/config/gcc-common-1.cfg
b/source-builder/config/gcc-common-1.cfg
index 694a1f3..0eb032b 100644
--- a/source-builder/config/gcc-common-1.cfg
+++ b/source-builder/config/gcc-common-1.cfg
@@ -192,6 +192,7 @@ URL: http://gcc.gnu.org/
--enable-version-specific-runtime-libs \
--enable-newlib-io-c99-formats \
%{?disable_MAKEINFO:MAKEINFO=missing} \
+%{?enable_newlib_tls:--enable-newlib-reent-thread-local} \
%{?with_iconv:--enable-newlib-iconv} \
%{?with_iconv:--enable-newlib-iconv-encodings=%{_newlib_iconv_encodings}} \
%{?with_threads:--enable-threads}%{!?with_threads:--disable-threads} \
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [RSB 1/3] 6/7: Update Newlib
On 21/7/2022 3:21 pm, Sebastian Huber wrote: > On 20.07.22 22:52, Chris Johns wrote: >> On 20/7/2022 6:20 pm, Sebastian Huber wrote: >>> On 20/07/2022 10:11, Chris Johns wrote: >> Are these TLS allocations in newlib based on a single use of a newlib >> call >> that >> brings in the reent stuff? How does that work? > No, each TLS object is defined in the translation unit which uses the > object. > The goal is to get only those objects linked in which are needed. > Currently, the > Newlib thread delete hook pulls in some objects, however, this dependency > will > go away once the TLS destructors are implemented. If I have task A and it opens a file and writes something to a file system will it pull in the TLS support for files? >>> >>> Yes. >>> Given the TLS support is static does this mean all threads in the A app allocate the newlib file TLS variables even if they never use newlib? >>> >>> Yes. >>> My understanding of the existing reent support is tasks that do not use newlib it never allocate a reent struct? >>> >>> No, the struct _reent is allocated for all tasks if you don't use >>> CONFIGURE_DISABLE_NEWLIB_REENTRANCY (which is not recommended). How would >>> you >>> know if a task doesn't use Newlib? >> >> I thought the get would do a check and then allocate on first use. It has >> been >> many years since I looked at the implementation. >> >> I think this change is a good one because it will reduce the needed memory to >> the amount used and it will have better performance. >> >> I think option you post is a good thing to add, maybe as >> --enable-newlib-reent-tls. What will be the default? > > You mean a proper sb-set-builder option and not just a --with-newlib-tls? Not an sb option rather something using the --wtih/--without flags. I just renamed yours as `thread-local` may not be as well know as TLS. > I > would make it the default for the targets with known to work TLS support: > aarch64, arm, nios2, powerpc, riscv, and sparc. Sure it can be the default for the archs that can support it but a --without-newlib-tls option might be useful to someone using libdl if this change breaks their usage, ie linking from archives on the target. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
