Re: [RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch - online documentation
can_1w SHLL [/] # can_2w All those steps are also described in project README or you can use help app command in RTEMS terminal to get further description of commands and their arguments. We want to rewrite some other controllers for our CAN stack to provide further tests and widen the support (SJA1000 would probably be the first one on our list), but currently the priority is the full completion of the stack itself (error reports, all required IOCTLs, etc.). Best wishes, Michal Lenc ___ 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- embedded brains GmbH & Co. KG Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 mobile: +49-176-152 206 08 Registergericht: Amtsgericht München Registernummer: HRA 117265 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] bsps/powerpc: Introduction of interrupt locks
if (!ip || ip->isr!=hdl || ip->usrData!=arg) {
- rtems_interrupt_enable(flags);
+ rtems_interrupt_lock_release( _lock,
_context );
return -1;
}
*pe = 0;
- rtems_interrupt_enable(flags);
+ rtems_interrupt_lock_release( _lock, _context
);
free(ip);
return 0;
}
@@ -2304,8 +2307,9 @@ volatile UniverseIRQEntry *pe;
static int
intDoEnDis(unsigned int level, int dis)
{
-unsigned long flags, v;
+unsigned long v;
int shift;
+rtems_interrupt_lock_context lock_context;
if ( ! vmeUniverseIrqMgrInstalled || (shift = lvl2bit(level)) < 0 )
return -1;
@@ -2315,14 +2319,14 @@ int shift;
if ( !dis )
return vmeUniverseReadReg(UNIV_REGOFF_LINT_EN) & v ? 1 : 0;
- rtems_interrupt_disable(flags);
+ rtems_interrupt_lock_acquire( _lock, _context );
if ( dis<0 )
vmeUniverseWriteReg( vmeUniverseReadReg(UNIV_REGOFF_LINT_EN) &
~v, UNIV_REGOFF_LINT_EN );
else {
vmeUniverseWriteReg( vmeUniverseReadReg(UNIV_REGOFF_LINT_EN) |
v, UNIV_REGOFF_LINT_EN );
}
- rtems_interrupt_enable(flags);
- return 0;
+ rtems_interrupt_lock_release( _lock, _context );
+ return 0;
}
int
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
embedded brains GmbH & Co. KG
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
mobile: +49-176-152 206 08
Registergericht: Amtsgericht München
Registernummer: HRA 117265
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: qemu-linaro and linaro-image-tools is olde
Hello Ashish, On 2024-04-03 05:07, ashish ashish wrote: Hello all, I am trying to emulate beagle black board and support for beagle board on qemu in past can be achieved by qemu-linaro but from last 10 years there is not activity on the community of qemu-linaro and it is use many depreciated packages and hard to got it work anyone tried it or using it. If the upstream qemu didn't pick up the changes and if no one else took over maintenance, you are most likely out of luck. Your best chance to get that running (with a reasonable amount of work) would most likely be a VM with an old Linux distribution. and ppa:linaro-maintainers/tools is down(404 when adding it to apt). tried compiling from sources but it uses python2 and many depreciated python2 packages If the sources are not there anymore, that's even more difficult. You will have to search whether you find them in some archives. If it is not absolutely crucial for you to get the Qemu for BBB running, I would suggest against trying it. Did you note any RTEMS documentation, scripts or source builder recipes, that don't work and that maybe should be updated or removed? Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Documentation theme update
Hello Chris, On 2024-02-21 06:16, Chris Johns wrote: Hi, I have a patch for rtems-docs.git to move us to the pip installed sphinx-rtd-theme removing the custom theme based on sphinx-rtd-theme we currently use. I think reducing RTEMS specific adaptions is a great idea. So thank you for that. The ticket is #4994. The patch is over 4M in size as it deletes common/sphinx_rtd_theme_rtems. YOu can download it from: https://ftp.rtems.org/pub/rtems/people/chrisj/0001-sphinx-Use-the-pip-installed-sphinx-rtd-theme.patch What I am not sure about is how old Sphinx can be to build the documentation. My versions are: Sphinx7.2.6 sphinx-rtd-theme 2.0.0 sphinxcontrib-applehelp 1.0.7 sphinxcontrib-bibtex 2.6.1 sphinxcontrib-devhelp 1.0.5 sphinxcontrib-htmlhelp2.0.4 sphinxcontrib-jquery 4.1 sphinxcontrib-jsmath 1.0.1 sphinxcontrib-qthelp 1.0.6 sphinxcontrib-serializinghtml 1.1.9 Is it OK to push? I tried building the manuals with your patches on OpenSUSE. It's basically the same procedure as without the patch except that the sphinx-rtd-theme is now necessary. The result looks as expected. With the patch, the search seems to work again. That hasn't been the case with the old version. So from my point of view, the patch is a great improvement and OK. Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 08/14] mpc85xx: Support P20XX Local Access Window regs
From: Sebastian Huber
---
freebsd/sys/powerpc/mpc85xx/mpc85xx.c | 38 +++
freebsd/sys/powerpc/mpc85xx/mpc85xx.h | 2 ++
2 files changed, 40 insertions(+)
diff --git a/freebsd/sys/powerpc/mpc85xx/mpc85xx.c
b/freebsd/sys/powerpc/mpc85xx/mpc85xx.c
index ec7eaa3f..7f3df540 100644
--- a/freebsd/sys/powerpc/mpc85xx/mpc85xx.c
+++ b/freebsd/sys/powerpc/mpc85xx/mpc85xx.c
@@ -82,6 +82,29 @@ ccsr_write4(uintptr_t addr, uint32_t val)
powerpc_iomb();
}
+static int
+mpc85xx_is_p20xx(void)
+{
+ uint32_t ver;
+ int is_p20xx;
+
+ ver = SVR_VER(mfspr(SPR_SVR));
+ switch (ver) {
+ case SVR_P2010:
+ case SVR_P2010E:
+ case SVR_P2020:
+ case SVR_P2020E:
+ case SVR_P2041:
+ case SVR_P2041E:
+ is_p20xx = 1;
+ break;
+ default:
+ is_p20xx = 0;
+ }
+
+ return (is_p20xx);
+}
+
int
law_getmax(void)
{
@@ -100,6 +123,14 @@ law_getmax(void)
case SVR_MPC8548E:
law_max = 10;
break;
+ case SVR_P2010:
+ case SVR_P2010E:
+ case SVR_P2020:
+ case SVR_P2020E:
+ case SVR_P2041:
+ case SVR_P2041E:
+ law_max = 12;
+ break;
case SVR_P5020:
case SVR_P5020E:
case SVR_P5021:
@@ -124,6 +155,10 @@ law_write(uint32_t n, uint64_t bar, uint32_t sr)
ccsr_write4(OCP85XX_LAWBARL(n), bar);
ccsr_write4(OCP85XX_LAWSR_QORIQ(n), sr);
ccsr_read4(OCP85XX_LAWSR_QORIQ(n));
+ } else if (mpc85xx_is_p20xx()) {
+ ccsr_write4(OCP85XX_LAWBAR_P20XX(n), bar >> 12);
+ ccsr_write4(OCP85XX_LAWAR(n), sr);
+ ccsr_read4(OCP85XX_LAWAR(n));
} else {
ccsr_write4(OCP85XX_LAWBAR(n), bar >> 12);
ccsr_write4(OCP85XX_LAWSR_85XX(n), sr);
@@ -148,6 +183,9 @@ law_read(uint32_t n, uint64_t *bar, uint32_t *sr)
*bar = (uint64_t)ccsr_read4(OCP85XX_LAWBARH(n)) << 32 |
ccsr_read4(OCP85XX_LAWBARL(n));
*sr = ccsr_read4(OCP85XX_LAWSR_QORIQ(n));
+ } else if (mpc85xx_is_p20xx()) {
+ *bar = (uint64_t)ccsr_read4(OCP85XX_LAWBAR_P20XX(n)) << 12;
+ *sr = ccsr_read4(OCP85XX_LAWAR(n));
} else {
*bar = (uint64_t)ccsr_read4(OCP85XX_LAWBAR(n)) << 12;
*sr = ccsr_read4(OCP85XX_LAWSR_85XX(n));
diff --git a/freebsd/sys/powerpc/mpc85xx/mpc85xx.h
b/freebsd/sys/powerpc/mpc85xx/mpc85xx.h
index 1a0be6cb..0f1ee5cc 100644
--- a/freebsd/sys/powerpc/mpc85xx/mpc85xx.h
+++ b/freebsd/sys/powerpc/mpc85xx/mpc85xx.h
@@ -79,6 +79,8 @@ extern vm_size_t ccsrbar_size;
#defineOCP85XX_LAWSR_85XX(n) (CCSRBAR_VA + 0xc10 + 0x10 * (n))
#defineOCP85XX_LAWSR(n)(mpc85xx_is_qoriq() ?
OCP85XX_LAWSR_QORIQ(n) : \
OCP85XX_LAWSR_85XX(n))
+#defineOCP85XX_LAWBAR_P20XX(n) (CCSRBAR_VA + 0xc08 + 0x20 * (n))
+#defineOCP85XX_LAWAR(n)(CCSRBAR_VA + 0xc10 + 0x20 * (n))
/* Attribute register */
#defineOCP85XX_ENA_MASK0x8000
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 03/14] mpc85xx: Port to RTEMS
From: Sebastian Huber
---
freebsd/sys/dev/ofw/ofwpci.c | 16
freebsd/sys/dev/pci/pci.c | 2 +
freebsd/sys/kern/subr_bus.c | 2 +-
freebsd/sys/powerpc/include/machine/spr.h | 3 ++
freebsd/sys/powerpc/mpc85xx/mpc85xx.c | 4 ++
freebsd/sys/powerpc/mpc85xx/pci_mpc85xx.c | 32 ++-
libbsd.py | 25
rtemsbsd/include/bsp/nexus-devices.h | 8
rtemsbsd/sys/powerpc/platform_mpc85xx.c | 48 +++
9 files changed, 137 insertions(+), 3 deletions(-)
create mode 100644 rtemsbsd/sys/powerpc/platform_mpc85xx.c
diff --git a/freebsd/sys/dev/ofw/ofwpci.c b/freebsd/sys/dev/ofw/ofwpci.c
index d576cb67..c18de9d2 100644
--- a/freebsd/sys/dev/ofw/ofwpci.c
+++ b/freebsd/sys/dev/ofw/ofwpci.c
@@ -47,7 +47,9 @@ __FBSDID("$FreeBSD$");
#include
#include
+#ifndef __rtems__
#include
+#endif /* __rtems__ */
#include
#include
@@ -79,9 +81,11 @@ static int ofw_pci_deactivate_resource(device_t, device_t,
int, int,
static int ofw_pci_adjust_resource(device_t, device_t, int,
struct resource *, rman_res_t, rman_res_t);
+#ifndef __rtems__
#ifdef __powerpc__
static bus_space_tag_t ofw_pci_bus_get_bus_tag(device_t, device_t);
#endif
+#endif /* __rtems__ */
/*
* pcib interface
@@ -118,9 +122,11 @@ static device_method_t ofw_pci_methods[] = {
DEVMETHOD(bus_activate_resource,ofw_pci_activate_resource),
DEVMETHOD(bus_deactivate_resource, ofw_pci_deactivate_resource),
DEVMETHOD(bus_adjust_resource, ofw_pci_adjust_resource),
+#ifndef __rtems__
#ifdef __powerpc__
DEVMETHOD(bus_get_bus_tag, ofw_pci_bus_get_bus_tag),
#endif
+#endif /* __rtems__ */
/* pcib interface */
DEVMETHOD(pcib_maxslots,ofw_pci_maxslots),
@@ -531,9 +537,13 @@ ofw_pci_activate_resource(device_t bus, device_t child,
int type, int rid,
printf("ofw_pci mapdev: start %jx, len %jd\n",
(rman_res_t)start, rman_get_size(res));
+#ifndef __rtems__
tag = BUS_GET_BUS_TAG(child, child);
if (tag == NULL)
return (ENOMEM);
+#else /* __rtems__ */
+ tag = 0;
+#endif /* __rtems__ */
rman_set_bustag(res, tag);
rv = bus_space_map(tag, start,
@@ -547,6 +557,7 @@ ofw_pci_activate_resource(device_t bus, device_t child, int
type, int rid,
return (rman_activate_resource(res));
}
+#ifndef __rtems__
#ifdef __powerpc__
static bus_space_tag_t
ofw_pci_bus_get_bus_tag(device_t bus, device_t child)
@@ -555,20 +566,25 @@ ofw_pci_bus_get_bus_tag(device_t bus, device_t child)
return (_le_tag);
}
#endif
+#endif /* __rtems__ */
static int
ofw_pci_deactivate_resource(device_t bus, device_t child, int type, int rid,
struct resource *res)
{
+#ifndef __rtems__
vm_size_t psize;
+#endif /* __rtems__ */
if (type != SYS_RES_IOPORT && type != SYS_RES_MEMORY) {
return (bus_generic_deactivate_resource(bus, child, type, rid,
res));
}
+#ifndef __rtems__
psize = rman_get_size(res);
pmap_unmapdev((vm_offset_t)rman_get_virtual(res), psize);
+#endif /* __rtems__ */
return (rman_deactivate_resource(res));
}
diff --git a/freebsd/sys/dev/pci/pci.c b/freebsd/sys/dev/pci/pci.c
index f1501208..0cc72dba 100644
--- a/freebsd/sys/dev/pci/pci.c
+++ b/freebsd/sys/dev/pci/pci.c
@@ -3694,6 +3694,7 @@ pci_reserve_secbus(device_t bus, device_t dev, pcicfgregs
*cfg,
}
break;
+#ifndef __rtems__
case 0x00dd10de:
/* Compaq R3000 BIOS sets wrong subordinate bus number. */
if ((cp = kern_getenv("smbios.planar.maker")) == NULL)
@@ -3715,6 +3716,7 @@ pci_reserve_secbus(device_t bus, device_t dev, pcicfgregs
*cfg,
PCI_WRITE_CONFIG(bus, dev, sub_reg, sub_bus, 1);
}
break;
+#endif /* __rtems__ */
}
if (bootverbose)
diff --git a/freebsd/sys/kern/subr_bus.c b/freebsd/sys/kern/subr_bus.c
index e43d0030..c4b8c04d 100644
--- a/freebsd/sys/kern/subr_bus.c
+++ b/freebsd/sys/kern/subr_bus.c
@@ -5588,7 +5588,6 @@ bus_data_generation_update(void)
bus_data_generation++;
}
-#ifndef __rtems__
int
bus_free_resource(device_t dev, int type, struct resource *r)
{
@@ -5597,6 +5596,7 @@ bus_free_resource(device_t dev, int type, struct resource
*r)
return (bus_release_resource(dev, type, rman_get_rid(r), r));
}
+#ifndef __rtems__
device_t
device_lookup_by_name(const char *name)
{
diff --git a/freebsd/sys/powerpc/include/machine/spr.h
b/freebsd/sys/powerpc/include/machine/spr.h
index 228e3955..4d108593 100644
--- a/freebsd/sys/powerpc/include/machine/spr.h
+++ b/freebsd/sys/powerpc/include/machine/spr.h
@@ -31,6 +31,9 @@
#ifndef _POWERPC_SPR_H_
#define_POWERPC_SPR_H_
+#ifdef __rtems__
+#define BOOKE
+#endif /* __rtems__
[PATCH rtems-libbsd 07/14] Enable NEW_PCIB
From: Sebastian Huber --- rtemsbsd/include/machine/resource.h | 1 + .../include/machine/rtems-bsd-kernel-space.h | 8 +++ rtemsbsd/rtems/rtems-kernel-nexus.c | 21 +++ 3 files changed, 30 insertions(+) diff --git a/rtemsbsd/include/machine/resource.h b/rtemsbsd/include/machine/resource.h index ad4f0f29..babc1ae6 100644 --- a/rtemsbsd/include/machine/resource.h +++ b/rtemsbsd/include/machine/resource.h @@ -45,5 +45,6 @@ #define SYS_RES_MEMORY 3 #define SYS_RES_IOPORT 4 #define SYS_RES_GPIO 5 +#define PCI_RES_BUS 6 #endif /* _RTEMS_BSD_MACHINE_RESOURCE_H_ */ diff --git a/rtemsbsd/include/machine/rtems-bsd-kernel-space.h b/rtemsbsd/include/machine/rtems-bsd-kernel-space.h index 09f3c64d..2b45c2db 100644 --- a/rtemsbsd/include/machine/rtems-bsd-kernel-space.h +++ b/rtemsbsd/include/machine/rtems-bsd-kernel-space.h @@ -247,6 +247,14 @@ dev_t rtems_bsd__makedev(int _M, int _m); struct dirent; void dirent_terminate(struct dirent *dp); +/* + * Enable the "new" PCI-PCI bridge driver, since this is going to be the future + * FreeBSD driver: + * + * https://reviews.freebsd.org/D32954 + */ +#defineNEW_PCIB 1 + #ifdef __cplusplus } #endif /* __cplusplus */ diff --git a/rtemsbsd/rtems/rtems-kernel-nexus.c b/rtemsbsd/rtems/rtems-kernel-nexus.c index 8fc879fe..c5ee33d8 100644 --- a/rtemsbsd/rtems/rtems-kernel-nexus.c +++ b/rtemsbsd/rtems/rtems-kernel-nexus.c @@ -57,6 +57,7 @@ #endif #include +#include #include #include @@ -103,6 +104,10 @@ static struct rman mem_rman; static struct rman irq_rman; +#ifdef RTEMS_BSD_MODULE_PCI +static struct rman pci_rman; +#endif + #if defined(RTEMS_BSP_PCI_IO_REGION_BASE) static struct rman port_rman; #endif @@ -137,6 +142,17 @@ nexus_probe(device_t dev) err = rman_manage_region(_rman, irq_rman.rm_start, irq_rman.rm_end); BSD_ASSERT(err == 0); +#ifdef RTEMS_BSD_MODULE_PCI + pci_rman.rm_start = 0; + pci_rman.rm_end = ~0UL; + pci_rman.rm_type = RMAN_ARRAY; + pci_rman.rm_descr = "PCI bus"; + err = rman_init(_rman) != 0; + BSD_ASSERT(err == 0); + err = rman_manage_region(_rman, pci_rman.rm_start, pci_rman.rm_end); + BSD_ASSERT(err == 0); +#endif + #if defined(RTEMS_BSP_PCI_IO_REGION_BASE) port_rman.rm_start = 0; port_rman.rm_end = ~0UL; @@ -191,6 +207,11 @@ nexus_alloc_resource(device_t bus, device_t child, int type, int *rid, case SYS_RES_IRQ: rm = _rman; break; +#ifdef RTEMS_BSD_MODULE_PCI + case PCI_RES_BUS: + rm = _rman; + break; +#endif #if defined(RTEMS_BSP_PCI_IO_REGION_BASE) case SYS_RES_IOPORT: rm = _rman; -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 06/14] Include missing header file
From: Sebastian Huber
---
rtemsbsd/rtems/rtems-kernel-pci_bus.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/rtemsbsd/rtems/rtems-kernel-pci_bus.c
b/rtemsbsd/rtems/rtems-kernel-pci_bus.c
index d344e7a3..67324dd8 100644
--- a/rtemsbsd/rtems/rtems-kernel-pci_bus.c
+++ b/rtemsbsd/rtems/rtems-kernel-pci_bus.c
@@ -44,6 +44,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
#include
#include
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 09/14] pci_mpc85xx.c: Disable reset during initialization
From: Sebastian Huber
---
freebsd/sys/powerpc/mpc85xx/pci_mpc85xx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/freebsd/sys/powerpc/mpc85xx/pci_mpc85xx.c
b/freebsd/sys/powerpc/mpc85xx/pci_mpc85xx.c
index beaf96e8..47879e68 100644
--- a/freebsd/sys/powerpc/mpc85xx/pci_mpc85xx.c
+++ b/freebsd/sys/powerpc/mpc85xx/pci_mpc85xx.c
@@ -383,6 +383,7 @@ fsl_pcib_attach(device_t dev)
PCIM_CMD_PORTEN;
fsl_pcib_cfgwrite(sc, 0, 0, 0, PCIR_COMMAND, cfgreg, 2);
+#ifndef __rtems__
/* Reset the bus. Needed for Radeon video cards. */
brctl = fsl_pcib_read_config(sc->sc_dev, 0, 0, 0,
PCIR_BRIDGECTL_1, 1);
@@ -394,6 +395,7 @@ fsl_pcib_attach(device_t dev)
fsl_pcib_write_config(sc->sc_dev, 0, 0, 0,
PCIR_BRIDGECTL_1, brctl, 1);
DELAY(10);
+#endif /* __rtems__ */
if (sc->sc_pcie) {
ltssm = fsl_pcib_cfgread(sc, 0, 0, 0, PCIR_LTSSM, 1);
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 05/14] Add pic_if.m
From: Sebastian Huber
---
Makefile.todo | 10 ++
rtemsbsd/include/rtems/bsd/local/pic_if.h | 133 ++
rtemsbsd/local/pic_if.c | 69 +++
3 files changed, 212 insertions(+)
create mode 100644 rtemsbsd/include/rtems/bsd/local/pic_if.h
create mode 100644 rtemsbsd/local/pic_if.c
diff --git a/Makefile.todo b/Makefile.todo
index 36951c55..111beb07 100644
--- a/Makefile.todo
+++ b/Makefile.todo
@@ -34,6 +34,8 @@ GENERATED += $(LOCAL_INC)/pci_if.h
GENERATED += $(LOCAL_SRC)/pci_if.c
GENERATED += $(LOCAL_INC)/pcib_if.h
GENERATED += $(LOCAL_SRC)/pcib_if.c
+GENERATED += $(LOCAL_INC)/pic_if.h
+GENERATED += $(LOCAL_SRC)/pic_if.c
GENERATED += $(LOCAL_INC)/mmcbr_if.h
GENERATED += $(LOCAL_SRC)/mmcbr_if.c
GENERATED += $(LOCAL_INC)/mmcbus_if.h
@@ -166,6 +168,14 @@ $(LOCAL_SRC)/pcib_if.c:
$(FREEBSD_SRC)/sys/dev/pci/pcib_if.m
awk -f $(TOOLS)/makeobjops.awk $< -c
mv pcib_if.c $@
+$(LOCAL_INC)/pic_if.h: $(FREEBSD_SRC)/sys/powerpc/powerpc/pic_if.m
+ awk -f $(TOOLS)/makeobjops.awk $< -h
+ mv pic_if.h $@
+
+$(LOCAL_SRC)/pic_if.c: $(FREEBSD_SRC)/sys/powerpc/powerpc/pic_if.m
+ awk -f $(TOOLS)/makeobjops.awk $< -c
+ mv pic_if.c $@
+
$(LOCAL_INC)/mmcbus_if.h: $(FREEBSD_SRC)/sys/dev/mmc/mmcbus_if.m
awk -f $(TOOLS)/makeobjops.awk $< -h
mv mmcbus_if.h $@
diff --git a/rtemsbsd/include/rtems/bsd/local/pic_if.h
b/rtemsbsd/include/rtems/bsd/local/pic_if.h
new file mode 100644
index ..a903a25d
--- /dev/null
+++ b/rtemsbsd/include/rtems/bsd/local/pic_if.h
@@ -0,0 +1,133 @@
+/*
+ * This file is produced automatically.
+ * Do not modify anything in here by hand.
+ *
+ * Created from source file
+ * freebsd-org/sys/powerpc/powerpc/pic_if.m
+ * with
+ * makeobjops.awk
+ *
+ * See the source file for legal information
+ */
+
+
+#ifndef _pic_if_h_
+#define _pic_if_h_
+
+/** @brief Unique descriptor for the PIC_BIND() method */
+extern struct kobjop_desc pic_bind_desc;
+/** @brief A function implementing the PIC_BIND() method */
+typedef void pic_bind_t(device_t dev, u_int irq, cpuset_t cpumask, void
**priv);
+
+static __inline void PIC_BIND(device_t dev, u_int irq, cpuset_t cpumask,
+ void **priv)
+{
+ kobjop_t _m;
+ KOBJOPLOOKUP(((kobj_t)dev)->ops,pic_bind);
+ ((pic_bind_t *) _m)(dev, irq, cpumask, priv);
+}
+
+/** @brief Unique descriptor for the PIC_TRANSLATE_CODE() method */
+extern struct kobjop_desc pic_translate_code_desc;
+/** @brief A function implementing the PIC_TRANSLATE_CODE() method */
+typedef void pic_translate_code_t(device_t dev, u_int irq, int code,
+ enum intr_trigger *trig,
+ enum intr_polarity *pol);
+
+static __inline void PIC_TRANSLATE_CODE(device_t dev, u_int irq, int code,
+enum intr_trigger *trig,
+enum intr_polarity *pol)
+{
+ kobjop_t _m;
+ KOBJOPLOOKUP(((kobj_t)dev)->ops,pic_translate_code);
+ ((pic_translate_code_t *) _m)(dev, irq, code, trig, pol);
+}
+
+/** @brief Unique descriptor for the PIC_CONFIG() method */
+extern struct kobjop_desc pic_config_desc;
+/** @brief A function implementing the PIC_CONFIG() method */
+typedef void pic_config_t(device_t dev, u_int irq, enum intr_trigger trig,
+ enum intr_polarity pol);
+
+static __inline void PIC_CONFIG(device_t dev, u_int irq, enum intr_trigger
trig,
+enum intr_polarity pol)
+{
+ kobjop_t _m;
+ KOBJOPLOOKUP(((kobj_t)dev)->ops,pic_config);
+ ((pic_config_t *) _m)(dev, irq, trig, pol);
+}
+
+/** @brief Unique descriptor for the PIC_DISPATCH() method */
+extern struct kobjop_desc pic_dispatch_desc;
+/** @brief A function implementing the PIC_DISPATCH() method */
+typedef void pic_dispatch_t(device_t dev, struct trapframe *tf);
+
+static __inline void PIC_DISPATCH(device_t dev, struct trapframe *tf)
+{
+ kobjop_t _m;
+ KOBJOPLOOKUP(((kobj_t)dev)->ops,pic_dispatch);
+ ((pic_dispatch_t *) _m)(dev, tf);
+}
+
+/** @brief Unique descriptor for the PIC_ENABLE() method */
+extern struct kobjop_desc pic_enable_desc;
+/** @brief A function implementing the PIC_ENABLE() method */
+typedef void pic_enable_t(device_t dev, u_int irq, u_int vector, void **priv);
+
+static __inline void PIC_ENABLE(device_t dev, u_int irq, u_int vector,
+void **priv)
+{
+ kobjop_t _m;
+ KOBJOPLOOKUP(((kobj_t)dev)->ops,pic_enable);
+ ((pic_enable_t *) _m)(dev, irq, vector, priv);
+}
+
+/** @brief Unique descriptor for the PIC_EOI() method */
+extern struct kobjop_desc pic_eoi_desc;
+/** @brief A function implementing the PIC_EOI() method */
+typedef void pic_eoi_t(device_t dev, u_int irq, void *priv);
+
+static __inline void PIC_EOI(device_t dev, u_int irq, void *priv)
+{
+ kobjop_t _m;
+
[PATCH rtems-libbsd 10/14] Enable kernel space pci_find_device()
From: Sebastian Huber
---
freebsd/sys/dev/pci/pci.c | 2 --
rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h | 1 +
rtemsbsd/rtems/rtems-kernel-pci_bus.c | 1 +
3 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/freebsd/sys/dev/pci/pci.c b/freebsd/sys/dev/pci/pci.c
index 3789a73e..5c76f1d5 100644
--- a/freebsd/sys/dev/pci/pci.c
+++ b/freebsd/sys/dev/pci/pci.c
@@ -471,7 +471,6 @@ pci_find_dbsf(uint32_t domain, uint8_t bus, uint8_t slot,
uint8_t func)
return (NULL);
}
-#ifndef __rtems__
/* Find a device_t by vendor/device ID */
device_t
@@ -488,7 +487,6 @@ pci_find_device(uint16_t vendor, uint16_t device)
return (NULL);
}
-#endif /* __rtems__ */
device_t
pci_find_class(uint8_t class, uint8_t subclass)
diff --git a/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h
b/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h
index 94e0d56f..c74eadbc 100644
--- a/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h
+++ b/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h
@@ -3847,6 +3847,7 @@
#definepci_find_cap_method _bsd_pci_find_cap_method
#definepci_find_class _bsd_pci_find_class
#definepci_find_dbsf _bsd_pci_find_dbsf
+#definepci_find_device _bsd_pci_find_device
#definepci_find_extcap_method _bsd_pci_find_extcap_method
#definepci_find_htcap_method _bsd_pci_find_htcap_method
#definepci_find_next_cap_method _bsd_pci_find_next_cap_method
diff --git a/rtemsbsd/rtems/rtems-kernel-pci_bus.c
b/rtemsbsd/rtems/rtems-kernel-pci_bus.c
index 67324dd8..6cbae125 100644
--- a/rtemsbsd/rtems/rtems-kernel-pci_bus.c
+++ b/rtemsbsd/rtems/rtems-kernel-pci_bus.c
@@ -52,6 +52,7 @@ __FBSDID("$FreeBSD$");
#include
#include
+#undef pci_find_device
#define pci_find_device rtems_pci_find_device
#if HAVE_RTEMS_PCI_H
#include
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 11/14] pci_mpc85xx: Ensure access order for config-regs
The CFG_ADDR has to be written before reading or writing the CFG_DATA.
---
freebsd/sys/powerpc/mpc85xx/pci_mpc85xx.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/freebsd/sys/powerpc/mpc85xx/pci_mpc85xx.c
b/freebsd/sys/powerpc/mpc85xx/pci_mpc85xx.c
index 47879e68..b479eb33 100644
--- a/freebsd/sys/powerpc/mpc85xx/pci_mpc85xx.c
+++ b/freebsd/sys/powerpc/mpc85xx/pci_mpc85xx.c
@@ -80,6 +80,7 @@ __FBSDID("$FreeBSD$");
#include
#ifdef __rtems__
#include
+#include
#endif /* __rtems__ */
#defineREG_CFG_ADDR0x
@@ -460,6 +461,9 @@ fsl_pcib_cfgread(struct fsl_pcib_softc *sc, u_int bus,
u_int slot, u_int func,
mtx_lock_spin(>sc_cfg_mtx);
bus_space_write_4(sc->sc_bst, sc->sc_bsh, REG_CFG_ADDR, addr);
+#ifdef __rtems__
+ ppc_enforce_in_order_execution_of_io();
+#endif
switch (bytes) {
case 1:
@@ -498,6 +502,9 @@ fsl_pcib_cfgwrite(struct fsl_pcib_softc *sc, u_int bus,
u_int slot, u_int func,
mtx_lock_spin(>sc_cfg_mtx);
bus_space_write_4(sc->sc_bst, sc->sc_bsh, REG_CFG_ADDR, addr);
+#ifdef __rtems__
+ ppc_enforce_in_order_execution_of_io();
+#endif
switch (bytes) {
case 1:
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 12/14] Add Tsi148 driver template
From: Sebastian Huber
---
buildset/default.ini | 1 +
buildset/everything.ini | 3 +
libbsd.py| 17
rtemsbsd/include/bsp/nexus-devices.h | 4 +
rtemsbsd/sys/dev/vme/tsi148.c| 123 +++
5 files changed, 148 insertions(+)
create mode 100644 rtemsbsd/sys/dev/vme/tsi148.c
diff --git a/buildset/default.ini b/buildset/default.ini
index fca70f9c..acb1226d 100644
--- a/buildset/default.ini
+++ b/buildset/default.ini
@@ -65,6 +65,7 @@ rpc = on
rpc_user = on
rtems = on
tests = on
+tsi148 = off
tty = on
user_space = on
user_space_wlanstats = off
diff --git a/buildset/everything.ini b/buildset/everything.ini
index 0eee99e7..b4e57246 100644
--- a/buildset/everything.ini
+++ b/buildset/everything.ini
@@ -17,3 +17,6 @@ usr_sbin_wpa_supplicant = on
# IPSec
netipsec = on
+
+# VME
+tsi148 = on
diff --git a/libbsd.py b/libbsd.py
index 73df656b..ed40106c 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -3139,6 +3139,22 @@ class pci(builder.Module):
mm.generator['source']()
)
+#
+# TSI148
+#
+class tsi148(builder.Module):
+
+def __init__(self, manager):
+super(tsi148, self).__init__(manager, type(self).__name__)
+
+def generate(self):
+mm = self.manager
+self.addRTEMSKernelSourceFiles(
+[
+'sys/dev/vme/tsi148.c',
+],
+mm.generator['source']()
+)
#
# User space
@@ -5666,6 +5682,7 @@ def load(mm):
# Add PCI
mm.addModule(pci(mm))
+mm.addModule(tsi148(mm))
# Add NIC devices
mm.addModule(dev_nic(mm))
diff --git a/rtemsbsd/include/bsp/nexus-devices.h
b/rtemsbsd/include/bsp/nexus-devices.h
index e764306e..ac4a52a1 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -267,6 +267,10 @@ SYSINIT_DRIVER_REFERENCE(pcib, pci);
SYSINIT_DRIVER_REFERENCE(rcpcib, pci);
#endif
+#ifdef RTEMS_BSD_MODULE_TSI148
+SYSINIT_DRIVER_REFERENCE(tsi148, pci);
+#endif
+
#endif /* QORIQ_CHIP_IS_T_VARIANT(QORIQ_CHIP_VARIANT) */
#elif defined(LIBBSP_POWERPC_TQM8XX_BSP_H)
diff --git a/rtemsbsd/sys/dev/vme/tsi148.c b/rtemsbsd/sys/dev/vme/tsi148.c
new file mode 100644
index ..56c746bc
--- /dev/null
+++ b/rtemsbsd/sys/dev/vme/tsi148.c
@@ -0,0 +1,123 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 2022 embedded brains GmbH (http://www.embedded-brains.de)
+ *
+ * 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 COPYRIGHT HOLDERS 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 COPYRIGHT OWNER 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
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+struct tsi148 {
+ device_tdev;
+ int mem_rid;
+ struct resource *mem_res;
+ int irq_rid;
+ struct resource *irq_res;
+ void*irq_cookie;
+};
+
+static void
+tsi148_intr(void *arg)
+{
+ struct tsi148 *sc;
+
+ sc = arg;
+}
+
+static int
+tsi148_probe(device_t dev)
+{
+
+ if (pci_get_devid(dev) == 0x014810e3) {
+ device_set_desc(dev, "Tundra Tsi148 PCI-VME bridge");
+ return (BUS_PROBE_GENERIC);
+ }
+
+ return (ENXIO);
+}
+
+static int
+tsi148_attach(device_t dev)
+{
+ struct tsi148 *sc;
+
+ sc = device_get_softc(dev);
+ sc->dev = dev;
+
+ sc->mem_rid = PCIR_BAR(0);
+ sc->mem_res = bus_alloc_resource_any(sc->dev, SYS_RES_MEMORY,
+ >mem_rid, RF_ACTIVE);
+ if (sc->mem_res == NULL) {
+ return (ENOMEM);
+ }
+
+ sc->irq_rid = 0;
+ sc->irq_res = bus_alloc_resource_any(sc->dev, SYS_RES_IRQ,
+ >irq_rid,
[PATCH rtems-libbsd 02/14] mpc85xx: Import from FreeBSD
From: Sebastian Huber
---
freebsd/sys/dev/ofw/ofwpci.c | 677 +
freebsd/sys/dev/ofw/ofwpci.h | 87 ++
freebsd/sys/dev/pci/pci_subr.c| 388 +++
freebsd/sys/powerpc/include/machine/hid.h | 224
freebsd/sys/powerpc/include/machine/pio.h | 306 ++
.../sys/powerpc/include/machine/platformvar.h | 91 ++
freebsd/sys/powerpc/mpc85xx/mpc85xx.c | 361 +++
freebsd/sys/powerpc/mpc85xx/mpc85xx.h | 177
freebsd/sys/powerpc/mpc85xx/pci_mpc85xx.c | 959 ++
.../sys/powerpc/mpc85xx/pci_mpc85xx_pcib.c| 111 ++
.../sys/powerpc/mpc85xx/platform_mpc85xx.c| 710 +
freebsd/sys/powerpc/ofw/ofw_pcib_pci.c| 178
12 files changed, 4269 insertions(+)
create mode 100644 freebsd/sys/dev/ofw/ofwpci.c
create mode 100644 freebsd/sys/dev/ofw/ofwpci.h
create mode 100644 freebsd/sys/dev/pci/pci_subr.c
create mode 100644 freebsd/sys/powerpc/include/machine/hid.h
create mode 100644 freebsd/sys/powerpc/include/machine/pio.h
create mode 100644 freebsd/sys/powerpc/include/machine/platformvar.h
create mode 100644 freebsd/sys/powerpc/mpc85xx/mpc85xx.c
create mode 100644 freebsd/sys/powerpc/mpc85xx/mpc85xx.h
create mode 100644 freebsd/sys/powerpc/mpc85xx/pci_mpc85xx.c
create mode 100644 freebsd/sys/powerpc/mpc85xx/pci_mpc85xx_pcib.c
create mode 100644 freebsd/sys/powerpc/mpc85xx/platform_mpc85xx.c
create mode 100644 freebsd/sys/powerpc/ofw/ofw_pcib_pci.c
diff --git a/freebsd/sys/dev/ofw/ofwpci.c b/freebsd/sys/dev/ofw/ofwpci.c
new file mode 100644
index ..d576cb67
--- /dev/null
+++ b/freebsd/sys/dev/ofw/ofwpci.c
@@ -0,0 +1,677 @@
+#include
+
+/*-
+ * Copyright (c) 2011 Nathan Whitehorn
+ * All rights reserved.
+ *
+ * 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
+__FBSDID("$FreeBSD$");
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+/*
+ * If it is necessary to set another value of this for
+ * some platforms it should be set at fdt.h file
+ */
+#ifndef PCI_MAP_INTR
+#definePCI_MAP_INTR4
+#endif
+
+#definePCI_INTR_PINS 4
+
+/*
+ * bus interface.
+ */
+static struct resource * ofw_pci_alloc_resource(device_t, device_t,
+int, int *, rman_res_t, rman_res_t, rman_res_t, u_int);
+static int ofw_pci_release_resource(device_t, device_t, int, int,
+struct resource *);
+static int ofw_pci_activate_resource(device_t, device_t, int, int,
+struct resource *);
+static int ofw_pci_deactivate_resource(device_t, device_t, int, int,
+struct resource *);
+static int ofw_pci_adjust_resource(device_t, device_t, int,
+struct resource *, rman_res_t, rman_res_t);
+
+#ifdef __powerpc__
+static bus_space_tag_t ofw_pci_bus_get_bus_tag(device_t, device_t);
+#endif
+
+/*
+ * pcib interface
+ */
+static int ofw_pci_maxslots(device_t);
+
+/*
+ * ofw_bus interface
+ */
+static phandle_t ofw_pci_get_node(device_t, device_t);
+
+/*
+ * local methods
+ */
+static int ofw_pci_fill_ranges(phandle_t, struct ofw_pci_range *);
+static struct rman *ofw_pci_get_rman(struct ofw_pci_softc *, int, u_int);
+
+/*
+ * Driver methods.
+ */
+static device_method_t ofw_pci_methods[] = {
+
+ /* Device interface */
+ DEVMETHOD(device_attach,ofw_pci_attach),
+
+ /* Bus interface */
+ DEVMETHOD(bus_print_child, bus_generic_print_child),
+ DEVMETHOD(bus_read_ivar,ofw_pci_read_ivar),
+ DEVMETHOD(bus_write_ivar, ofw_pci_write_ivar),
+ DEVMETHOD(bus_setup_intr,
[PATCH rtems-libbsd 13/14] tsi148: Add an RTEMS VME glue layer
The glue layer provides the necessary function so that the Tsi148 driver
in the BSP can use the PCI functionality from libbsd.
---
libbsd.py | 1 +
rtemsbsd/sys/dev/vme/tsi148.c | 24 +++-
rtemsbsd/sys/dev/vme/vme-rtems-compat.c | 143
3 files changed, 167 insertions(+), 1 deletion(-)
create mode 100644 rtemsbsd/sys/dev/vme/vme-rtems-compat.c
diff --git a/libbsd.py b/libbsd.py
index ed40106c..b05ea069 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -3152,6 +3152,7 @@ class tsi148(builder.Module):
self.addRTEMSKernelSourceFiles(
[
'sys/dev/vme/tsi148.c',
+'sys/dev/vme/vme-rtems-compat.c',
],
mm.generator['source']()
)
diff --git a/rtemsbsd/sys/dev/vme/tsi148.c b/rtemsbsd/sys/dev/vme/tsi148.c
index 56c746bc..99c3cfcd 100644
--- a/rtemsbsd/sys/dev/vme/tsi148.c
+++ b/rtemsbsd/sys/dev/vme/tsi148.c
@@ -27,6 +27,10 @@
#include
+#include
+#ifdef LIBBSP_POWERPC_QORIQ_BSP_H
+#include
+
#include
#include
#include
@@ -37,6 +41,8 @@
#include
#include
+#include
+
struct tsi148 {
device_tdev;
int mem_rid;
@@ -52,6 +58,13 @@ tsi148_intr(void *arg)
struct tsi148 *sc;
sc = arg;
+
+ /*
+* Note: This interrupt is never used. It would be used in case of MSIs.
+* But the Tsi148 can't generate them. So this interrupt must never
+* happen.
+*/
+ puts("tsi148_intr: Unexpected interrupt. Should never happen.\n");
}
static int
@@ -71,6 +84,11 @@ tsi148_attach(device_t dev)
{
struct tsi148 *sc;
+ if (bsp_vme_pcie_base_address != 0) {
+ puts("tsi148: Another instance is already attached.\n");
+ return (ENXIO);
+ }
+
sc = device_get_softc(dev);
sc->dev = dev;
@@ -94,7 +112,10 @@ tsi148_attach(device_t dev)
return (ENOMEM);
}
- return (ENXIO);
+ bsp_vme_pcie_base_address = sc->mem_res->r_bushandle;
+ BSP_vme_config();
+
+ return 0;
}
static int
@@ -121,3 +142,4 @@ static driver_t tsi148_driver = {
static devclass_t tsi148_devclass;
DRIVER_MODULE(tsi148, pci, tsi148_driver, tsi148_devclass, NULL, 0);
+#endif /* LIBBSP_POWERPC_QORIQ_BSP_H */
diff --git a/rtemsbsd/sys/dev/vme/vme-rtems-compat.c
b/rtemsbsd/sys/dev/vme/vme-rtems-compat.c
new file mode 100644
index ..c5ce8d84
--- /dev/null
+++ b/rtemsbsd/sys/dev/vme/vme-rtems-compat.c
@@ -0,0 +1,143 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 2023 embedded brains GmbH
+ *
+ * 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 COPYRIGHT HOLDERS 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 COPYRIGHT OWNER 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.
+ */
+
+/*
+ * This file is a glue layer that allows the TSI148 RTEMS VME driver to use the
+ * libbsd PCI support.
+ */
+
+typedef void FILE;
+
+#define __INSIDE_RTEMS_BSP__
+
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+
+#undef pci_find_device
+
+static device_t dev;
+
+static int
+read_config_byte(unsigned char bus, unsigned char slot, unsigned char func,
+unsigned char reg, uint8_t *val)
+{
+ *val = (uint8_t)pci_read_config(dev, reg, 1);
+ return 0;
+}
+
+static int
+read_config_word(unsigned char bus, unsigned char slot, unsigned char func,
+unsigned char reg, uint16_t *val)
+{
+ *val = (uint16_t)pci_read_config(dev, reg, 2);
+ return 0;
+}
+
+static int
+read_config_dword(unsigned char bus, unsigned char slot, unsigned char func,
+unsigned char reg, uint32_t *val)
+{
+ *val = pci_read_config(dev, reg, 4);
+ return 0;
+}
+
+static int
+write_config_byte(unsigned char bus, unsigned char slot, unsigned
[PATCH rtems-libbsd 14/14] testsuite: Add a VME test
Note: This test currently only works with a board with a Tsi148 like the
MVME2500. For other boards it will print only a message.
---
libbsd.py | 2 +
testsuite/vme01/test_main.c | 80 +
2 files changed, 82 insertions(+)
create mode 100644 testsuite/vme01/test_main.c
diff --git a/libbsd.py b/libbsd.py
index b05ea069..3fa2c8f3 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -5631,6 +5631,8 @@ class tests(builder.Module):
self.addTest(mm.generator['test']('openssl01', ['test_main']))
self.addTest(mm.generator['test']('openssl02', ['test_main']))
self.addTest(mm.generator['test']('tcpdump01', ['test_main']))
+self.addTest(mm.generator['test']('vme01', ['test_main'],
+ runTest = False))
def load(mm):
diff --git a/testsuite/vme01/test_main.c b/testsuite/vme01/test_main.c
new file mode 100644
index ..fe6c1072
--- /dev/null
+++ b/testsuite/vme01/test_main.c
@@ -0,0 +1,80 @@
+/**
+ * @file
+ *
+ * @brief A test for VME interrupts.
+ */
+
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 2023 embedded brains GmbH & Co. KG
+ *
+ * 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 COPYRIGHT HOLDERS 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 COPYRIGHT OWNER 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.
+ */
+
+#define TEST_NAME "LIBBSD VME 1"
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#if defined(RTEMS_BSD_MODULE_TSI148) && defined(LIBBSP_POWERPC_QORIQ_BSP_H)
+
+#include
+
+static void
+test_main(void)
+{
+ int error = 0;
+
+ for (int vec = 42; vec < 43; ++vec) {
+ for (int lvl = 7; lvl > 0; --lvl) {
+ int x = vmeTsi148IntLoopbackTst(lvl, vec);
+ printf("Tsi Interrupt test lvl %d, vec %d: %d\n",
+ lvl, vec, x);
+ if (x != 0) {
+ error = x;
+ }
+ }
+ }
+
+ exit(error);
+}
+
+#else /* RTEMS_BSD_MODULE_TSI148 */
+
+static void
+test_main(void)
+{
+ puts("VME not enabled in the current build set or not available on this
BSP.");
+ exit(0);
+}
+
+#endif /* RTEMS_BSD_MODULE_TSI148 */
+
+#define RTEMS_BSD_CONFIG_BSP_CONFIG
+
+#include
+
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 3/3] bsps/qoriq: Add VME support for MVME2500
This enables the VME support for the MVME2500. Note that the PCIe
support from libbsd is used. So you need the related libbsd patches for
this to work.
If the drivers in libbsd are not enabled, the linker should not pick up
anything from this patch.
---
bsps/powerpc/qoriq/include/bsp/VMEConfig.h | 50 ++
spec/build/bsps/powerpc/qoriq/grp.yml | 2 +
spec/build/bsps/powerpc/qoriq/obj.yml | 3 +-
3 files changed, 53 insertions(+), 2 deletions(-)
diff --git a/bsps/powerpc/qoriq/include/bsp/VMEConfig.h
b/bsps/powerpc/qoriq/include/bsp/VMEConfig.h
index 79c22d137a..4bb7c0d62f 100644
--- a/bsps/powerpc/qoriq/include/bsp/VMEConfig.h
+++ b/bsps/powerpc/qoriq/include/bsp/VMEConfig.h
@@ -7,6 +7,9 @@
*
* @brief This header file provides the interfaces used by VME bus device
* drivers.
+ *
+ * Note that for the MVME2500, you need the PCIe support from libbsd for this
to
+ * work.
*/
/*
@@ -43,6 +46,53 @@ extern "C" {
#define _VME_DRIVER_TSI148
+/*
+ * Base address of the PCI that is used for the VME bridge. Value is set in
+ * libbsd during device discovery.
+ */
+extern uintptr_t bsp_vme_pcie_base_address;
+
+#define PCI_MEM_BASE 0
+#define PCI_DRAM_OFFSET 0
+
+/*
+ * NOTE: shared vmeconfig.c uses hardcoded window lengths that match this
layout
+ *
+ * The memory length of the PCIe controllers on the P2020 processor is
+ * 0x2000. The Tsi148 registers are mapped at the bsp_vme_pcie_base_address
+ * with a size of 0x1000. Therefore the VME windows are arranged a bit
different
+ * then on other BSPs.
+ */
+#define _VME_A32_WIN0_ON_PCI (bsp_vme_pcie_base_address + 0x1000)
+#define _VME_A24_ON_PCI(bsp_vme_pcie_base_address + 0x0300)
+#define _VME_A16_ON_PCI(bsp_vme_pcie_base_address + 0x0200)
+#define _VME_CSR_ON_PCI(bsp_vme_pcie_base_address + 0x0100)
+
+/* FIXME: Make this a BSP config option */
+#define _VME_A32_WIN0_ON_VME 0x2000
+
+/*
+ * FIXME: The fixed QORIQ_IRQ_EXT_0 is valid for the MVME2500 board. In theory
+ * there should be some possibility to get that information from the device
tree
+ * or from PCI config space. But I didn't find it anywhere.
+ */
+#define BSP_VME_INSTALL_IRQ_MGR(err) \
+ do { \
+err = qoriq_pic_set_sense_and_polarity(\
+ QORIQ_IRQ_EXT_0, \
+ QORIQ_EIRQ_TRIGGER_LEVEL_LOW, \
+ NULL \
+); \
+if (err == 0) { \
+ err = vmeTsi148InstallIrqMgrAlt(0, 0, QORIQ_IRQ_EXT_0, -1); \
+} \
+ } while (0)
+
+/* Add prototypes that are in all VMEConfig.h files */
+extern int BSP_VMEInit(void);
+extern int BSP_VMEIrqMgrInstall(void);
+extern unsigned short (*_BSP_clear_vmebridge_errors)(int);
+
#ifdef __cplusplus
}
#endif /* __cplusplus */
diff --git a/spec/build/bsps/powerpc/qoriq/grp.yml
b/spec/build/bsps/powerpc/qoriq/grp.yml
index 2acb506c89..65e623fdbd 100644
--- a/spec/build/bsps/powerpc/qoriq/grp.yml
+++ b/spec/build/bsps/powerpc/qoriq/grp.yml
@@ -28,6 +28,8 @@ links:
uid: ../obj
- role: build-dependency
uid: ../objexc
+- role: build-dependency
+ uid: ../objvme
- role: build-dependency
uid: abi
- role: build-dependency
diff --git a/spec/build/bsps/powerpc/qoriq/obj.yml
b/spec/build/bsps/powerpc/qoriq/obj.yml
index 8926cc2135..b0ab1e6ca2 100644
--- a/spec/build/bsps/powerpc/qoriq/obj.yml
+++ b/spec/build/bsps/powerpc/qoriq/obj.yml
@@ -17,6 +17,7 @@ install:
- bsps/powerpc/qoriq/include/asm/fsl_hcalls.h
- destination: ${BSP_INCLUDEDIR}/bsp
source:
+ - bsps/powerpc/qoriq/include/bsp/VMEConfig.h
- bsps/powerpc/qoriq/include/bsp/intercom.h
- bsps/powerpc/qoriq/include/bsp/irq.h
- bsps/powerpc/qoriq/include/bsp/mmu.h
@@ -63,8 +64,6 @@ source:
- bsps/powerpc/shared/start/bsp-start-zero.S
- bsps/powerpc/shared/start/bspidle.c
- bsps/powerpc/shared/start/tictac.c
-- bsps/powerpc/shared/vme/bspVmeDmaList.c
-- bsps/powerpc/shared/vme/vmeTsi148.c
- bsps/shared/dev/getentropy/getentropy-cpucounter.c
- bsps/shared/dev/rtc/rtc-support.c
- bsps/shared/dev/serial/console-termios-init.c
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCHES rtems, libbsd] Add PCIe and VME support for qoriq
Hello, the attached patch set for RTEMS and libbsd adds initial support of the Tsi148 VME bridge on the MVME2500 board using the qoriq BSP. Basically it consists of the following parts: - Add PCIe ranges to the qoriq MMU configuration (based on FDT). - Add the existing VME support files to the qoriq BSP. - Allow to set up the necessary interrupt level and polarity in the BSP. - Add a matching VMEConfig.h to the BSP. - Add PCIe support for the qoriq to libbsd. - Add a glue layer to libbsd that allows the Tsi148 driver to use the BSP Tsi148 driver. The VME parts are only active, if `tsi148` is set to on in the buildset in libbsd. Otherwise, no VME parts will be linked into the application. Please note that the libbsd patches currently can only be applied to 6-freebsd-12. The master branch is a few months behind the 6-freebsd-12 in the FreeBSD development. Unluckily, the PCIe driver has been adapted to this controller in these months. Backporting the driver would pull in a other system changes which would make a later update of the master branch in libbsd harder. So I currently plan to only apply the patches to 6-freebsd-12 for now. With kind regards Christian Mauderer ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 01/14] sys/bus.h: Fix for small-data area targets
From: Sebastian Huber --- freebsd/sys/sys/buf.h | 4 1 file changed, 4 insertions(+) diff --git a/freebsd/sys/sys/buf.h b/freebsd/sys/sys/buf.h index 209174b4..dfe3eaa6 100644 --- a/freebsd/sys/sys/buf.h +++ b/freebsd/sys/sys/buf.h @@ -497,7 +497,11 @@ extern int cluster_pbuf_freecnt; /* Number of pbufs for clusters */ extern int vnode_pbuf_freecnt; /* Number of pbufs for vnode pager */ extern int vnode_async_pbuf_freecnt; /* Number of pbufs for vnode pager, asynchronous reads */ +#ifndef __rtems__ extern caddr_t unmapped_buf; /* Data address for unmapped buffers. */ +#else /* __rtems__ */ +extern caddr_t __read_mostly unmapped_buf; +#endif /* __rtems__ */ static inline int buf_mapped(struct buf *bp) -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/3] bsps/qoriq: Allow setting EIRQ polarity and sense
Add a function that allows to set the polarity (active-low / negative
edge triggered or active-high / positive edge triggered) and sense
(level or edge sensitive) of the external interrupts.
---
bsps/powerpc/qoriq/include/bsp/irq.h | 27 ++
bsps/powerpc/qoriq/irq/irq.c | 56
2 files changed, 83 insertions(+)
diff --git a/bsps/powerpc/qoriq/include/bsp/irq.h
b/bsps/powerpc/qoriq/include/bsp/irq.h
index 5719701d02..f197f7ab6e 100644
--- a/bsps/powerpc/qoriq/include/bsp/irq.h
+++ b/bsps/powerpc/qoriq/include/bsp/irq.h
@@ -279,6 +279,8 @@ extern "C" {
#define QORIQ_IRQ_EXT_10 (QORIQ_IRQ_EXT_BASE + 10)
#define QORIQ_IRQ_EXT_11 (QORIQ_IRQ_EXT_BASE + 11)
+#define QORIQ_IRQ_IS_EXT(vector) \
+ ((vector) >= QORIQ_IRQ_EXT_0 && (vector) <= QORIQ_IRQ_EXT_11)
/** @} */
/**
@@ -429,6 +431,31 @@ rtems_status_code qoriq_pic_msi_map(
uint32_t *data
);
+typedef enum {
+ QORIQ_EIRQ_TRIGGER_EDGE_FALLING,
+ QORIQ_EIRQ_TRIGGER_EDGE_RISING,
+ QORIQ_EIRQ_TRIGGER_LEVEL_LOW,
+ QORIQ_EIRQ_TRIGGER_LEVEL_HIGH,
+} qoriq_eirq_sense_and_polarity;
+
+/**
+ * @brief Change polarity and sense settings of external interrupts.
+ *
+ * NOTE: There are only very rare edge cases where you need this function.
+ *
+ * @a vector must be the vector number of an external interrupt.
+ *
+ * Use @a new_sense_and_polarity to select the new setting. If @a
+ * old_sense_and_polarity is not NULL, the old value is returned.
+ *
+ * @returns RTEMS_SUCCSSSFUL on sucess or other values for invalid settings.
+ */
+rtems_status_code qoriq_pic_set_sense_and_polarity(
+ rtems_vector_number vector,
+ qoriq_eirq_sense_and_polarity new_sense_and_polarity,
+ qoriq_eirq_sense_and_polarity *old_sense_and_polarity
+);
+
/** @} */
#ifdef __cplusplus
diff --git a/bsps/powerpc/qoriq/irq/irq.c b/bsps/powerpc/qoriq/irq/irq.c
index 1a650ddc83..8d6afa6c12 100644
--- a/bsps/powerpc/qoriq/irq/irq.c
+++ b/bsps/powerpc/qoriq/irq/irq.c
@@ -338,6 +338,62 @@ rtems_status_code qoriq_pic_set_priority(
return sc;
}
+rtems_status_code qoriq_pic_set_sense_and_polarity(
+ rtems_vector_number vector,
+ qoriq_eirq_sense_and_polarity new_sense_and_polarity,
+ qoriq_eirq_sense_and_polarity *old_sense_and_polarity
+)
+{
+ rtems_status_code sc = RTEMS_SUCCESSFUL;
+ uint32_t old_vpr = 0;
+ volatile qoriq_pic_src_cfg *src_cfg;
+ rtems_interrupt_lock_context lock_context;
+ uint32_t new_p_s = 0;
+
+ if (!QORIQ_IRQ_IS_EXT(vector)) {
+ return RTEMS_UNSATISFIED;
+ }
+
+ if (new_sense_and_polarity == QORIQ_EIRQ_TRIGGER_EDGE_RISING ||
+ new_sense_and_polarity == QORIQ_EIRQ_TRIGGER_LEVEL_HIGH) {
+ new_p_s |= VPR_P;
+ }
+
+ if (new_sense_and_polarity == QORIQ_EIRQ_TRIGGER_LEVEL_HIGH ||
+ new_sense_and_polarity == QORIQ_EIRQ_TRIGGER_LEVEL_LOW) {
+ new_p_s |= VPR_S;
+ }
+
+ src_cfg = get_src_cfg(vector);
+
+ rtems_interrupt_lock_acquire(, _context);
+ old_vpr = src_cfg->vpr;
+ src_cfg->vpr = (old_vpr & ~(VPR_P | VPR_S)) | new_p_s;
+ rtems_interrupt_lock_release(, _context);
+
+ if (old_sense_and_polarity != NULL) {
+ if ((old_vpr & VPR_P) == 0) {
+ if ((old_vpr & VPR_S) == 0) {
+ *old_sense_and_polarity =
+ QORIQ_EIRQ_TRIGGER_EDGE_FALLING;
+ } else {
+ *old_sense_and_polarity =
+ QORIQ_EIRQ_TRIGGER_LEVEL_LOW;
+ }
+ } else {
+ if ((old_vpr & VPR_S) == 0) {
+ *old_sense_and_polarity =
+ QORIQ_EIRQ_TRIGGER_EDGE_RISING;
+ } else {
+ *old_sense_and_polarity =
+ QORIQ_EIRQ_TRIGGER_LEVEL_HIGH;
+ }
+ }
+ }
+
+ return sc;
+}
+
rtems_status_code bsp_interrupt_set_affinity(
rtems_vector_number vector,
const Processor_mask *affinity
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/3] bsps/qoriq: Add MMU regions for PCIe based on fdt
Get the memory ranges for the PCIe from the FDT and add them to the MMU.
This is necessary so that the PCIe driver in libbsd can work.
---
bsps/powerpc/qoriq/start/mmu-config.c | 88 +++
1 file changed, 88 insertions(+)
diff --git a/bsps/powerpc/qoriq/start/mmu-config.c
b/bsps/powerpc/qoriq/start/mmu-config.c
index 58b08c8349..15e4a83fc4 100644
--- a/bsps/powerpc/qoriq/start/mmu-config.c
+++ b/bsps/powerpc/qoriq/start/mmu-config.c
@@ -305,6 +305,92 @@ static void TEXT config_fdt_adjust(const void *fdt)
}
}
+/*
+ * Each PCIe controller has a ranges attribute in the fdt like the following:
+ *
+ * ranges = <0x200 0x00 0xc000 0x00 0xc000 0x00 0x2000
+ * 0x100 0x00 0x 0x00 0xffc2 0x00 0x0001>;
+ * |--PCI address--| |-CPU address-| |-size|
+ *
+ * In theory, some fdt-attributes should be used to find out how long the PCI
+ * address (#address-cells of the PCIe node), the CPU address (#address-cells
of
+ * the parent node) and the size (#size-cells of the PCIe node) are. In our
case
+ * the structure is fixed because the pcie root controllers are a part of the
+ * chip. Therefore the sizes will never change and we can assume fixed lengths.
+ *
+ * The first cell of the PCI address holds a number of flags. A detailed
+ * explanation can be found for example here:
+ *
+ *
https://web.archive.org/web/20240109080338/https://michael2012z.medium.com/understanding-pci-node-in-fdt-769a894a13cc
+ *
+ * We are only interested in the entry with the flags 0x0200 which
basically
+ * means that it is a non-relocatable, non-prefetchable, not-aliased 32 bit
+ * memory space on the first bus.
+ *
+ * The other two cells of the PCI address are a 64 Bit address viewed from PCI
+ * address space. The two CPU address cells are the same 64 Bit address viewed
+ * from CPU address space. For our controller these two should always be the
+ * same (no address translation). The last two cells give a size of the memory
+ * region (in theory in PCI address space but it has to be the same for CPU and
+ * PCI).
+ */
+static void TEXT add_pcie_regions(qoriq_mmu_context *context, const void *fdt)
+{
+ int node;
+
+ node = -1;
+
+ while (true) {
+ static const size_t range_length = 7 * 4;
+ const void *val;
+ int len;
+
+ node = fdt_node_offset_by_compatible(
+ fdt,
+ node,
+ "fsl,mpc8548-pcie"
+ );
+ if (node < 0) {
+ break;
+ }
+
+ val = fdt_getprop(fdt, node, "ranges", );
+ if (len % range_length != 0) {
+ continue;
+ }
+
+ while (len >= range_length) {
+ uint32_t pci_addr_flags;
+ uintptr_t pci_addr;
+ uintptr_t cpu_addr;
+ uintptr_t size;
+ const uint32_t *cells;
+
+ cells = val;
+ pci_addr_flags = fdt32_to_cpu(cells[0]);
+ pci_addr = fdt64_to_cpu(*(fdt64_t *)([1]));
+ cpu_addr = fdt64_to_cpu(*(fdt64_t *)([3]));
+ size = fdt64_to_cpu(*(fdt64_t *)([5]));
+
+ if (pci_addr_flags == 0x0200 &&
+ pci_addr == cpu_addr) {
+ /* Add as I/O memory */
+ qoriq_mmu_add(
+ context,
+ cpu_addr,
+ cpu_addr + size - 1,
+ 0,
+ FSL_EIS_MAS2_I | FSL_EIS_MAS2_G,
+ FSL_EIS_MAS3_SR | FSL_EIS_MAS3_SW,
+ 0
+ );
+ }
+ len -= range_length;
+ val += range_length;
+ }
+ }
+}
+
void TEXT qoriq_mmu_config(bool boot_processor, int first_tlb, int scratch_tlb)
{
qoriq_mmu_context context;
@@ -349,6 +435,8 @@ void TEXT qoriq_mmu_config(bool boot_processor, int
first_tlb, int scratch_tlb)
}
}
+ add_pcie_regions(, fdt);
+
qoriq_mmu_partition(, max_count);
qoriq_mmu_write_to_tlb1(, first_tlb);
}
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 04/14] pci: Back port changes
From: Sebastian Huber
---
freebsd/sys/dev/pci/pci.c | 3 ++-
freebsd/sys/dev/pci/pci_pci.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/freebsd/sys/dev/pci/pci.c b/freebsd/sys/dev/pci/pci.c
index 0cc72dba..3789a73e 100644
--- a/freebsd/sys/dev/pci/pci.c
+++ b/freebsd/sys/dev/pci/pci.c
@@ -233,7 +233,8 @@ static device_method_t pci_methods[] = {
DEFINE_CLASS_0(pci, pci_driver, pci_methods, sizeof(struct pci_softc));
static devclass_t pci_devclass;
-DRIVER_MODULE(pci, pcib, pci_driver, pci_devclass, pci_modevent, NULL);
+EARLY_DRIVER_MODULE(pci, pcib, pci_driver, pci_devclass, pci_modevent, NULL,
+BUS_PASS_BUS);
MODULE_VERSION(pci, 1);
static char*pci_vendordata;
diff --git a/freebsd/sys/dev/pci/pci_pci.c b/freebsd/sys/dev/pci/pci_pci.c
index 5ba3e9a0..c1e73a3c 100644
--- a/freebsd/sys/dev/pci/pci_pci.c
+++ b/freebsd/sys/dev/pci/pci_pci.c
@@ -136,7 +136,8 @@ static device_method_t pcib_methods[] = {
static devclass_t pcib_devclass;
DEFINE_CLASS_0(pcib, pcib_driver, pcib_methods, sizeof(struct pcib_softc));
-DRIVER_MODULE(pcib, pci, pcib_driver, pcib_devclass, NULL, NULL);
+EARLY_DRIVER_MODULE(pcib, pci, pcib_driver, pcib_devclass, NULL, NULL,
+BUS_PASS_BUS);
#if defined(NEW_PCIB) || defined(PCI_HP)
SYSCTL_DECL(_hw_pci);
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems v2 2/3] bsp/imxrt1166: Support GPIO CS pins in LPSPI
With this, it is possible to use GPIOs as CS pins in the LPSPI. To avoid
additional complexity, the GPIOs will have the same limitations as the
native (hardware) CS pins.
The GPIO CS feature adds a number of extra code when starting SPI
transfers on this controller. Therefore it is possible to disable the
additional code by just setting the IMXRT_LPSPI_MAX_CS option to 0. In
that case only native CS pins are supported.
At the moment, this feature is only enabled on i.MXRT1166 by default
because it is not tested on i.MXRT1050. But it should work there too.
---
bsps/arm/imxrt/spi/imxrt-lpspi.c| 244 ++--
spec/build/bsps/arm/imxrt/grp.yml | 2 +
spec/build/bsps/arm/imxrt/optlpspimaxcs.yml | 21 ++
3 files changed, 248 insertions(+), 19 deletions(-)
create mode 100644 spec/build/bsps/arm/imxrt/optlpspimaxcs.yml
diff --git a/bsps/arm/imxrt/spi/imxrt-lpspi.c b/bsps/arm/imxrt/spi/imxrt-lpspi.c
index aed4f07f88..f23df73734 100644
--- a/bsps/arm/imxrt/spi/imxrt-lpspi.c
+++ b/bsps/arm/imxrt/spi/imxrt-lpspi.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
@@ -36,6 +37,10 @@
#include
#include
+#if IMXRT_LPSPI_MAX_CS != 0 && IMXRT_LPSPI_MAX_CS < 4
+#error IMXRT_LPSPI_MAX_CS hast to be either 0 or at least 4.
+#endif
+
struct imxrt_lpspi_bus {
spi_bus base;
volatile LPSPI_Type *regs;
@@ -57,6 +62,19 @@ struct imxrt_lpspi_bus {
const uint8_t *tx_buf;
uint32_t fifo_size;
+
+#if IMXRT_LPSPI_MAX_CS != 0
+ struct {
+bool is_gpio;
+struct imx_gpio_pin gpio;
+uint32_t active;
+ } cs[IMXRT_LPSPI_MAX_CS];
+ /*
+ * dummy_cs is either <0 if no dummy exists or the index of the cs that is
+ * used as dummy.
+ */
+ int dummy_cs;
+#endif
};
static const uint32_t word_size = 8;
@@ -148,7 +166,15 @@ static void imxrt_lpspi_config(
tcr |= LPSPI_TCR_LSBF_MASK;
}
+#if IMXRT_LPSPI_MAX_CS > 0
+ if (bus->cs[msg->cs].is_gpio || (msg->mode & SPI_NO_CS) != 0) {
+tcr |= LPSPI_TCR_PCS(bus->dummy_cs);
+ } else {
+tcr |= LPSPI_TCR_PCS(msg->cs);
+ }
+#else
tcr |= LPSPI_TCR_PCS(msg->cs);
+#endif
tcr |= LPSPI_TCR_CONT_MASK;
tcr |= LPSPI_TCR_FRAMESZ(word_size-1);
@@ -308,14 +334,33 @@ static inline int imxrt_lpspi_settings_ok(
)
{
/* most of this is currently just not implemented */
- if (msg->cs > 3 ||
- msg->speed_hz > bus->base.max_speed_hz ||
+ if (msg->speed_hz > bus->base.max_speed_hz ||
msg->delay_usecs != 0 ||
- (msg->mode & ~(SPI_CPHA | SPI_CPOL | SPI_LSB_FIRST)) != 0 ||
+ (msg->mode & ~(SPI_CPHA | SPI_CPOL | SPI_LSB_FIRST | SPI_NO_CS)) != 0 ||
msg->bits_per_word != word_size) {
return -EINVAL;
}
+#if IMXRT_LPSPI_MAX_CS == 0
+ if (msg->cs > 3 || (msg->mode & SPI_NO_CS) != 0) {
+return -EINVAL;
+ }
+#else /* IMXRT_LPSPI_MAX_CS != 0 */
+ /*
+ * Chip select is a bit tricky. This depends on whether it's a native or a
+ * GPIO chip select.
+ */
+ if (msg->cs > IMXRT_LPSPI_MAX_CS) {
+return -EINVAL;
+ }
+ if (!bus->cs[msg->cs].is_gpio && msg->cs > 3) {
+return -EINVAL;
+ }
+ if ((msg->mode & SPI_NO_CS) != 0 && bus->dummy_cs < 0) {
+return -EINVAL;
+ }
+#endif
+
if (prev_msg != NULL && !prev_msg->cs_change) {
/*
* A lot of settings have to be the same in this case because the upper 8
@@ -355,6 +400,10 @@ static int imxrt_lpspi_check_messages(
* Check whether cs_change is set on last message. Can't work without it
* because the last received data is only put into the FIFO if it is the end
* of a transfer or if another TX byte is put into the FIFO.
+ *
+ * In theory, a GPIO CS wouldn't need that limitation. But handling it
+ * different for the GPIO CS would add complexity. So keep it as a driver
+ * limitation for now.
*/
if (!prev_msg->cs_change) {
return -EINVAL;
@@ -363,6 +412,92 @@ static int imxrt_lpspi_check_messages(
return 0;
}
+#if IMXRT_LPSPI_MAX_CS > 0
+/*
+ * Check how many of the messages can be processed in one go. At the moment it
+ * is necessary to pause on CS changes when GPIO CS are used.
+ */
+static int imxrt_lpspi_check_howmany(
+ struct imxrt_lpspi_bus *bus,
+ const spi_ioc_transfer *msgs,
+ uint32_t max
+)
+{
+ int i;
+
+ if (max == 0) {
+return max;
+ }
+
+ for (i = 0; i < max - 1; ++i) {
+const spi_ioc_transfer *msg = [i];
+const spi_ioc_transfer *next_msg = [i+1];
+
+bool cs_is_gpio = bus->cs[msg->cs].is_gpio;
+bool no_cs = msg->mode & SPI_NO_CS;
+bool no_cs_next = next_msg->mode & SPI_NO_CS;
+
+if (cs_is_gpio && msg->cs_change) {
+ break;
+}
+
+if (no_cs != no_cs_next) {
+ break;
+}
+
+if (cs_is_gpio && (msg->cs != next_msg->cs)) {
+ break;
+}
+ }
+
+ return i+1;
+}
+#endif
+
+/*
+ * Transfer some messages. CS must not change between messages if GPIO CS are
+ * used.
+ */
+static void imxrt_lpspi_transfer_some(
+ struct imxrt_lpspi_bus *bus,
+ const
[PATCH rtems-docs v2] bsps/imxrt: Document GPIO CS pins for LPSPI
---
user/bsps/arm/imxrt.rst | 28
1 file changed, 28 insertions(+)
diff --git a/user/bsps/arm/imxrt.rst b/user/bsps/arm/imxrt.rst
index ad18766..30b1437 100644
--- a/user/bsps/arm/imxrt.rst
+++ b/user/bsps/arm/imxrt.rst
@@ -198,10 +198,38 @@ Note that the SPI-pins on the evaluation board are shared
with the SD card.
Populate R278, R279, R280, R281 on the IMXRT1050-EVKB (Rev A) to use the SPI
pins on the Arduino connector.
+By default, the native chip selects are used. If you want to use GPIOs as chip
+select instead, you can use the `cs-gpios` and `num-cs` attributes just like on
+a Linux SPI controller. A maximum of `IMXRT_LPSPI_MAX_CS` pins can be used.
+
+The hardware doesn't support selecting no native chip select during a transfer.
+Therefore one native chip select has to be reserved as a dummy if you want to
be
+able to use GPIOs. The pin function for this chip select must not be configured
+on any pin. Dummy will be the first of the first four chip selects that is not
a
+native one. Example configuration::
+
+ {
+status = "okay";
+pinctrl-0 = <_pinctrl_lpspi4>;
+cs-gpios = <0>, <0>, < 1 0>, <0>, < 5 1>;
+num-cs = <5>;
+ }
+
+In this case, CS2 will be the dummy chip select and no pin must be configured
+with that function. CS0, CS1 and CS3 are just native chip selects and should be
+used via pin functions. GPIO1.1 is used as a high active CS and GPIO11.5 a low
+active one.
+
Limitations:
* Only a basic SPI driver is implemented. This is mostly a driver limitation
and
not a hardware one.
+* GPIO CS pins on i.MXRT10xx are not tested. The chip has a lot of errate so
+ they might not work.
+* Switching from one mode (CPOL/CPHA) to another one can lead to single wrong
+ edges on the CLK line if GPIO CS pins are involved. Make sure to stuff a
dummy
+ transfer with `SPI_NO_CS` set if you use multiple modes together with a GPIO
+ CS.
Network Interface Driver
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems v2 3/3] bsps/imxrt1166: Disable video_mux
The pinctrl-0 of the video_mux might overwrite pin settings done by
other peripherals. Disabling it by default prevents unexpected pin
settings.
---
bsps/arm/imxrt/dts/imxrt1166-cm7-saltshaker.c | 10 ++
bsps/arm/imxrt/dts/imxrt1166-cm7-saltshaker.dts | 1 +
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/bsps/arm/imxrt/dts/imxrt1166-cm7-saltshaker.c
b/bsps/arm/imxrt/dts/imxrt1166-cm7-saltshaker.c
index 78e7feda09..e312902ff9 100644
--- a/bsps/arm/imxrt/dts/imxrt1166-cm7-saltshaker.c
+++ b/bsps/arm/imxrt/dts/imxrt1166-cm7-saltshaker.c
@@ -7,10 +7,10 @@
#include
const unsigned char imxrt_dtb[] __attribute__(( __aligned__(8) )) = {
- 0xd0, 0x0d, 0xfe, 0xed, 0x00, 0x00, 0x70, 0xf2, 0x00, 0x00, 0x00, 0x38,
- 0x00, 0x00, 0x6a, 0xa8, 0x00, 0x00, 0x00, 0x28, 0x00, 0x00, 0x00, 0x11,
+ 0xd0, 0x0d, 0xfe, 0xed, 0x00, 0x00, 0x71, 0x0a, 0x00, 0x00, 0x00, 0x38,
+ 0x00, 0x00, 0x6a, 0xc0, 0x00, 0x00, 0x00, 0x28, 0x00, 0x00, 0x00, 0x11,
0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x06, 0x0a,
- 0x00, 0x00, 0x6a, 0x70, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x6a, 0x88, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x04,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x03,
@@ -1836,7 +1836,9 @@ const unsigned char imxrt_dtb[] __attribute__((
__aligned__(8) )) = {
0x40, 0x81, 0x80, 0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x03,
0x00, 0x00, 0x00, 0x08, 0x00, 0x00, 0x04, 0xd2, 0x00, 0x00, 0x00, 0x5f,
0x00, 0x00, 0x00, 0x60, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x04,
- 0x00, 0x00, 0x05, 0x02, 0x00, 0x00, 0x00, 0x0f, 0x00, 0x00, 0x00, 0x02,
+ 0x00, 0x00, 0x05, 0x02, 0x00, 0x00, 0x00, 0x0f, 0x00, 0x00, 0x00, 0x03,
+ 0x00, 0x00, 0x00, 0x09, 0x00, 0x00, 0x04, 0xb3, 0x64, 0x69, 0x73, 0x61,
+ 0x62, 0x6c, 0x65, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02,
0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x01, 0x61, 0x69, 0x70, 0x73,
0x2d, 0x62, 0x75, 0x73, 0x40, 0x34, 0x30, 0x63, 0x30, 0x30, 0x30, 0x30,
0x30, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x18,
diff --git a/bsps/arm/imxrt/dts/imxrt1166-cm7-saltshaker.dts
b/bsps/arm/imxrt/dts/imxrt1166-cm7-saltshaker.dts
index c961abcd37..0cce861716 100644
--- a/bsps/arm/imxrt/dts/imxrt1166-cm7-saltshaker.dts
+++ b/bsps/arm/imxrt/dts/imxrt1166-cm7-saltshaker.dts
@@ -125,6 +125,7 @@
_mux {
pinctrl-0 = <_video_mux>;
+ status = "disabled";
};
{
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCHES v2] bsps/imxrt: Support GPIO CS for LPSPI; Minor fix for imxrt1166
Hello, I noted some minor bugs in the first version of the patches while using them. So here is a second version. That are BSP specific patches and I now used the driver in this configuration for some time and found no further problems. So if no one objects, I will push the patches in a few days. Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems v2 1/3] bsps/imx*: imx_gpio from pointer to fdt property
Device trees allow mixing different kinds of GPIOs in one property. For
that it is usefull to only provide a pointer to an arbitrary location in
the property and initialize a GPIO from that.
---
bsps/arm/include/bsp/imx-gpio.h | 26
bsps/arm/shared/pins/imx-gpio.c | 55 ++---
2 files changed, 69 insertions(+), 12 deletions(-)
diff --git a/bsps/arm/include/bsp/imx-gpio.h b/bsps/arm/include/bsp/imx-gpio.h
index 148f62a56e..5cda22972f 100644
--- a/bsps/arm/include/bsp/imx-gpio.h
+++ b/bsps/arm/include/bsp/imx-gpio.h
@@ -76,6 +76,32 @@ struct imx_gpio_pin {
*/
void imx_gpio_init (struct imx_gpio_pin *pin);
+/**
+ * Initialize a GPIO pin from the fields in an FDT property.
+ *
+ * If you have for example the following property in an FDT node:
+ *
+ * some-node {
+ * mixed-stuff = <0>, <_node 1>, < 22 GPIO_ACTIVE_LOW>,
<17>;
+ * };
+ *
+ * You can get the property using fdt_getprop(...) in your code, somehow find
+ * the right start position (the phandle ) and then pass it to this
+ * function.
+ *
+ * If you pass something != NULL to @a next_prop_pointer, you will get a
pointer
+ * to the next part in the attribute. In the example above, that will be a
+ * pointer to the <17>.
+ *
+ * NOTE: The information from the third parameter in the FDT (GPIO_ACTIVE_LOW
in
+ * the example) is currently ignored.
+ */
+rtems_status_code imx_gpio_init_from_fdt_property_pointer(
+ struct imx_gpio_pin *pin,
+ const uint32_t *prop_pointer,
+ enum imx_gpio_mode mode,
+ const uint32_t **next_prop_pointer);
+
/**
* Initialize a GPIO pin from a FDT property.
*
diff --git a/bsps/arm/shared/pins/imx-gpio.c b/bsps/arm/shared/pins/imx-gpio.c
index 8b7d09e864..1e39822b93 100644
--- a/bsps/arm/shared/pins/imx-gpio.c
+++ b/bsps/arm/shared/pins/imx-gpio.c
@@ -191,12 +191,11 @@ static void imx_gpio_set_interrupt_mode(struct
imx_gpio_pin *pin, uint32_t mode)
}
}
-rtems_status_code imx_gpio_init_from_fdt_property (
+rtems_status_code imx_gpio_init_from_fdt_property_pointer (
struct imx_gpio_pin *pin,
- int node_offset,
- const char *property,
+ const uint32_t *prop_pointer,
enum imx_gpio_mode mode,
- size_t index
+ const uint32_t **next_prop_pointer
)
{
int len;
@@ -205,7 +204,6 @@ rtems_status_code imx_gpio_init_from_fdt_property (
const void *fdt;
uint32_t gpio_regs;
const unsigned pin_length_dwords = 3;
- const unsigned pin_length_bytes = (pin_length_dwords * sizeof(uint32_t));
uint32_t gpio_phandle;
uint32_t pin_nr;
int cfgnode;
@@ -213,16 +211,12 @@ rtems_status_code imx_gpio_init_from_fdt_property (
memset(pin, 0, sizeof(*pin));
fdt = bsp_fdt_get();
- val = fdt_getprop(fdt, node_offset, property, );
- if (val == NULL || (len % pin_length_bytes != 0) ||
- (index >= len / pin_length_bytes)) {
-sc = RTEMS_UNSATISFIED;
- }
if (sc == RTEMS_SUCCESSFUL) {
-pin_nr = fdt32_to_cpu(val[1 + index * pin_length_dwords]);
-gpio_phandle = fdt32_to_cpu(val[0 + index * pin_length_dwords]);
+pin_nr = fdt32_to_cpu(prop_pointer[1]);
+gpio_phandle = fdt32_to_cpu(prop_pointer[0]);
cfgnode = fdt_node_offset_by_phandle(fdt, gpio_phandle);
+/* FIXME: Check compatible strings here. */
val = fdt_getprop(fdt, cfgnode, "reg", );
if (len > 0) {
gpio_regs = fdt32_to_cpu(val[0]);
@@ -239,6 +233,43 @@ rtems_status_code imx_gpio_init_from_fdt_property (
if (sc == RTEMS_SUCCESSFUL) {
imx_gpio_init(pin);
}
+ if (sc == RTEMS_SUCCESSFUL && next_prop_pointer != NULL) {
+*next_prop_pointer = prop_pointer + pin_length_dwords;
+ }
+
+ return sc;
+}
+
+rtems_status_code imx_gpio_init_from_fdt_property (
+ struct imx_gpio_pin *pin,
+ int node_offset,
+ const char *property,
+ enum imx_gpio_mode mode,
+ size_t index
+)
+{
+ int len;
+ const uint32_t *val;
+ rtems_status_code sc = RTEMS_SUCCESSFUL;
+ const void *fdt;
+ const unsigned pin_length_dwords = 3;
+ const unsigned pin_length_bytes = pin_length_dwords * 4;
+
+ memset(pin, 0, sizeof(*pin));
+
+ fdt = bsp_fdt_get();
+ val = fdt_getprop(fdt, node_offset, property, );
+ if (val == NULL || (len % pin_length_bytes != 0) ||
+ (index >= len / pin_length_bytes)) {
+sc = RTEMS_UNSATISFIED;
+ }
+ if (sc == RTEMS_SUCCESSFUL) {
+sc = imx_gpio_init_from_fdt_property_pointer(
+ pin,
+ val + index * pin_length_dwords,
+ mode,
+ NULL);
+ }
return sc;
}
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add RTEMS_QUALIFIED
for all possible profiles? Maybe I do not understand the problem but to me you either need to maintain a union of overlaying files for all profiles and what ever rules that brings or the profiles need to maintain their own set? I do not like the use of QUALIFIED as mentioned in my other post in this thread because it implies something the open project should not and that is the code is qualified. We will only provide pre-qualification data packs from the public repos unless that has changed? In the context of this patch set and the Software Requirements Engineering chapter of the RTEMS Software Engineering manual https://docs.rtems.org/branches/master/eng/req/index.html "qualified" means that: 1. An interface specification exists for each qualified API element. 2. Each qualified interface has a functional specification. 3. The function is validated by a test. 4. You get 100% branch and code coverage from the validation tests. For some justified exceptions you can use unit tests. Yes but there is no public proof so it is a promise until it is a fact and that is achieved at the end of the process. What is written is correct but a repo is in the present tense. I continuously work on integrating the work into the RTEMS Project. This patch set is a part of this work. It would reduce the maintenance cost on my side and so help to free time to work on other parts of the integration TODO list. I understand this and appreciate the work being done. My point is about the language and the word being used. If you know nothing about RTEMS or qualifying code can the use of RTEMS_QUALIFIED mislead someone into thinking that code is qualified for them when it is not? One thing this project has taught me over the last few decades is what I see and think is not what other users see and think. The accuracy of language is a factor. I suggested INDUSTRIAL and Amar suggested GENERAL. If we assume RTEMS_PROFILE_.* is about a qualifable (?) profile does that help? I've read through the discussion. It seems that one of the basic issues with the name that Sebastian suggested is that "qualified" suggests that qualification is already done. I think INDUSTRIAL would be a bit limiting to specific use cases. GENERAL doesn't tell a lot about the goal of the profile. Maybe some possible alternatives could be one of ..._QUALIFIABLE ..._PRE_QUALIFIED ..._QUALIFICATION_READY ..._QUALIFICATION_KIT ..._BASE_QUALIFICATION The first two would be the best in my opinion. They are short and tell you that there is no complete qualification done already. Beneath that they mostly fit to the wording that is already used in the RTEMS manual for example in https://docs.rtems.org/branches/master/eng/prequalification.html The later three suggestions are a bit long. Best regards Christian If someone has a better name than "qualified" for this, I am happy to use it. Good question. If RTEMS_PROFILE_SPACE is used can RTEMS_QUALIFIED be avoided? I think "space" is too specific. Yes it could be and GENERAL may not be specific enough? The objects which are pre-qualified or in the FACE profile would use this: enabled-by: - RTEMS_EVERYTHING - RTEMS_QUALIFIED - RTEMS_FACE_PROFILE The addition of these defines explodes the builds and testing we need to perform for each commit. We need to discuss this some more and look for boundaries that could help limit the builds and testing for each profile. Yes, all these options lead to a combinatorial explosion. We have to be pragmatic and focus on a useful subset for tests. I know for RTEMS_PROFILE_SPACE it will be a specific set of LEON archs? I see no point building that profile for anything else. The point is a profile should have a list of arches or BSPs associated to it as part of being accepted. This profile is not specific to a particular BSP. However, for each pre-qualified BSP there is some work to do. Firstly, it needs to be restructured to use only features of the pre-qualified feature set. Secondly, you may have to specify BSP-specific functions and validate them. Thirdly, you have to review all chip errata, implement workarounds, justify why erratas are not applicable to the BSP. Yes. Do you have a different list of BSPs in mind? Chris Of RTEMS_EVERYTHING, RTEMS_QUALIFIED, and RTEMS_FACE_PROFILE exactly one option shall be enabled. Yes this makes sense. Should a source file not in a profile be considered an error? Yes, this would be an error. Great. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- ---- embedded brains GmbH & Co. KG Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 mobile: +49-176-152 206 08 Registergericht: Amtsgericht München Registernummer: HRA 117265 Vertretungsberecht
[PATCHES] bsps/imxrt: Support GPIO CS for LPSPI; Minor fix for imxrt1166
Hello, with this patch set, the LPSPI of the imxrt BSPs now can use a GPIO as a chip select pin. The documentation is updated to show how it works. Additionally a minor fix for the iomux for the imxrt1166 is added. On that BSP some pins have been initialized that shouldn't be initialized unless someone explicitly uses the peripheral. Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 2/3] bsp/imxrt: Support GPIO CS pins in LPSPI
With this, it is possible to use GPIOs as CS pins in the LPSPI. To avoid
additional complexity, the GPIOs will have the same limitations as the
native (hardware) CS pins.
The GPIO CS feature adds a number of extra code when starting SPI
transfers on this controller. Therefore it is possible to disable the
additional code by just setting the IMXRT_LPSPI_MAX_CS option to 0. In
that case only native CS pins are supported.
---
bsps/arm/imxrt/spi/imxrt-lpspi.c| 146 +++-
spec/build/bsps/arm/imxrt/grp.yml | 2 +
spec/build/bsps/arm/imxrt/optlpspimaxcs.yml | 19 +++
3 files changed, 165 insertions(+), 2 deletions(-)
create mode 100644 spec/build/bsps/arm/imxrt/optlpspimaxcs.yml
diff --git a/bsps/arm/imxrt/spi/imxrt-lpspi.c b/bsps/arm/imxrt/spi/imxrt-lpspi.c
index aed4f07f88..9d1124e58f 100644
--- a/bsps/arm/imxrt/spi/imxrt-lpspi.c
+++ b/bsps/arm/imxrt/spi/imxrt-lpspi.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
@@ -36,6 +37,10 @@
#include
#include
+#if IMXRT_LPSPI_MAX_CS != 0 && IMXRT_LPSPI_MAX_CS < 4
+#error IMXRT_LPSPI_MAX_CS hast to be either 0 or at least 4.
+#endif
+
struct imxrt_lpspi_bus {
spi_bus base;
volatile LPSPI_Type *regs;
@@ -57,6 +62,19 @@ struct imxrt_lpspi_bus {
const uint8_t *tx_buf;
uint32_t fifo_size;
+
+#if IMXRT_LPSPI_MAX_CS != 0
+ struct {
+bool is_gpio;
+struct imx_gpio_pin gpio;
+uint32_t active;
+ } cs[IMXRT_LPSPI_MAX_CS];
+ /*
+ * dummy_cs is either <0 if no dummy exists or the index of the cs that is
+ * used as dummy.
+ */
+ int dummy_cs;
+#endif
};
static const uint32_t word_size = 8;
@@ -148,7 +166,15 @@ static void imxrt_lpspi_config(
tcr |= LPSPI_TCR_LSBF_MASK;
}
+#if IMXRT_LPSPI_MAX_CS > 0
+ if (bus->cs[msg->cs].is_gpio) {
+tcr |= LPSPI_TCR_PCS(bus->dummy_cs);
+ } else {
+tcr |= LPSPI_TCR_PCS(msg->cs);
+ }
+#else
tcr |= LPSPI_TCR_PCS(msg->cs);
+#endif
tcr |= LPSPI_TCR_CONT_MASK;
tcr |= LPSPI_TCR_FRAMESZ(word_size-1);
@@ -308,18 +334,40 @@ static inline int imxrt_lpspi_settings_ok(
)
{
/* most of this is currently just not implemented */
- if (msg->cs > 3 ||
- msg->speed_hz > bus->base.max_speed_hz ||
+ if (msg->speed_hz > bus->base.max_speed_hz ||
msg->delay_usecs != 0 ||
(msg->mode & ~(SPI_CPHA | SPI_CPOL | SPI_LSB_FIRST)) != 0 ||
msg->bits_per_word != word_size) {
return -EINVAL;
}
+#if IMXRT_LPSPI_MAX_CS == 0
+ if (msg->cs > 3) {
+return -EINVAL;
+ }
+#else /* IMXRT_LPSPI_MAX_CS != 0 */
+ /*
+ * Chip select is a bit tricky. This depends on whether it's a native or a
+ * GPIO chip select.
+ */
+ if (msg->cs > IMXRT_LPSPI_MAX_CS) {
+return -EINVAL;
+ }
+ if (!bus->cs[msg->cs].is_gpio && msg->cs > 3) {
+return -EINVAL;
+ }
+#endif
+
if (prev_msg != NULL && !prev_msg->cs_change) {
/*
* A lot of settings have to be the same in this case because the upper 8
* bit of TCR can't be changed if it is a continuous transfer.
+ *
+ * This also makes sure that there is only one GPIO CS used during the
whole
+ * message queue. Without that, we maybe would have to wait for the FIFOs
to
+ * be empty and then switch the CS. In theory that would be possible but it
+ * would add a lot of complexity. So stick with it as a driver limitation
+ * for now.
*/
if (prev_msg->cs != msg->cs ||
prev_msg->speed_hz != msg->speed_hz ||
@@ -355,6 +403,10 @@ static int imxrt_lpspi_check_messages(
* Check whether cs_change is set on last message. Can't work without it
* because the last received data is only put into the FIFO if it is the end
* of a transfer or if another TX byte is put into the FIFO.
+ *
+ * In theory, a GPIO CS wouldn't need that limitation. But handling it
+ * different for the GPIO CS would add complexity. So keep it as a driver
+ * limitation for now.
*/
if (!prev_msg->cs_change) {
return -EINVAL;
@@ -377,6 +429,18 @@ static int imxrt_lpspi_transfer(
rv = imxrt_lpspi_check_messages(bus, msgs, n);
if (rv == 0) {
+#if IMXRT_LPSPI_MAX_CS > 0
+/*
+ * Software chip select. Due to the checks in the
+ * imxrt_lpspi_check_messages, the CS can't change in the middle of a
+ * transfer. So we can just use the one from the first message.
+ */
+if (bus->cs[msgs[0].cs].is_gpio) {
+ imx_gpio_set_output(>cs[msgs[0].cs].gpio,
+ bus->cs[msgs[0].cs].active);
+}
+#endif
+
bus->tx_msg_todo = n;
bus->tx_msg = [0];
bus->rx_msg_todo = n;
@@ -392,6 +456,13 @@ static int imxrt_lpspi_transfer(
*/
bus->regs->IER = LPSPI_IER_TDIE_MASK;
rtems_binary_semaphore_wait(>sem);
+
+#if IMXRT_LPSPI_MAX_CS > 0
+if (bus->cs[msgs[0].cs].is_gpio) {
+ imx_gpio_set_output(>cs[msgs[0].cs].gpio,
+ ~bus->cs[msgs[0].cs].active);
+}
+#endif
}
return rv;
@@ -570,6 +641,9 @@ void imxrt_lpspi_init(void)
[PATCH rtems-docs] bsps/imxrt: Document GPIO CS pins for LPSPI
---
user/bsps/arm/imxrt.rst | 22 ++
1 file changed, 22 insertions(+)
diff --git a/user/bsps/arm/imxrt.rst b/user/bsps/arm/imxrt.rst
index ad18766..6554b3b 100644
--- a/user/bsps/arm/imxrt.rst
+++ b/user/bsps/arm/imxrt.rst
@@ -198,6 +198,28 @@ Note that the SPI-pins on the evaluation board are shared
with the SD card.
Populate R278, R279, R280, R281 on the IMXRT1050-EVKB (Rev A) to use the SPI
pins on the Arduino connector.
+By default, the native chip selects are used. If you want to use GPIOs as chip
+select instead, you can use the `cs-gpios` and `num-cs` attributes just like on
+a Linux SPI controller. A maximum of `IMXRT_LPSPI_MAX_CS` pins can be used.
+
+The hardware doesn't support selecting no native chip select during a transfer.
+Therefore one native chip select has to be reserved as a dummy if you want to
be
+able to use GPIOs. The pin function for this chip select must not be configured
+on any pin. Dummy will be the first of the first four chip selects that is not
a
+native one. Example configuration::
+
+ {
+status = "okay";
+pinctrl-0 = <_pinctrl_lpspi4>;
+cs-gpios = <0>, <0>, < 1 0>, <0>, < 5 1>;
+num-cs = <5>;
+ }
+
+In this case, CS2 will be the dummy chip select and no pin must be configured
+with that function. CS0, CS1 and CS3 are just native chip selects and should be
+used via pin functions. GPIO1.1 is used as a high active CS and GPIO11.5 a low
+active one.
+
Limitations:
* Only a basic SPI driver is implemented. This is mostly a driver limitation
and
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 1/3] bsps/imx*: imx_gpio from pointer to fdt property
Device trees allow mixing different kinds of GPIOs in one property. For
that it is usefull to only provide a pointer to an arbitrary location in
the property and initialize a GPIO from that.
---
bsps/arm/include/bsp/imx-gpio.h | 26
bsps/arm/shared/pins/imx-gpio.c | 55 ++---
2 files changed, 69 insertions(+), 12 deletions(-)
diff --git a/bsps/arm/include/bsp/imx-gpio.h b/bsps/arm/include/bsp/imx-gpio.h
index 148f62a56e..5cda22972f 100644
--- a/bsps/arm/include/bsp/imx-gpio.h
+++ b/bsps/arm/include/bsp/imx-gpio.h
@@ -76,6 +76,32 @@ struct imx_gpio_pin {
*/
void imx_gpio_init (struct imx_gpio_pin *pin);
+/**
+ * Initialize a GPIO pin from the fields in an FDT property.
+ *
+ * If you have for example the following property in an FDT node:
+ *
+ * some-node {
+ * mixed-stuff = <0>, <_node 1>, < 22 GPIO_ACTIVE_LOW>,
<17>;
+ * };
+ *
+ * You can get the property using fdt_getprop(...) in your code, somehow find
+ * the right start position (the phandle ) and then pass it to this
+ * function.
+ *
+ * If you pass something != NULL to @a next_prop_pointer, you will get a
pointer
+ * to the next part in the attribute. In the example above, that will be a
+ * pointer to the <17>.
+ *
+ * NOTE: The information from the third parameter in the FDT (GPIO_ACTIVE_LOW
in
+ * the example) is currently ignored.
+ */
+rtems_status_code imx_gpio_init_from_fdt_property_pointer(
+ struct imx_gpio_pin *pin,
+ const uint32_t *prop_pointer,
+ enum imx_gpio_mode mode,
+ const uint32_t **next_prop_pointer);
+
/**
* Initialize a GPIO pin from a FDT property.
*
diff --git a/bsps/arm/shared/pins/imx-gpio.c b/bsps/arm/shared/pins/imx-gpio.c
index 8b7d09e864..1e39822b93 100644
--- a/bsps/arm/shared/pins/imx-gpio.c
+++ b/bsps/arm/shared/pins/imx-gpio.c
@@ -191,12 +191,11 @@ static void imx_gpio_set_interrupt_mode(struct
imx_gpio_pin *pin, uint32_t mode)
}
}
-rtems_status_code imx_gpio_init_from_fdt_property (
+rtems_status_code imx_gpio_init_from_fdt_property_pointer (
struct imx_gpio_pin *pin,
- int node_offset,
- const char *property,
+ const uint32_t *prop_pointer,
enum imx_gpio_mode mode,
- size_t index
+ const uint32_t **next_prop_pointer
)
{
int len;
@@ -205,7 +204,6 @@ rtems_status_code imx_gpio_init_from_fdt_property (
const void *fdt;
uint32_t gpio_regs;
const unsigned pin_length_dwords = 3;
- const unsigned pin_length_bytes = (pin_length_dwords * sizeof(uint32_t));
uint32_t gpio_phandle;
uint32_t pin_nr;
int cfgnode;
@@ -213,16 +211,12 @@ rtems_status_code imx_gpio_init_from_fdt_property (
memset(pin, 0, sizeof(*pin));
fdt = bsp_fdt_get();
- val = fdt_getprop(fdt, node_offset, property, );
- if (val == NULL || (len % pin_length_bytes != 0) ||
- (index >= len / pin_length_bytes)) {
-sc = RTEMS_UNSATISFIED;
- }
if (sc == RTEMS_SUCCESSFUL) {
-pin_nr = fdt32_to_cpu(val[1 + index * pin_length_dwords]);
-gpio_phandle = fdt32_to_cpu(val[0 + index * pin_length_dwords]);
+pin_nr = fdt32_to_cpu(prop_pointer[1]);
+gpio_phandle = fdt32_to_cpu(prop_pointer[0]);
cfgnode = fdt_node_offset_by_phandle(fdt, gpio_phandle);
+/* FIXME: Check compatible strings here. */
val = fdt_getprop(fdt, cfgnode, "reg", );
if (len > 0) {
gpio_regs = fdt32_to_cpu(val[0]);
@@ -239,6 +233,43 @@ rtems_status_code imx_gpio_init_from_fdt_property (
if (sc == RTEMS_SUCCESSFUL) {
imx_gpio_init(pin);
}
+ if (sc == RTEMS_SUCCESSFUL && next_prop_pointer != NULL) {
+*next_prop_pointer = prop_pointer + pin_length_dwords;
+ }
+
+ return sc;
+}
+
+rtems_status_code imx_gpio_init_from_fdt_property (
+ struct imx_gpio_pin *pin,
+ int node_offset,
+ const char *property,
+ enum imx_gpio_mode mode,
+ size_t index
+)
+{
+ int len;
+ const uint32_t *val;
+ rtems_status_code sc = RTEMS_SUCCESSFUL;
+ const void *fdt;
+ const unsigned pin_length_dwords = 3;
+ const unsigned pin_length_bytes = pin_length_dwords * 4;
+
+ memset(pin, 0, sizeof(*pin));
+
+ fdt = bsp_fdt_get();
+ val = fdt_getprop(fdt, node_offset, property, );
+ if (val == NULL || (len % pin_length_bytes != 0) ||
+ (index >= len / pin_length_bytes)) {
+sc = RTEMS_UNSATISFIED;
+ }
+ if (sc == RTEMS_SUCCESSFUL) {
+sc = imx_gpio_init_from_fdt_property_pointer(
+ pin,
+ val + index * pin_length_dwords,
+ mode,
+ NULL);
+ }
return sc;
}
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 3/3] bsps/imxrt1166: Disable video_mux
The pinctrl-0 of the video_mux might overwrite pin settings done by
other peripherals. Disabling it by default prevents unexpected pin
settings.
---
bsps/arm/imxrt/dts/imxrt1166-cm7-saltshaker.c | 10 ++
bsps/arm/imxrt/dts/imxrt1166-cm7-saltshaker.dts | 1 +
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/bsps/arm/imxrt/dts/imxrt1166-cm7-saltshaker.c
b/bsps/arm/imxrt/dts/imxrt1166-cm7-saltshaker.c
index 78e7feda09..e312902ff9 100644
--- a/bsps/arm/imxrt/dts/imxrt1166-cm7-saltshaker.c
+++ b/bsps/arm/imxrt/dts/imxrt1166-cm7-saltshaker.c
@@ -7,10 +7,10 @@
#include
const unsigned char imxrt_dtb[] __attribute__(( __aligned__(8) )) = {
- 0xd0, 0x0d, 0xfe, 0xed, 0x00, 0x00, 0x70, 0xf2, 0x00, 0x00, 0x00, 0x38,
- 0x00, 0x00, 0x6a, 0xa8, 0x00, 0x00, 0x00, 0x28, 0x00, 0x00, 0x00, 0x11,
+ 0xd0, 0x0d, 0xfe, 0xed, 0x00, 0x00, 0x71, 0x0a, 0x00, 0x00, 0x00, 0x38,
+ 0x00, 0x00, 0x6a, 0xc0, 0x00, 0x00, 0x00, 0x28, 0x00, 0x00, 0x00, 0x11,
0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x06, 0x0a,
- 0x00, 0x00, 0x6a, 0x70, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x6a, 0x88, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x04,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x03,
@@ -1836,7 +1836,9 @@ const unsigned char imxrt_dtb[] __attribute__((
__aligned__(8) )) = {
0x40, 0x81, 0x80, 0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x03,
0x00, 0x00, 0x00, 0x08, 0x00, 0x00, 0x04, 0xd2, 0x00, 0x00, 0x00, 0x5f,
0x00, 0x00, 0x00, 0x60, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x04,
- 0x00, 0x00, 0x05, 0x02, 0x00, 0x00, 0x00, 0x0f, 0x00, 0x00, 0x00, 0x02,
+ 0x00, 0x00, 0x05, 0x02, 0x00, 0x00, 0x00, 0x0f, 0x00, 0x00, 0x00, 0x03,
+ 0x00, 0x00, 0x00, 0x09, 0x00, 0x00, 0x04, 0xb3, 0x64, 0x69, 0x73, 0x61,
+ 0x62, 0x6c, 0x65, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02,
0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x01, 0x61, 0x69, 0x70, 0x73,
0x2d, 0x62, 0x75, 0x73, 0x40, 0x34, 0x30, 0x63, 0x30, 0x30, 0x30, 0x30,
0x30, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x18,
diff --git a/bsps/arm/imxrt/dts/imxrt1166-cm7-saltshaker.dts
b/bsps/arm/imxrt/dts/imxrt1166-cm7-saltshaker.dts
index c961abcd37..0cce861716 100644
--- a/bsps/arm/imxrt/dts/imxrt1166-cm7-saltshaker.dts
+++ b/bsps/arm/imxrt/dts/imxrt1166-cm7-saltshaker.dts
@@ -125,6 +125,7 @@
_mux {
pinctrl-0 = <_video_mux>;
+ status = "disabled";
};
{
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 1/2] bsp/imxrt: Enable cache handling
The BSP needs the CPU_DATA_CACHE_ALIGNMENT set to enable correct cache handling in libbsd. Otherwise for example USB doesn't work reliable. --- rtemsbsd/include/machine/rtems-bsd-cache.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rtemsbsd/include/machine/rtems-bsd-cache.h b/rtemsbsd/include/machine/rtems-bsd-cache.h index 73b55e25..e292b216 100755 --- a/rtemsbsd/include/machine/rtems-bsd-cache.h +++ b/rtemsbsd/include/machine/rtems-bsd-cache.h @@ -45,7 +45,7 @@ #if defined(LIBBSP_ARM_LPC24XX_BSP_H) || (defined(LIBBSP_ARM_LPC32XX_BSP_H) && defined(LPC32XX_DISABLE_MMU)) /* No cache */ #elif defined(LIBBSP_ARM_ALTERA_CYCLONE_V_BSP_H) || \ - defined(LIBBSP_ARM_XILINX_ZYNQ_BSP_H) || (defined(LIBBSP_ARM_LPC32XX_BSP_H) && !defined(LPC32XX_DISABLE_MMU)) || defined(LIBBSP_ARM_IMX_BSP_H) + defined(LIBBSP_ARM_XILINX_ZYNQ_BSP_H) || (defined(LIBBSP_ARM_LPC32XX_BSP_H) && !defined(LPC32XX_DISABLE_MMU)) || defined(LIBBSP_ARM_IMX_BSP_H) || defined(LIBBSP_ARM_IMXRT_BSP_H) /* With cache, no coherency support in hardware */ #define CPU_DATA_CACHE_ALIGNMENT 32 #elif defined(__GEN83xx_BSP_h) -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 2/3] bsps/arm/imxrt1166: Enable USB
Enable the USB modules in the FDT.
---
bsps/arm/imxrt/dts/imxrt1166-cm7-saltshaker.c | 115 +++---
.../imxrt/dts/imxrt1166-cm7-saltshaker.dts| 8 ++
bsps/arm/imxrt/include/imxrt/imxrt1166.dtsi | 8 ++
3 files changed, 85 insertions(+), 46 deletions(-)
diff --git a/bsps/arm/imxrt/dts/imxrt1166-cm7-saltshaker.c
b/bsps/arm/imxrt/dts/imxrt1166-cm7-saltshaker.c
index f533172bbc..78e7feda09 100644
--- a/bsps/arm/imxrt/dts/imxrt1166-cm7-saltshaker.c
+++ b/bsps/arm/imxrt/dts/imxrt1166-cm7-saltshaker.c
@@ -7,10 +7,10 @@
#include
const unsigned char imxrt_dtb[] __attribute__(( __aligned__(8) )) = {
- 0xd0, 0x0d, 0xfe, 0xed, 0x00, 0x00, 0x6f, 0xdf, 0x00, 0x00, 0x00, 0x38,
- 0x00, 0x00, 0x69, 0xa0, 0x00, 0x00, 0x00, 0x28, 0x00, 0x00, 0x00, 0x11,
- 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x05, 0xff,
- 0x00, 0x00, 0x69, 0x68, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0xd0, 0x0d, 0xfe, 0xed, 0x00, 0x00, 0x70, 0xf2, 0x00, 0x00, 0x00, 0x38,
+ 0x00, 0x00, 0x6a, 0xa8, 0x00, 0x00, 0x00, 0x28, 0x00, 0x00, 0x00, 0x11,
+ 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x06, 0x0a,
+ 0x00, 0x00, 0x6a, 0x70, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x04,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x03,
@@ -1239,7 +1239,7 @@ const unsigned char imxrt_dtb[] __attribute__((
__aligned__(8) )) = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0a, 0x00, 0x00, 0x02, 0x50,
0x00, 0x00, 0x04, 0x94, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0a, 0x00, 0x00, 0x00, 0x03,
- 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x04, 0xab, 0x00, 0x00, 0x00, 0x0d,
+ 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x04, 0xab, 0x00, 0x00, 0x00, 0x0f,
0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x01, 0x6c, 0x65, 0x64, 0x67,
0x72, 0x70, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x48,
0x00, 0x00, 0x05, 0x0c, 0x00, 0x00, 0x01, 0x4c, 0x00, 0x00, 0x03, 0x90,
@@ -1249,7 +1249,7 @@ const unsigned char imxrt_dtb[] __attribute__((
__aligned__(8) )) = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x58, 0x00, 0x00, 0x03, 0x9c,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0a, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x04,
- 0x00, 0x00, 0x04, 0xab, 0x00, 0x00, 0x00, 0x11, 0x00, 0x00, 0x00, 0x02,
+ 0x00, 0x00, 0x04, 0xab, 0x00, 0x00, 0x00, 0x13, 0x00, 0x00, 0x00, 0x02,
0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x01, 0x74, 0x69, 0x6d, 0x65,
0x72, 0x40, 0x34, 0x30, 0x30, 0x65, 0x63, 0x30, 0x30, 0x30, 0x00, 0x00,
0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x08, 0x00, 0x00, 0x04, 0xa7,
@@ -1745,22 +1745,44 @@ const unsigned char imxrt_dtb[] __attribute__((
__aligned__(8) )) = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x08,
0x00, 0x00, 0x04, 0xa7, 0x40, 0x42, 0xc0, 0x00, 0x00, 0x00, 0x40, 0x00,
0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x04, 0xd2,
- 0x00, 0x00, 0x00, 0x87, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x01,
- 0x75, 0x73, 0x62, 0x40, 0x34, 0x30, 0x34, 0x33, 0x30, 0x30, 0x30, 0x30,
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x08,
- 0x00, 0x00, 0x04, 0xa7, 0x40, 0x43, 0x00, 0x00, 0x00, 0x00, 0x40, 0x00,
- 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x04, 0xd2,
- 0x00, 0x00, 0x00, 0x88, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x01,
- 0x75, 0x73, 0x62, 0x70, 0x68, 0x79, 0x40, 0x34, 0x30, 0x34, 0x33, 0x34,
- 0x30, 0x30, 0x30, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x08,
- 0x00, 0x00, 0x04, 0xa7, 0x40, 0x43, 0x40, 0x00, 0x00, 0x00, 0x40, 0x00,
- 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x04, 0xd2,
- 0x00, 0x00, 0x00, 0x5a, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x01,
- 0x75, 0x73, 0x62, 0x70, 0x68, 0x79, 0x40, 0x34, 0x30, 0x34, 0x33, 0x38,
- 0x30, 0x30, 0x30, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x08,
- 0x00, 0x00, 0x04, 0xa7, 0x40, 0x43, 0x80, 0x00, 0x00, 0x00, 0x40, 0x00,
- 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x04, 0xd2,
- 0x00, 0x00, 0x00, 0x5b, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x01,
+ 0x00, 0x00, 0x00, 0x87, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x20,
+ 0x00, 0x00, 0x04, 0x76, 0x66, 0x73, 0x6c, 0x2c, 0x69, 0x6d, 0x78, 0x72,
+ 0x74, 0x31, 0x31, 0x36, 0x36, 0x2d, 0x75, 0x73, 0x62, 0x00, 0x66, 0x73,
+ 0x6c, 0x2c, 0x69, 0x6d, 0x78, 0x32, 0x37, 0x2d, 0x75, 0x73, 0x62, 0x00,
+ 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x05, 0xa9,
+ 0x00, 0x00, 0x00, 0x0d, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x05,
+ 0x00, 0x00, 0x04, 0xb3, 0x6f, 0x6b, 0x61, 0x79, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x01, 0x75, 0x73,
[PATCH rtems-libbsd 2/2] rtemsbsd/sys/arm: Add imxrt1166 USBPHY driver
Adds a driver for the i.MXRT1166 USB PHY and enable USB for the
imxrt11xx BSPs.
---
libbsd.py | 6 +
rtemsbsd/include/bsp/nexus-devices.h | 8 +
.../sys/arm/freescale/imx/imxrt1166_usbphy.c | 227 ++
3 files changed, 241 insertions(+)
create mode 100644 rtemsbsd/sys/arm/freescale/imx/imxrt1166_usbphy.c
diff --git a/libbsd.py b/libbsd.py
index e3840f37..db390df0 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -5334,6 +5334,12 @@ class imx(builder.Module):
],
mm.generator['source']()
)
+self.addRTEMSKernelSourceFiles(
+[
+'sys/arm/freescale/imx/imxrt1166_usbphy.c',
+],
+mm.generator['source']()
+)
class regulator(builder.Module):
def __init__(self, manager):
diff --git a/rtemsbsd/include/bsp/nexus-devices.h
b/rtemsbsd/include/bsp/nexus-devices.h
index d98e6f76..37008cc6 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -173,6 +173,14 @@ SYSINIT_DRIVER_REFERENCE(simplebus, ofwbus);
SYSINIT_DRIVER_REFERENCE(ffec, simplebus);
SYSINIT_DRIVER_REFERENCE(ksz8091rnb, miibus);
+#if IMXRT_IS_MIMXRT11xx
+SYSINIT_DRIVER_REFERENCE(ehci, simplebus);
+SYSINIT_DRIVER_REFERENCE(imxrt1166_usbphy, simplebus);
+SYSINIT_DRIVER_REFERENCE(usbus, ehci);
+RTEMS_BSD_DRIVER_USB;
+RTEMS_BSD_DRIVER_USB_MASS;
+#endif /* IMXRT_IS_IMXRT11xx */
+
#elif defined(LIBBSP_ARM_LPC24XX_BSP_H)
RTEMS_BSD_DEFINE_NEXUS_DEVICE(ohci, 0, 0, NULL);
diff --git a/rtemsbsd/sys/arm/freescale/imx/imxrt1166_usbphy.c
b/rtemsbsd/sys/arm/freescale/imx/imxrt1166_usbphy.c
new file mode 100644
index ..b8e3a188
--- /dev/null
+++ b/rtemsbsd/sys/arm/freescale/imx/imxrt1166_usbphy.c
@@ -0,0 +1,227 @@
+#include
+
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (c) 2013 Ian Lepore
+ * Copyright (C) 2023 embedded brains GmbH & Co. KG
+ * All rights reserved.
+ *
+ * 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
+#if defined(LIBBSP_ARM_IMXRT_BSP_H)
+
+#include
+__FBSDID("$FreeBSD$");
+
+/*
+ * USBPHY driver for Freescale i.MXRT1166. Most likely works with the whole
+ * i.MXRT11xx family.
+ *
+ * Based on USBPHY driver for i.MX6.
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+#include
+
+#include
+#include
+
+struct imxrt1166_usbphy_softc {
+ device_tdev;
+ struct resource *mem_res;
+ regulator_t supply_vbus;
+ USBPHY_Type *regs;
+};
+
+static struct ofw_compat_data compat_data[] = {
+ {"fsl,imxrt1166-usbphy",true},
+ {NULL, false}
+};
+
+static int
+imxrt1166_usbphy_detach(device_t dev)
+{
+ struct imxrt1166_usbphy_softc *sc;
+
+ sc = device_get_softc(dev);
+
+ if (sc->mem_res != NULL)
+ bus_release_resource(dev, SYS_RES_MEMORY, 0, sc->mem_res);
+
+ return (0);
+}
+
+#define BUS_SPACE_PHYSADDR(res, offs) \
+ ((u_int)(rman_get_start(res)+(offs)))
+
+static int
+enable_vbus_supply(device_t dev, struct imxrt1166_usbphy_softc *sc)
+{
+ int rv;
+ phandle_t node;
+
+ node = ofw_bus_get_node(dev);
+ if (OF_hasprop(node, "vbus-supply")) {
+ rv = regulator_get_by_ofw_property(sc->dev, node, "vbus-supply",
+ >supply_vbus);
+ if (rv != 0) {
+ device_printf(sc->dev,
+ "Cannot get \"vbus\" regulator\n");
+ return ENXIO;
+ }
+ rv = regulator_enable(sc->supply_vbus);
+ if (rv != 0) {
+
[PATCH rtems 3/3] bsps/arm/imxrt: Optimize nocache memory settings
The nocache-memory was set as device memory. It's not necessary to be
that strict. Set it to normal non-cacheable non-shareable memory
instead.
---
bsps/arm/imxrt/start/mpu-config.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/bsps/arm/imxrt/start/mpu-config.c
b/bsps/arm/imxrt/start/mpu-config.c
index a8f98f1c81..93a4cb08e4 100644
--- a/bsps/arm/imxrt/start/mpu-config.c
+++ b/bsps/arm/imxrt/start/mpu-config.c
@@ -53,13 +53,13 @@ BSP_START_DATA_SECTION const ARMV7M_MPU_Region_config
.begin = imxrt_memory_extram_nocache_begin,
.end = imxrt_memory_extram_nocache_end,
.rasr = ARMV7M_MPU_RASR_AP(0x3)
-| ARMV7M_MPU_RASR_TEX(0x2)
+| ARMV7M_MPU_RASR_TEX(0x1)
| ARMV7M_MPU_RASR_ENABLE,
}, {
.begin = imxrt_memory_ocram_nocache_begin,
.end = imxrt_memory_ocram_nocache_end,
.rasr = ARMV7M_MPU_RASR_AP(0x3)
-| ARMV7M_MPU_RASR_TEX(0x2)
+| ARMV7M_MPU_RASR_TEX(0x1)
| ARMV7M_MPU_RASR_ENABLE,
}, {
.begin = imxrt_memory_peripheral_begin,
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 1/3] bsps/imxrt: Fix enabling USBPHY in fsl_clock
The mcux-sdk tries to enable the USBPHY. But it uses the wrong register
for that. This patch fixes the bug.
---
.../imxrt/mcux-sdk/devices/MIMXRT1166/drivers/fsl_clock.c | 8
1 file changed, 8 insertions(+)
diff --git a/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1166/drivers/fsl_clock.c
b/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1166/drivers/fsl_clock.c
index 1e40dc4038..4928b1aad7 100644
--- a/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1166/drivers/fsl_clock.c
+++ b/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1166/drivers/fsl_clock.c
@@ -1735,7 +1735,11 @@ bool CLOCK_EnableUsbhs0PhyPllClock(clock_usb_phy_src_t
src, uint32_t freq)
USBPHY1->PLL_SIC_SET = (USBPHY_PLL_SIC_PLL_EN_USB_CLKS_MASK);
USBPHY1->CTRL_CLR = USBPHY_CTRL_CLR_CLKGATE_MASK;
+#ifndef __rtems__
USBPHY1->PWD_SET = 0x0;
+#else /* __rtems__ */
+USBPHY1->PWD = 0x0;
+#endif /* __rtems__ */
while (0UL == (USBPHY1->PLL_SIC & USBPHY_PLL_SIC_PLL_LOCK_MASK))
{
@@ -1841,7 +1845,11 @@ bool CLOCK_EnableUsbhs1PhyPllClock(clock_usb_phy_src_t
src, uint32_t freq)
USBPHY2->PLL_SIC_SET = (USBPHY_PLL_SIC_PLL_EN_USB_CLKS_MASK);
USBPHY2->CTRL_CLR = USBPHY_CTRL_CLR_CLKGATE_MASK;
+#ifndef __rtems__
USBPHY2->PWD_SET = 0x0;
+#else /* __rtems__ */
+USBPHY2->PWD = 0x0;
+#endif /* __rtems__ */
while (0UL == (USBPHY2->PLL_SIC & USBPHY_PLL_SIC_PLL_LOCK_MASK))
{
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 0/3, libbsd 0/2] Enable USB for i.MXRT11xx
Hello, this patch set adds a USB PHY driver for the i.MXRT11xx family and enables USB on that device family. Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsps/shared: Fix Coverity warning in MCP7940M
On 2023-08-02 15:31, Joel Sherrill wrote:
On Wed, Aug 2, 2023 at 6:45 AM Christian MAUDERER
<mailto:christian.maude...@embedded-brains.de>> wrote:
Hello Joel,
thanks. Is the ID processed somewhere automatically so that I should
use
a special format? Otherwise I can just just add the error message from
covertity:
** CID 1539495: Integer handling issues (CONSTANT_EXPRESSION_RESULT)
/bsps/shared/dev/rtc/mcp7940m.c: 317 in mcp7940m_set_time()
It is not processed special. The CID is just nice to have in the future
and, if needed,
track back to what Coverity saw.
Especially given the history with some of these static analysis
triggered fixes where
they are hard to get right.
Thanks. I'll add the message and push the patch tomorrow.
--joel
Best regards
Christian
On 2023-08-02 13:43, Joel Sherrill wrote:
> Ok but out the Coverity Id number in the commit long message
>
> On Wed, Aug 2, 2023, 1:17 AM Christian Mauderer
> mailto:christian.maude...@embedded-brains.de>
> <mailto:christian.maude...@embedded-brains.de
<mailto:christian.maude...@embedded-brains.de>>> wrote:
>
> Coverity warns that (buf[...] & 0x7) can't be bigger than 7.
This patch
> removes the unnecessary comparison.
> ---
> bsps/shared/dev/rtc/mcp7940m.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/bsps/shared/dev/rtc/mcp7940m.c
> b/bsps/shared/dev/rtc/mcp7940m.c
> index 78a4f21b58..1abc5faaad 100644
> --- a/bsps/shared/dev/rtc/mcp7940m.c
> +++ b/bsps/shared/dev/rtc/mcp7940m.c
> @@ -312,9 +312,8 @@ static int mcp7940m_set_time(int minor, const
> rtems_time_of_day *time)
> }
>
> if (rv == 0) {
> - /* Make sure weekday is in range. Otherwise it's not
relevant. */
> - if (RTCWKDAY_WKDAY_GET(buf[REG_RTCWKDAY]) < 1 ||
> - RTCWKDAY_WKDAY_GET(buf[REG_RTCWKDAY]) > 7) {
> + /* Make sure weekday is not 0 (out of range). Otherwise it's
> not used. */
> + if (RTCWKDAY_WKDAY_GET(buf[REG_RTCWKDAY]) < 1) {
> buf[REG_RTCWKDAY] &= ~RTCWKDAY_WKDAY_MASK;
> buf[REG_RTCWKDAY] |= RTCWKDAY_WKDAY(1);
> }
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org <mailto:devel@rtems.org> <mailto:devel@rtems.org
<mailto:devel@rtems.org>>
> http://lists.rtems.org/mailman/listinfo/devel
<http://lists.rtems.org/mailman/listinfo/devel>
> <http://lists.rtems.org/mailman/listinfo/devel
<http://lists.rtems.org/mailman/listinfo/devel>>
>
--
embedded brains GmbH & Co. KG
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
<mailto:christian.maude...@embedded-brains.de>
phone: +49-89-18 94 741 - 18
mobile: +49-176-152 206 08
Registergericht: Amtsgericht München
Registernummer: HRA 117265
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
<https://embedded-brains.de/datenschutzerklaerung/>
--
embedded brains GmbH & Co. KG
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
mobile: +49-176-152 206 08
Registergericht: Amtsgericht München
Registernummer: HRA 117265
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] bsps/shared: Fix Coverity warning in MCP7940M
Hello Joel,
thanks. Is the ID processed somewhere automatically so that I should use
a special format? Otherwise I can just just add the error message from
covertity:
** CID 1539495: Integer handling issues (CONSTANT_EXPRESSION_RESULT)
/bsps/shared/dev/rtc/mcp7940m.c: 317 in mcp7940m_set_time()
Best regards
Christian
On 2023-08-02 13:43, Joel Sherrill wrote:
Ok but out the Coverity Id number in the commit long message
On Wed, Aug 2, 2023, 1:17 AM Christian Mauderer
<mailto:christian.maude...@embedded-brains.de>> wrote:
Coverity warns that (buf[...] & 0x7) can't be bigger than 7. This patch
removes the unnecessary comparison.
---
bsps/shared/dev/rtc/mcp7940m.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/bsps/shared/dev/rtc/mcp7940m.c
b/bsps/shared/dev/rtc/mcp7940m.c
index 78a4f21b58..1abc5faaad 100644
--- a/bsps/shared/dev/rtc/mcp7940m.c
+++ b/bsps/shared/dev/rtc/mcp7940m.c
@@ -312,9 +312,8 @@ static int mcp7940m_set_time(int minor, const
rtems_time_of_day *time)
}
if (rv == 0) {
- /* Make sure weekday is in range. Otherwise it's not relevant. */
- if (RTCWKDAY_WKDAY_GET(buf[REG_RTCWKDAY]) < 1 ||
- RTCWKDAY_WKDAY_GET(buf[REG_RTCWKDAY]) > 7) {
+ /* Make sure weekday is not 0 (out of range). Otherwise it's
not used. */
+ if (RTCWKDAY_WKDAY_GET(buf[REG_RTCWKDAY]) < 1) {
buf[REG_RTCWKDAY] &= ~RTCWKDAY_WKDAY_MASK;
buf[REG_RTCWKDAY] |= RTCWKDAY_WKDAY(1);
}
--
2.35.3
___
devel mailing list
devel@rtems.org <mailto:devel@rtems.org>
http://lists.rtems.org/mailman/listinfo/devel
<http://lists.rtems.org/mailman/listinfo/devel>
--
----
embedded brains GmbH & Co. KG
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
mobile: +49-176-152 206 08
Registergericht: Amtsgericht München
Registernummer: HRA 117265
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
[PATCH] bsps/shared: Fix Coverity warning in MCP7940M
Coverity warns that (buf[...] & 0x7) can't be bigger than 7. This patch
removes the unnecessary comparison.
---
bsps/shared/dev/rtc/mcp7940m.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/bsps/shared/dev/rtc/mcp7940m.c b/bsps/shared/dev/rtc/mcp7940m.c
index 78a4f21b58..1abc5faaad 100644
--- a/bsps/shared/dev/rtc/mcp7940m.c
+++ b/bsps/shared/dev/rtc/mcp7940m.c
@@ -312,9 +312,8 @@ static int mcp7940m_set_time(int minor, const
rtems_time_of_day *time)
}
if (rv == 0) {
-/* Make sure weekday is in range. Otherwise it's not relevant. */
-if (RTCWKDAY_WKDAY_GET(buf[REG_RTCWKDAY]) < 1 ||
-RTCWKDAY_WKDAY_GET(buf[REG_RTCWKDAY]) > 7) {
+/* Make sure weekday is not 0 (out of range). Otherwise it's not used. */
+if (RTCWKDAY_WKDAY_GET(buf[REG_RTCWKDAY]) < 1) {
buf[REG_RTCWKDAY] &= ~RTCWKDAY_WKDAY_MASK;
buf[REG_RTCWKDAY] |= RTCWKDAY_WKDAY(1);
}
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsps/arm: fix nested extern decl. warnings brought by CMSIS files update
On 2023-07-25 16:20, Karel Gardas wrote: On 7/25/23 15:32, Sebastian Huber wrote: On 21.07.23 17:37, Karel Gardas wrote: --- bsps/arm/include/cmsis_gcc.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/bsps/arm/include/cmsis_gcc.h b/bsps/arm/include/cmsis_gcc.h index 4f0762d6dc..9e867348d2 100644 --- a/bsps/arm/include/cmsis_gcc.h +++ b/bsps/arm/include/cmsis_gcc.h @@ -30,7 +30,9 @@ #pragma GCC diagnostic ignored "-Wsign-conversion" #pragma GCC diagnostic ignored "-Wconversion" #pragma GCC diagnostic ignored "-Wunused-parameter" - +#ifdef __rtems__ +#pragma GCC diagnostic ignored "-Wnested-externs" +#endif /* __rtems__ */ /* Fallback for __has_builtin */ #ifndef __has_builtin #define __has_builtin(x) (0) I would disable this warning only in __cmsis_start() with a push/pop pragma. Will look into it. The way it was done was to reuse as much as possible of the current file infrastructure. I think you have to add also a * Modifications Copyright (C) Karel Gardas if you change the file, see also: It's a shame to need to copyright single liners. IMHO license does not require that precisely. What about to just add: /* The file was modified for the purposes of RTEMS project */ right at the beginning (1st line) of file? Apache clearly states that modified files have to be marked: 4.b.: You must cause any modified files to carry prominent notices stating that You changed the files Not sure whether the big 'You' means that it is a person or a project. RTEMS project distributes the files so "adapted by RTEMS contributors" might work? By the way: I just noted that we now most likely also need a LICENSE.Apache-2.0 file in the root directory of RTEMS. https://softwareengineering.stackexchange.com/questions/220068/file-with-apache-2-0-and-my-modifications In general, some advice for dealing with Apache 2.0 files in the RTEMS Software Engineering manual would be nice. That would be great to have, but who would do that? > Or perhaps we may distill right behavioral patterns from our competitors: Zephyr/NuttX? E.g. https://github.com/apache/nuttx/commits/master/net/tcp/tcp_getsockopt.c -- file modified by several persons and none is mentioned (do all of them have signed contributor agreement with ASF?) and https://github.com/zephyrproject-rtos/zephyr/commits/main/kernel/paging/statistics.c -- file modified by jfisher-no (from Nordic Semiconductor) and yet, file clearly copyrighted by Intel and no message about modification by anyone else. Nuttx and Zephyr are both Apache-Licensed. Both files that you have linked seem to be developed for the systems. At least I didn't find an "import from xyz" commit or similar hint. I think that makes the situation different compared to our import of Apache licensed third party code into a non-Apache licensed project. Another idea my be to go with what Joel suggested in the original CMSISv5 inclusion thread: put any modification into #ifdef __rtems__ / #endif and make that clearly visible that file was changed this way. Nothing more needed... Marking changes with #ifdef __rtems__ is always a good idea because it makes porting the changes during the next update simpler. I would expect that at least a general "modified for RTEMS" or "modified by RTEMS contributors" statement is still necessary. If you want to get a definitive answer what is the right solution and end all the discussions, you might consider asking that question on the FSFE License Question list and post the result here and / or add it to the manual (assuming that they agree that the answer is published): https://fsfe.org/activities/legal.en.html Best regards Christian Thanks! Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- ---- embedded brains GmbH & Co. KG Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 mobile: +49-176-152 206 08 Registergericht: Amtsgericht München Registernummer: HRA 117265 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: Outdated list of BSPs in rtems-tools/config
Hello Joel, On 2023-07-25 16:14, Joel Sherrill wrote: On Tue, Jul 25, 2023 at 9:08 AM Christian MAUDERER <mailto:christian.maude...@embedded-brains.de>> wrote: Hello Joel, On 2023-07-25 15:46, Joel Sherrill wrote: > > > On Tue, Jul 25, 2023 at 5:02 AM Christian MAUDERER > mailto:christian.maude...@embedded-brains.de> > <mailto:christian.maude...@embedded-brains.de <mailto:christian.maude...@embedded-brains.de>>> wrote: > > Hello, > > I noted that some BSPs are missing in the config files in the > rtems-tools repo. If I didn't miss one it's: > > - aarch64, raspberrypi4b > - aarch64, xilinx_zynqmp_lp64_cfc400x > - arm, imxrt1166-cm7-saltshaker > - arm, stm32h750b-dk > - powerpc, mvme2700 > - powerpc, phycore_mpc5554 > - riscv, kendrytek210 > - x86_64, amd64efi > > One of the BSPs is from me. I don't know of the other ones. Most of those are recent and from a lot of different people. GSoC, Kinsey, you, Vijay or Chris, Karel, etc. But I wonder about that phycore_mpc5554. I think it has been around a LONG time. > > I noted the configuration files in that repo just now more or less by > chance when playing around with rtems-bsp-builder. I wasn't aware that > we have a second list beneath the one printed by the `rtems-bsps` > script > or `waf bsp-list` in the RTEMS repo. I would hope they are related under the hood. But rtems-bsps already can produce the bsp list in a lot of formats. Perhaps just having it product the ini file would help. Could be useful as a first step, yes. If I find some time, I'll take a look at that. > > > Yep. The list of bsps in the ini files for rtems-bsp-builder get out of > date. > I was probably the last one to try to sync them back in March. > > We need some scripting to check them both ways -- additions from rtems > and deletions from RTEMS need to be reflected. > > If we had some tool which checked this, I'd be happy to run it to the > cron jobs that do build sweeps and Coverity runs. > Wouldn't it be better to try to integrate the information from the ini files into the yml files of the new build system? That way they can't go out of sync. Or is there a special reason that they have to be separate? Chris would have to answer this. At this point, I don't think the tools know about the RTEMS repo. But rtems-bsp-builder is special so it could ask rtems to generate that ini file. That might be easy. I tried it with rtems-bsp-builder and that one should know the sources. Otherwise, it can't build the BSPs. But it's possible that the ini files are used in other tools too. I'll wait for a day or two whether Chris has an answer. From a quick glance, every BSP would need an additional "exclude-smp" and "tier" parameter for that. Long term, that would be good information to have anyway. > > Did I miss that I should have updated rtems-tools (and with that the > rtems-source-builder) every time I have added a BSP in the past? Or > would it only make problems if I would update these files manually > because they are usually created by some script during the release > process? > > > Yes. And we all forget to do it. To be honest: I haven't known these files or completely erased that I ever knew them from my memory till a few hours ago. I'll try to remember that I have to adapt them if I add a new BSP from now on. I only randomly trip across them myself. > > I don't know if it is documented at all. It should be. I don't know where it > would go. Tooling to check consistency would help. > > The other part of this is the forgotten concept of BSP tiers. Tier 1 is for > BSPs with test results reported on real hardware. We don't see that > regularly. > > Tier 2 is simulator testing. We do a lot of that. Speaking for Chris, > he'd like > to see the tests annotated for those not passing. > > Tier 3 is "it builds" and we do a good job of keeping that going. I'm > not sure > we have been on a warning search and destroy lately though. > > Tier 4 is "does not build". These tend to be transient or precursors to the > architecture losing tooling and us dropping it. Yes, these are documented: https://docs.rtems.org/branches/master/user/
Re: Outdated list of BSPs in rtems-tools/config
Hello Joel, On 2023-07-25 15:46, Joel Sherrill wrote: On Tue, Jul 25, 2023 at 5:02 AM Christian MAUDERER <mailto:christian.maude...@embedded-brains.de>> wrote: Hello, I noted that some BSPs are missing in the config files in the rtems-tools repo. If I didn't miss one it's: - aarch64, raspberrypi4b - aarch64, xilinx_zynqmp_lp64_cfc400x - arm, imxrt1166-cm7-saltshaker - arm, stm32h750b-dk - powerpc, mvme2700 - powerpc, phycore_mpc5554 - riscv, kendrytek210 - x86_64, amd64efi One of the BSPs is from me. I don't know of the other ones. I noted the configuration files in that repo just now more or less by chance when playing around with rtems-bsp-builder. I wasn't aware that we have a second list beneath the one printed by the `rtems-bsps` script or `waf bsp-list` in the RTEMS repo. Yep. The list of bsps in the ini files for rtems-bsp-builder get out of date. I was probably the last one to try to sync them back in March. We need some scripting to check them both ways -- additions from rtems and deletions from RTEMS need to be reflected. If we had some tool which checked this, I'd be happy to run it to the cron jobs that do build sweeps and Coverity runs. Wouldn't it be better to try to integrate the information from the ini files into the yml files of the new build system? That way they can't go out of sync. Or is there a special reason that they have to be separate? From a quick glance, every BSP would need an additional "exclude-smp" and "tier" parameter for that. Did I miss that I should have updated rtems-tools (and with that the rtems-source-builder) every time I have added a BSP in the past? Or would it only make problems if I would update these files manually because they are usually created by some script during the release process? Yes. And we all forget to do it. To be honest: I haven't known these files or completely erased that I ever knew them from my memory till a few hours ago. I'll try to remember that I have to adapt them if I add a new BSP from now on. I don't know if it is documented at all. It should be. I don't know where it would go. Tooling to check consistency would help. The other part of this is the forgotten concept of BSP tiers. Tier 1 is for BSPs with test results reported on real hardware. We don't see that regularly. Tier 2 is simulator testing. We do a lot of that. Speaking for Chris, he'd like to see the tests annotated for those not passing. Tier 3 is "it builds" and we do a good job of keeping that going. I'm not sure we have been on a warning search and destroy lately though. Tier 4 is "does not build". These tend to be transient or precursors to the architecture losing tooling and us dropping it. Yes, these are documented: https://docs.rtems.org/branches/master/user/hardware/tiers.html I think the Tiers might start to live again as soon as we have a CI/CD system and the checks for the tiers are automated with that. Till then, the tires will most likely only be checked sporadically. Best regards Christian --joel Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsps/arm: fix installation broken by recent CMSIS files update
Hello Karel,
I tested with the patch from Chris (which is identical to yours) and I
have no problems building and installing the imx7, imxrt1052 and
imxrt1166-cm7-saltshaker BSP and libbsd from master for these BSPs.
The only point that I have noted are a lot of new warnings when building
the BSP. Example:
../../../../../rtems-sources/rtems/bsps/arm/include/cmsis_gcc.h:139:15:
warning: nested extern declaration of '_start' [-Wnested-externs]
139 | extern void _start(void) __NO_RETURN;
Best regards
Christian
On 2023-07-25 08:55, Karel Gardas wrote:
Sure! Not a problem, I was just waiting for Christian to confirm its
also working on his side.
Thanks,
Karel
On 7/25/23 03:34, Chris Johns wrote:
Hi Karel,
I did not see this and made and pushed a similar patch. Thanks for
this and
sorry for not checking closely as I missed it on the first pass.
Thanks
Chris
On 25/7/2023 1:53 am, Karel Gardas wrote:
---
spec/build/bsps/arm/grp.yml | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/spec/build/bsps/arm/grp.yml b/spec/build/bsps/arm/grp.yml
index 1058f58d92..a48cd80d74 100644
--- a/spec/build/bsps/arm/grp.yml
+++ b/spec/build/bsps/arm/grp.yml
@@ -10,12 +10,13 @@ includes: []
install:
- destination: ${BSP_INCLUDEDIR}
source:
+ - bsps/arm/include/cachel1_armv7.h
+ - bsps/arm/include/cmsis_compiler.h
- bsps/arm/include/cmsis_gcc.h
+ - bsps/arm/include/cmsis_version.h
- bsps/arm/include/core_cm7.h
- bsps/arm/include/core_cm4.h
- - bsps/arm/include/core_cmFunc.h
- - bsps/arm/include/core_cmInstr.h
- - bsps/arm/include/core_cmSimd.h
+ - bsps/arm/include/mpu_armv7.h
- bsps/arm/include/uart.h
- destination: ${BSP_INCLUDEDIR}/bsp
source:
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
embedded brains GmbH & Co. KG
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
mobile: +49-176-152 206 08
Registergericht: Amtsgericht München
Registernummer: HRA 117265
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
Outdated list of BSPs in rtems-tools/config
Hello, I noted that some BSPs are missing in the config files in the rtems-tools repo. If I didn't miss one it's: - aarch64, raspberrypi4b - aarch64, xilinx_zynqmp_lp64_cfc400x - arm, imxrt1166-cm7-saltshaker - arm, stm32h750b-dk - powerpc, mvme2700 - powerpc, phycore_mpc5554 - riscv, kendrytek210 - x86_64, amd64efi One of the BSPs is from me. I don't know of the other ones. I noted the configuration files in that repo just now more or less by chance when playing around with rtems-bsp-builder. I wasn't aware that we have a second list beneath the one printed by the `rtems-bsps` script or `waf bsp-list` in the RTEMS repo. Did I miss that I should have updated rtems-tools (and with that the rtems-source-builder) every time I have added a BSP in the past? Or would it only make problems if I would update these files manually because they are usually created by some script during the release process? Best regards Christian -- embedded brains GmbH & Co. KG Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 mobile: +49-176-152 206 08 Registergericht: Amtsgericht München Registernummer: HRA 117265 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
[PATCH rtems 1/2] bsps/shared: Add MCP7940M RTC driver
The MCP7940M is a I2C RTC chip. The new driver uses the dev/i2c API to
support the RTC. It is written with the intention, that the driver can
be adapted to other RTCs with a similar register layout by just
replacing the initialization function.
---
bsps/include/libchip/mcp7940m-rtc.h | 103
bsps/shared/dev/rtc/mcp7940m.c | 362
spec/build/bsps/obj.yml | 2 +
3 files changed, 467 insertions(+)
create mode 100644 bsps/include/libchip/mcp7940m-rtc.h
create mode 100644 bsps/shared/dev/rtc/mcp7940m.c
diff --git a/bsps/include/libchip/mcp7940m-rtc.h
b/bsps/include/libchip/mcp7940m-rtc.h
new file mode 100644
index 00..266400dfba
--- /dev/null
+++ b/bsps/include/libchip/mcp7940m-rtc.h
@@ -0,0 +1,103 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 2023 embedded brains GmbH & Co. KG
+ *
+ * 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 COPYRIGHT HOLDERS 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 COPYRIGHT OWNER 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.
+ */
+
+#ifndef LIBCHIP_MCP7940M_RTC_H
+#define LIBCHIP_MCP7940M_RTC_H
+
+#include
+#include
+#include
+#include
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+extern const rtc_fns rtc_mcp7940m_fns;
+bool rtc_mcp7940m_probe(int minor);
+
+/*
+ * It is expected, that the RTC can be accessed as a raw file. A pointer to a
+ * constant string with the name of that device has to be passed to the table
+ * initializer.
+ *
+ * The MCP7940M uses an EEPROM-like interface. So you could for example use the
+ * following initialization:
+ *
+ * Define a context for the RTC somewhere:
+ *
+ * static struct mcp7940m_rtc rtc_ctx =
+ * MCP7940M_RTC_INITIALIZER("/dev/i2c-1", 0x6F, true);
+ *
+ * Then you can use the following for the RTC_Table:
+ *
+ * MCP7940M_RTC_TBL_ENTRY("/dev/rtc", _ctx)
+ */
+
+struct mcp7940m_rtc {
+ /** Just initialize with RTEMS_MUTEX_INITIALIZER('mcp7940'). */
+ rtems_mutex mutex;
+
+ /** The path of the I2C bus device. */
+ const char *i2c_bus_path;
+
+ /** I2C address. */
+ uint8_t i2c_addr;
+
+ /** True if a crystal should be used. False if an oscillator is connected. */
+ bool crystal;
+
+ /** Whether the RTC has already been initialized. Used internally. */
+ bool initialized;
+};
+
+#define MCP7940M_RTC_INITIALIZER(i2c_path, i2c_address, has_crystal) { \
+.mutex = RTEMS_MUTEX_INITIALIZER("mcp7940m"), \
+.i2c_bus_path = i2c_path, \
+.i2c_addr = i2c_address, \
+.crystal = has_crystal, \
+.initialized = false, \
+ }
+
+#define MCP7940M_RTC_TBL_ENTRY(dev_name, mcp7940m_rtc_ctx) \
+ { \
+.sDeviceName = dev_name, \
+.deviceType = RTC_CUSTOM, \
+.pDeviceFns = _mcp7940m_fns, \
+.deviceProbe = rtc_mcp7940m_probe, \
+.pDeviceParams = (void *)mcp7940m_rtc_ctx, \
+.ulCtrlPort1 = 0, \
+.ulDataPort = 0, \
+.getRegister = NULL, \
+.setRegister = NULL, \
+ }
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+#endif /* LIBCHIP_MCP7940M_RTC_H */
diff --git a/bsps/shared/dev/rtc/mcp7940m.c b/bsps/shared/dev/rtc/mcp7940m.c
new file mode 100644
index 00..78a4f21b58
--- /dev/null
+++ b/bsps/shared/dev/rtc/mcp7940m.c
@@ -0,0 +1,362 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 2023 embedded brains GmbH & Co. KG
+ *
+ * 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
[PATCH rtems 2/2] bsps/arm/imx: Enable shared RTC support
This allows to use a I2C RTC together with this BSP. --- spec/build/bsps/arm/imx/bspimx.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/spec/build/bsps/arm/imx/bspimx.yml b/spec/build/bsps/arm/imx/bspimx.yml index 63733dd5a4..51c2413409 100644 --- a/spec/build/bsps/arm/imx/bspimx.yml +++ b/spec/build/bsps/arm/imx/bspimx.yml @@ -103,6 +103,7 @@ source: - bsps/shared/dev/getentropy/getentropy-cpucounter.c - bsps/shared/dev/irq/arm-gicv2.c - bsps/shared/dev/irq/arm-gicv2-get-attributes.c +- bsps/shared/dev/rtc/rtc-support.c - bsps/shared/dev/serial/console-termios.c - bsps/shared/irq/irq-default-handler.c - bsps/shared/start/bsp-fdt.c -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsps/arm: replace CMSIS v4 with CMSIS v5 files
Hello Karel, with this change, it seems that I can't install an ARM BSP anymore. The core_cmFunc.h and similar files are missing now. I assume that some old headers have to be removed, and new headers added to the yml files. Is it necessary to install all the new headers or only some of them? Best regards Christian On 2023-07-13 23:05, Karel Gardas wrote: CAVEAT: license change from BSD to Apache2 license! Explanation: The imported files come from CMSIS v5 project available on: https://github.com/ARM-software/CMSIS_5/tree/develop The files imported are located inside the CMSIS/Core/Include project sub-directory. The project does not provide any NOTICE file in its root directory nor in the directory of the imported files. The NOTICE file and its usage in the Apache 2 license was/is so far the only issue mentioned in discussion of RTEMS developers/users when considering inclusion of the code under Apache 2 license into the RTEMS project. Since the CMSIS v5 project is free from this legal hinder, we may freely use it and update files to the latest version. Technical: the patch replaces code from 2015 with the latest version which brings quite a lot of bug fixes and most importantly opens possibilities to support MCUs based on new ARM cores. --- bsps/arm/include/cachel1_armv7.h | 441 +++ bsps/arm/include/cmsis_compiler.h | 303 ++ bsps/arm/include/cmsis_gcc.h | 3592 + bsps/arm/include/cmsis_version.h | 39 + bsps/arm/include/core_cm4.h | 629 ++-- bsps/arm/include/core_cm7.h | 4922 ++--- bsps/arm/include/core_cmFunc.h| 87 - bsps/arm/include/core_cmInstr.h | 88 - bsps/arm/include/core_cmSimd.h| 97 - bsps/arm/include/mpu_armv7.h | 275 ++ 10 files changed, 6113 insertions(+), 4360 deletions(-) create mode 100644 bsps/arm/include/cachel1_armv7.h create mode 100644 bsps/arm/include/cmsis_compiler.h create mode 100644 bsps/arm/include/cmsis_version.h delete mode 100644 bsps/arm/include/core_cmFunc.h delete mode 100644 bsps/arm/include/core_cmInstr.h delete mode 100644 bsps/arm/include/core_cmSimd.h create mode 100644 bsps/arm/include/mpu_armv7.h -- embedded brains GmbH & Co. KG Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 mobile: +49-176-152 206 08 Registergericht: Amtsgericht München Registernummer: HRA 117265 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 rtems 6/6] bsps/imxrt: Add imxrt1166_cm7_saltshaker BSP
Hello Jacob, On 2023-07-14 08:36, Christian MAUDERER wrote: Hello Jacob, On 2023-07-13 18:59, Jacob Killelea wrote: Hi Christian, This looks awesome! Do you have any interest in adding support for the i.MXRT1062 based Teensy 4.0 and Teensy 4.1? - Jacob the Teensy look like interesting boards. Maybe a bit low on memory. That would make it difficult to run libbsd on them. The boards don't have network, so it's not a problem for the network part. But on the i.MXRT, I also use the MMC/SD stack from libbsd so the SD card would be a problem. Just noted: The Teensy 4.1 has an optional Ethernet. So some network library would be good. But like I said: The target has too few memory for libbsd. lwIP would be a candidate. But I haven't tried that on the i.MXRT yet. Best regards Christian On the Teensy 4.1, the two memories (optional Flash and optional PSRAM) on the FlexSPI maybe can be a bit tricky. These boards would be pure hobby time. I don't think that I will find enough time to fully support the boards at the moment. But I would expect that the basics should work with the i.MXRT1052 BSP already. The 1050 and 1060 family is quite similar. If you want, I can give you some guidance what would be necessary to support the boards. Best regards Christian -- embedded brains GmbH & Co. KG Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 mobile: +49-176-152 206 08 Registergericht: Amtsgericht München Registernummer: HRA 117265 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 rtems 6/6] bsps/imxrt: Add imxrt1166_cm7_saltshaker BSP
Hello Jacob, On 2023-07-13 18:59, Jacob Killelea wrote: Hi Christian, This looks awesome! Do you have any interest in adding support for the i.MXRT1062 based Teensy 4.0 and Teensy 4.1? - Jacob the Teensy look like interesting boards. Maybe a bit low on memory. That would make it difficult to run libbsd on them. The boards don't have network, so it's not a problem for the network part. But on the i.MXRT, I also use the MMC/SD stack from libbsd so the SD card would be a problem. On the Teensy 4.1, the two memories (optional Flash and optional PSRAM) on the FlexSPI maybe can be a bit tricky. These boards would be pure hobby time. I don't think that I will find enough time to fully support the boards at the moment. But I would expect that the basics should work with the i.MXRT1052 BSP already. The 1050 and 1060 family is quite similar. If you want, I can give you some guidance what would be necessary to support the boards. Best regards Christian -- embedded brains GmbH & Co. KG Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 mobile: +49-176-152 206 08 Registergericht: Amtsgericht München Registernummer: HRA 117265 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
[PATCH rtems-docs] user/bsps/imxrt: Add new BSP variant
Add information about the new i.MXRT1166 BSP. Rework some parts that
have been changed during or as preparation for that variant:
* The BSP now adapts to the Chip variant. It's no longer necessary to
overwrite the PLL settings in an application.
* Improve documentation on how to adapt to different boards.
* Add Update the i.MXRT chapter so that it represents the new i.MXRT1166
BSP.
* Add information about mcux-sdk and how to handle it.
---
user/bsps/arm/imxrt.rst | 117 +++-
1 file changed, 81 insertions(+), 36 deletions(-)
diff --git a/user/bsps/arm/imxrt.rst b/user/bsps/arm/imxrt.rst
index 3df233f..ad18766 100644
--- a/user/bsps/arm/imxrt.rst
+++ b/user/bsps/arm/imxrt.rst
@@ -6,14 +6,17 @@
imxrt (NXP i.MXRT)
==
-This BSP offers only one variant, the `imxrt1052`. This variant supports the
-i.MXRT 1052 processor on a IMXRT1050-EVKB (tested with rev A1). You can also
-configure it to work with custom boards.
+This BSP offers multiple variants. The `imxrt1052` supports the i.MXRT 1052
+processor on a IMXRT1050-EVKB (tested with rev A1). Some possibilities to adapt
+it to a custom board are described below.
NOTE: The IMXRT1050-EVKB has an backlight controller that must not be enabled
without load. Make sure to either attach a load, disable it by software or
disable it by removing the 0-Ohm resistor on it's input.
+The `imxrt1166-cm7-saltshaker` supports an application specific board. Adapting
+it to another i.MXRT1166 based board works similar like for the `imxrt1052`
BSP.
+
Build Configuration Options
---
@@ -22,8 +25,24 @@ for that. You can generate a default set of options with::
./waf bspdefaults --rtems-bsps=arm/imxrt1052 > config.ini
-Boot Process
-
+Adapting to a different board
+-
+
+This is only a short overview for the most important steps to adapt the BSP to
+another board. Details for most steps follow further below.
+
+#. The device tree has to be adapted to fit the target hardware.
+#. A matching clock configuration is necessary (simplest method is to generate
+ it with the NXP PinMux tool)
+#. The `dcd_data` has to be adapted. That is used for example to initialize
+ SDRAM.
+#. `imxrt_flexspi_config` has to be adapted to match the Flash connected to
+ FlexSPI (if that is used).
+#. `BOARD_InitDEBUG_UARTPins` should be adapted to match the used system
+ console.
+
+Boot Process of IMXRT1050-EVKB
+--
There are two possible boot processes supported:
@@ -82,18 +101,19 @@ ones that need different values):
You can find the default definitions in `bsps/arm/imxrt/start/flash-*.c`. Take
a
look at the `i.MX RT1050 Processor Reference Manual, Rev. 4, 12/2019` chapter
-`9.7 Program image` for details about the contents.
+`9.7 Program image` or `i.MX RT1166 Processor Reference Manual, Rev. 0,
05/2021`
+chapter `10.7 Program image` for details about the contents.
FDT
---
The BSP uses a FDT based initialization. The FDT is linked into the
application.
-You can find the default FDT used in the BSP in
-`bsps/arm/imxrt/dts/imxrt1050-evkb.dts`. The FDT is split up into two parts.
The
-core part is put into an `dtsi` file and is installed together with normal
-headers into `${PREFIX}/arm-rtems@rtems-ver-major@/imxrt1052/lib/include`. You
-can use that to create your own device tree based on that. Basically use
-something like::
+You can find the default FDT used in the BSPs in `bsps/arm/imxrt/dts`. The FDT
+is split up into two parts. The controller specific part is put into an `dtsi`
+file. The board specific one is in the dts file. Both are installed together
+with normal headers into
+`${PREFIX}/arm-rtems@rtems-ver-major@/${BSP}/lib/include`. You can use that to
+create your own device tree based on that. Basically use something like::
/dts-v1/;
@@ -137,26 +157,6 @@ You'll get a C file which defines the `imxrt_dtb` array.
Make sure that your new
C file is compiled and linked into the application. It will overwrite the
existing definition of the `imxrt_dtb` in RTEMS.
-PLL Settings
-
-
-The commercial variant of the i.MXRT1052 on the evaluation board allows a clock
-up to 600MHz for the ARM core. For some industrial variants only up to 528MHz
-are specified. To make it possible to adapt to these variants the application
-can overwrite the following constant:
-
-.. code-block:: c
-
- #include "fsl_clock_config.h"
-
- const clock_arm_pll_config_t armPllConfig_BOARD_BootClockRUN = {
- .loopDivider = 100,
- .src = 0,
- };
-
-With the default configuration of a 24MHz oscillator, the loopDivider has to be
-88 for the 528MHz.
-
Clock Driver
@@ -225,13 +225,58 @@ the SDK. But please note that they are not tested and
maybe won't work out of
the box. Everything that works with interrupts most likely needs some special
treatment.
-Caveats
+The SDK files
[PATCH rtems 2/6] bsps/imxrt: Fix getting qtmr clock for i.MXRT11xx
The function returned a multiplexer value instead of the frequency. --- bsps/arm/imxrt/mcux-sdk/drivers/qtmr_1/fsl_qtmr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsps/arm/imxrt/mcux-sdk/drivers/qtmr_1/fsl_qtmr.c b/bsps/arm/imxrt/mcux-sdk/drivers/qtmr_1/fsl_qtmr.c index 4c8bd71be5..33271d6e9a 100644 --- a/bsps/arm/imxrt/mcux-sdk/drivers/qtmr_1/fsl_qtmr.c +++ b/bsps/arm/imxrt/mcux-sdk/drivers/qtmr_1/fsl_qtmr.c @@ -99,7 +99,7 @@ uint32_t QTMR_get_src_clk(TMR_Type *base) #elif IMXRT_IS_MIMXRT11xx (void) base; -return CLOCK_GetRootClockMux(kCLOCK_Root_Bus); +return CLOCK_GetRootClockFreq(kCLOCK_Root_Bus); #else #error Getting Timer clock frequency is not implemented for this chip #endif -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd] imx: Enable GPIO driver for imxrt too
---
rtemsbsd/sys/arm/freescale/imx/imx_rtems_gpio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/rtemsbsd/sys/arm/freescale/imx/imx_rtems_gpio.c
b/rtemsbsd/sys/arm/freescale/imx/imx_rtems_gpio.c
index c24732cc..da64922f 100644
--- a/rtemsbsd/sys/arm/freescale/imx/imx_rtems_gpio.c
+++ b/rtemsbsd/sys/arm/freescale/imx/imx_rtems_gpio.c
@@ -27,7 +27,7 @@
*/
#include
-#if defined(LIBBSP_ARM_IMX_BSP_H)
+#if defined(LIBBSP_ARM_IMX_BSP_H) || defined(LIBBSP_ARM_IMXRT_BSP_H)
#include
__FBSDID("$FreeBSD$");
@@ -303,4 +303,4 @@ EARLY_DRIVER_MODULE(imx_rtems_gpio, simplebus,
imx_rtems_gpio_driver,
imx_rtems_gpio_devclass, NULL, NULL,
BUS_PASS_RESOURCE + BUS_PASS_ORDER_MIDDLE);
-#endif /* LIBBSP_ARM_IMX_BSP_H */
+#endif /* LIBBSP_ARM_IMX_BSP_H || LIBBSP_ARM_IMXRT_BSP_H */
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 5/6] bsps/imsrt: Make flash config more flexible
The flash configuration is something very board specific. So move the
file to a board specific location. Beneath that, not all controllers and
configurations need the flash config right at the address 0 of the
flash. For example on the i.MXRT11xx, the config has an offset for some
flash types.
---
.../evkbimxrt1050}/flash-flexspi-config.c | 0
bsps/arm/imxrt/include/imxrt/memory.h | 4
bsps/arm/imxrt/start/flash-boot-data.c| 2 +-
bsps/arm/imxrt/start/mpu-config.c | 4 ++--
spec/build/bsps/arm/imxrt/bspimxrt1052.yml| 1 +
spec/build/bsps/arm/imxrt/grp.yml | 4 +++-
spec/build/bsps/arm/imxrt/linkcmdsmemory.yml | 15 -
spec/build/bsps/arm/imxrt/obj.yml | 1 -
.../bsps/arm/imxrt/optmemflashcfgoffset.yml | 21 +++
.../build/bsps/arm/imxrt/optmemflashcfgsz.yml | 20 --
.../bsps/arm/imxrt/optmemflashivtoffset.yml | 20 ++
11 files changed, 62 insertions(+), 30 deletions(-)
rename bsps/arm/imxrt/{start => boards/evkbimxrt1050}/flash-flexspi-config.c
(100%)
create mode 100644 spec/build/bsps/arm/imxrt/optmemflashcfgoffset.yml
delete mode 100644 spec/build/bsps/arm/imxrt/optmemflashcfgsz.yml
create mode 100644 spec/build/bsps/arm/imxrt/optmemflashivtoffset.yml
diff --git a/bsps/arm/imxrt/start/flash-flexspi-config.c
b/bsps/arm/imxrt/boards/evkbimxrt1050/flash-flexspi-config.c
similarity index 100%
rename from bsps/arm/imxrt/start/flash-flexspi-config.c
rename to bsps/arm/imxrt/boards/evkbimxrt1050/flash-flexspi-config.c
diff --git a/bsps/arm/imxrt/include/imxrt/memory.h
b/bsps/arm/imxrt/include/imxrt/memory.h
index 3fc8f0bbfa..52163d040f 100644
--- a/bsps/arm/imxrt/include/imxrt/memory.h
+++ b/bsps/arm/imxrt/include/imxrt/memory.h
@@ -56,6 +56,10 @@ extern char imxrt_memory_peripheral_begin[];
extern char imxrt_memory_peripheral_end[];
extern char imxrt_memory_peripheral_size[];
+extern char imxrt_memory_flash_raw_begin[];
+extern char imxrt_memory_flash_raw_end[];
+extern char imxrt_memory_flash_raw_size[];
+
extern char imxrt_memory_flash_config_begin[];
extern char imxrt_memory_flash_config_end[];
extern char imxrt_memory_flash_config_size[];
diff --git a/bsps/arm/imxrt/start/flash-boot-data.c
b/bsps/arm/imxrt/start/flash-boot-data.c
index 485f91c8ec..2186fc08bf 100644
--- a/bsps/arm/imxrt/start/flash-boot-data.c
+++ b/bsps/arm/imxrt/start/flash-boot-data.c
@@ -30,7 +30,7 @@
#include
const BOOT_DATA_T imxrt_boot_data = {
- .start = (uint32_t) imxrt_memory_flash_config_begin,
+ .start = (uint32_t) imxrt_memory_flash_raw_begin,
.size = IMXRT_MEMORY_FLASH_SIZE,
.plugin = PLUGIN_FLAG,
.placeholder = 0x,
diff --git a/bsps/arm/imxrt/start/mpu-config.c
b/bsps/arm/imxrt/start/mpu-config.c
index 8928980445..a8f98f1c81 100644
--- a/bsps/arm/imxrt/start/mpu-config.c
+++ b/bsps/arm/imxrt/start/mpu-config.c
@@ -44,8 +44,8 @@ BSP_START_DATA_SECTION const ARMV7M_MPU_Region_config
| ARMV7M_MPU_RASR_TEX(0x1) | ARMV7M_MPU_RASR_C | ARMV7M_MPU_RASR_B
| ARMV7M_MPU_RASR_ENABLE,
}, {
- .begin = imxrt_memory_flash_config_begin,
- .end = imxrt_memory_flash_end,
+ .begin = imxrt_memory_flash_raw_begin,
+ .end = imxrt_memory_flash_raw_end,
.rasr = ARMV7M_MPU_RASR_AP(0x3)
| ARMV7M_MPU_RASR_TEX(0x1) | ARMV7M_MPU_RASR_C | ARMV7M_MPU_RASR_B
| ARMV7M_MPU_RASR_ENABLE,
diff --git a/spec/build/bsps/arm/imxrt/bspimxrt1052.yml
b/spec/build/bsps/arm/imxrt/bspimxrt1052.yml
index d2bd43d84d..8413b4bef1 100644
--- a/spec/build/bsps/arm/imxrt/bspimxrt1052.yml
+++ b/spec/build/bsps/arm/imxrt/bspimxrt1052.yml
@@ -25,6 +25,7 @@ links:
source:
- bsps/arm/imxrt/boards/evkbimxrt1050/clock_config.c
- bsps/arm/imxrt/boards/evkbimxrt1050/flash-dcd.c
+- bsps/arm/imxrt/boards/evkbimxrt1050/flash-flexspi-config.c
- bsps/arm/imxrt/boards/evkbimxrt1050/pin_mux.c
- bsps/arm/imxrt/boards/evkbimxrt1050/clock-arm-pll-config.c
- bsps/arm/imxrt/dts/imxrt1050-evkb.c
diff --git a/spec/build/bsps/arm/imxrt/grp.yml
b/spec/build/bsps/arm/imxrt/grp.yml
index c8128ef10d..6191823899 100644
--- a/spec/build/bsps/arm/imxrt/grp.yml
+++ b/spec/build/bsps/arm/imxrt/grp.yml
@@ -33,7 +33,9 @@ links:
- role: build-dependency
uid: optmemextramsz
- role: build-dependency
- uid: optmemflashcfgsz
+ uid: optmemflashcfgoffset
+- role: build-dependency
+ uid: optmemflashivtoffset
- role: build-dependency
uid: optmemflashivtsz
- role: build-dependency
diff --git a/spec/build/bsps/arm/imxrt/linkcmdsmemory.yml
b/spec/build/bsps/arm/imxrt/linkcmdsmemory.yml
index d50d2c814b..967423ed6b 100644
--- a/spec/build/bsps/arm/imxrt/linkcmdsmemory.yml
+++ b/spec/build/bsps/arm/imxrt/linkcmdsmemory.yml
@@ -5,12 +5,13 @@ content: |
NULL : ORIGIN = 0x, LENGTH =
${IMXRT_MEMORY_NULL_SIZE:#010x}
ITCM : ORIGIN = ${IMXRT_MEMORY_NULL_SIZE:#010x}, LENGTH =
${IMXRT_MEMORY_ITCM_SIZE:#010x}
DTCM :
[PATCH rtems 1/6] bsps/imxrt1050: Install device tree sources
Useful for creating an application specific device tree that is based on
the evaluation board.
---
spec/build/bsps/arm/imxrt/bspimxrt1052.yml | 1 +
1 file changed, 1 insertion(+)
diff --git a/spec/build/bsps/arm/imxrt/bspimxrt1052.yml
b/spec/build/bsps/arm/imxrt/bspimxrt1052.yml
index ec218112ac..d2bd43d84d 100644
--- a/spec/build/bsps/arm/imxrt/bspimxrt1052.yml
+++ b/spec/build/bsps/arm/imxrt/bspimxrt1052.yml
@@ -16,6 +16,7 @@ includes:
install:
- destination: ${BSP_INCLUDEDIR}/imxrt
source:
+ - bsps/arm/imxrt/dts/imxrt1050-evkb.dts
- bsps/arm/imxrt/include/imxrt/imxrt1050.dtsi
- bsps/arm/imxrt/include/imxrt/imxrt1050-pinfunc.h
links:
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 4/6] bsps/imx*: Support more GPIO controllers
The imx-gpio driver used in i.MX and i.MXRT BSPs generates a name based
on a fixed string. The original code only used one digit for the
controller. With the 13 GPIO controllers of the i.MXRT1166, that isn't
enough any more. This patch extends the name to two digits which should
be enough for the next controller generations.
---
bsps/arm/shared/pins/imx-gpio.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/bsps/arm/shared/pins/imx-gpio.c b/bsps/arm/shared/pins/imx-gpio.c
index 615e13da7d..8b7d09e864 100644
--- a/bsps/arm/shared/pins/imx-gpio.c
+++ b/bsps/arm/shared/pins/imx-gpio.c
@@ -33,14 +33,17 @@
#include
#include
-#define IMX_GPIO_ALIAS_NAME "gpioX"
+/*
+ * Most of the time it's gpio1 or gpio13.
+ */
+#define IMX_GPIO_ALIAS_NAME "gpioXY"
/*
- * i.MX6ULL has 5, i.MX7D has 7
+ * i.MX6ULL has 5, i.MX7D has 7, i.MXRT1160 has 13 (base) + 2 (core-specific).
*
* Be careful when changing this. The attach() does a simple ASCII conversion.
*/
-#define IMX_MAX_GPIO_MODULES 7
+#define IMX_MAX_GPIO_MODULES 15
struct imx_gpio_regs {
uint32_t dr;
@@ -88,7 +91,14 @@ static void imx_gpio_attach(void)
int len;
memcpy(imx_gpio[i].name, IMX_GPIO_ALIAS_NAME, sizeof(IMX_GPIO_ALIAS_NAME));
-imx_gpio[i].name[sizeof(IMX_GPIO_ALIAS_NAME)-2] = (char)('0' + i);
+if (i < 10) {
+ imx_gpio[i].name[sizeof(IMX_GPIO_ALIAS_NAME)-3] = (char)('0' + i);
+ imx_gpio[i].name[sizeof(IMX_GPIO_ALIAS_NAME)-2] = '\0';
+} else {
+ imx_gpio[i].name[sizeof(IMX_GPIO_ALIAS_NAME)-3] = (char)('0' + i / 10);
+ imx_gpio[i].name[sizeof(IMX_GPIO_ALIAS_NAME)-2] = (char)('0' + i % 10);
+ imx_gpio[i].name[sizeof(IMX_GPIO_ALIAS_NAME)-1] = '\0';
+}
path = fdt_get_alias(fdt, imx_gpio[i].name);
if (path == NULL) {
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 3/6] imxrt/mcux-sdk: Add HREQ-related bits
According to the reference manual the bits exist and they can be used.
Also confirmed by NXP support in the community forum:
https://community.nxp.com/t5/i-MX-RT/i-MXRT1160-LPSPI-HREQ-supported/m-p/1668647#M25512
---
.../devices/MIMXRT1166/MIMXRT1166_cm7.h | 25 +++
1 file changed, 25 insertions(+)
diff --git a/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1166/MIMXRT1166_cm7.h
b/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1166/MIMXRT1166_cm7.h
index 64ce9ee126..1936e4c5de 100644
--- a/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1166/MIMXRT1166_cm7.h
+++ b/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1166/MIMXRT1166_cm7.h
@@ -60038,6 +60038,31 @@ typedef struct {
/*! @name CFGR0 - Configuration 0 */
/*! @{ */
+#ifdef __rtems__
+#define LPSPI_CFGR0_HREN_MASK(0x1U)
+#define LPSPI_CFGR0_HREN_SHIFT (0U)
+/*! HREN - Host Request Enable
+ * 0b0..Host request is disabled
+ * 0b1..Host request is enabled
+ */
+#define LPSPI_CFGR0_HREN(x) (((uint32_t)(((uint32_t)(x))
<< LPSPI_CFGR0_HREN_SHIFT)) & LPSPI_CFGR0_HREN_MASK)
+
+#define LPSPI_CFGR0_HRPOL_MASK (0x2U)
+#define LPSPI_CFGR0_HRPOL_SHIFT (1U)
+/*! HRPOL - Host Request Polarity
+ * 0b0..LPSPI_HREQ pin is active low
+ * 0b1..LPSPI_HREQ pin is active high
+ */
+#define LPSPI_CFGR0_HRPOL(x) (((uint32_t)(((uint32_t)(x))
<< LPSPI_CFGR0_HRPOL_SHIFT)) & LPSPI_CFGR0_HRPOL_MASK)
+
+#define LPSPI_CFGR0_HRSEL_MASK (0x4U)
+#define LPSPI_CFGR0_HRSEL_SHIFT (2U)
+/*! HRSEL - Host Request Select
+ * 0b0..Host request input is the LPSPI_HREQ pin
+ * 0b1..Host request input is the input trigger
+ */
+#define LPSPI_CFGR0_HRSEL(x) (((uint32_t)(((uint32_t)(x))
<< LPSPI_CFGR0_HRSEL_SHIFT)) & LPSPI_CFGR0_HRSEL_MASK)
+#endif /* __rtems__ */
#define LPSPI_CFGR0_CIRFIFO_MASK (0x100U)
#define LPSPI_CFGR0_CIRFIFO_SHIFT(8U)
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCHES] Add i.MXRT1166 based BSP
Hello, some weeks back, I mentioned that I want to add a new BSP variant to the i.MXRT family. Now I have finally a version that is clean enough to publish it. I'm sure that some more patches for further components will follow (like USB). But the current version is stable and usable enough to publish it. The patch set also includes a documentation patch to bring the manual for that BSP family up to date. Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Need community suggestions for a new generic GPIO API
Hello Utkarsh, please be a bit careful with GPIO and pin functions. That's a quite difficult topic. Some controller manufacturers mix these functions. One such example is the STM32 family. I'll take the STM32F410 as an example. That chip has a GPIO register block with one GPIOx_MODER where you can select whether a pin is a Input, GPIO, alternate function or analog mode. There is also a GPIOx_OSPEEDR that defines speed and some others that define pull ups / downs and so on. Other controllers - like a lot of the NXP ones - have two completely independent modules for that. I'll take the i.MXRT1050 series as an example: That chip has an IOMUXC where you can set a pin function for a pad. For example, there is a register IOMUXC_SW_MUX_CTL_PAD_GPIO_EMC_26. In that register, you can set a pin function of GPIO4_IO26. There is a related PAD_CTL register in the IOMUXC where you can set up pull ups / downs, drive strength and so on. The GPIO controller where you set up levels and interrupts for that pin is a completely unrelated module. On the i.MXRT1166 you can even assign some pins to two different GPIO controllers. So it's not possible to have a 1:1 mapping between pin and GPIO. If you ask me GPIO and pin function are two separate things and need two APIs. That should make it possible to support controllers like the STM32 (where some of the GPIO registers would be controlled by the GPIO API and some by the pin function API) and for controllers like the i.MXRT where the two APIs would handle different hardware modules. If you take a look at Linux or FreeBSD, they usually split that up just like that. If you want to dig deeper into that, maybe it would be worth to take a look at some other embedded operating systems. For example Zephyr or Contiki or any of the ones in Wikipedia "Comparison of real-time operating systems". It can even be a good idea to create a compatible interface. Best regards Christian On 2023-07-07 21:48, Utkarsh Verma wrote: Dear all, While working on the Raspberry Pi 4 BSP, I realized that the GPIO API could be improved. It seems that last year, a GSoC student worked on introducing a new GPIO API, called GPIO2 to RTEMS. However, it did not get merged. Discussing this topic with my mentor and on RTEMS Discord revealed that it would be a good idea to get it merged. For that, I would like to ask the community the following: - Moving forward, will GPIO2 API be the community-preferred GPIO API? - What would be the recommended way in this new API to select alternate pin functions? Will that be left for the BSP to decide? Here are the links associated with GPIO2: Git Repo: https://github.com/dtbpkmte/GSoC-2022-RTEMS GPIO2 commit: https://github.com/dtbpkmte/GSoC-2022-RTEMS/commit/0aec268f1209c Blog post about the API: https://medium.com/@dtbpkmte/gsoc-2022-rtems-coding-period-week-4-gpio-wiki-1f10e5c4458 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- embedded brains GmbH & Co. KG Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 mobile: +49-176-152 206 08 Registergericht: Amtsgericht München Registernummer: HRA 117265 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: GIT Issues?
Hello Cedric, Am 03.07.23 um 08:47 schrieb Cedric Berger: Hello, Two issues here: 1) When looking at RTEMS on github, it seems everything stopped being updated on March 23. > 2) Then going to https://www.rtems.org, clicking "Git" yield this page: Trac Error Page Developer/Git not found Sounds like a broken link on the homepage. As a workaround, you can reach https://git.rtems.org directly. Best regards Christian Is there something we can do to help with this situation? Cedric ___ 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: RTEMS-libbsd freebsd-org submodule would require update in order to import genet drivers. Suggestions?
Hello Alan and Noor, please note that updating libbsd to a newer FreeBSD version is a bit more work than pushing the hash of the freebsd-org submodule. The basic process is: - use freebsd-to-rtems.py to copy changes from libbsd to the freebsd-org - commit them there - rebase to a newer release - fix all problems during the rebase - take a look at the changed subsystems in freebsd - use freebsd-to-rtems.py to copy the changes back from freebsd-org to libbsd Last time I talked to Sebastian about that, he estimated the update to the current release to be the work of a few weeks. Sebastian did all updates in the last years, so I think I can trust that estimation. I think currently your best approach is to try to do a backport on a branch. If you have well isolated drivers, rebasing that backport on a newer libbsd version should be possible. Please note that backports most likely won't be directly included in libbsd. They make the upgrade process a lot more complicated. So I'm sure that someone will object to include a backport in the master branch. Still: I think the backport on a branch is currently the best approach for your project. Best regards Christian On 2023-06-04 19:18, Noor Aman wrote: Hi Alan, If you have not done so already, would it be worth trying to build and initialize the current libbsd with a loopback driver? I haven't done it so far, This might help. Thanks. Are there other devices on the RPI4 such as the SD card or USB that may be usable in the current libbsd on the Pi 4? The only thing which I think might be compatible would be arasan SD card drivers. And every other peripheral's drivers isn't present in the current rtems-libbsd state. I know it will not get you the ethernet driver you need, but having an environment that runs on the board might be a step in the right direction. How hard do you think it would be to backport the ethernet driver to the current rtems-libbsd release? I'm not sure how difficult it would be to backport since it's a major release (backporting from 13.x to 12.x). It will take a while to figure all that out. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- embedded brains GmbH & Co. KG Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 mobile: +49-176-152 206 08 Registergericht: Amtsgericht München Registernummer: HRA 117265 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: Discussion: How to handle HALs, SDKs and libraries
On 2023-05-25 01:57, Chris Johns wrote: On 24/5/2023 5:07 pm, Christian MAUDERER wrote: Hello Chris, On 2023-05-24 03:44, Chris Johns wrote: Hi Christian, Thanks for raising this topic. It is a tough one. On 24/5/2023 12:11 am, Kinsey Moore wrote: On Tue, May 23, 2023 at 2:26 AM Christian MAUDERER mailto:christian.maude...@embedded-brains.de>> wrote: Hello, I recently updated the HAL in the i.MXRT BSP. I used the same approach that we use for a lot of similar cases: Import the sources into RTEMS and adapt them slightly so that they work for us. So basically a Clone-and-Own approach. During the discussion of the patches, some concerns were raised, whether we should find a better solution to handle HALs, SDKs and similar cases. We should start discussing a solution that can be used after the 6 release so that maybe someone can start to work on a prototype. Some example cases are: - the mcux_sdk in the imxrt BSP - the hal in the stm32h7 BSP - general ARM CMSIS files - zlib - libfdt One solution could be to build these libraries external and only link RTEMS with them. There are disadvantages to this aproach: - Also in my experience, the API of the HALs / SDKs / libraries seems to be quite stable, it's possible that there are combinations where some unexpected change breaks a driver or makes it impossible to link the applications. Xilinx with the more complex devices like the Versal have been moving things about. The Versal SMC call set is fluid and the PM (platform manager) seems to functionally align to Xilinx tools releases plus Petalinux versions. For example there are stable defined API calls in Versal Linux (XRT/zocl) that depends on PM code that is commented in the code as "to be removed". When I first used the Zynq I used Xilinx's drivers like OAR is currently with the Microblaze. I could not release the results because of the license at the time. I quickly found the drivers lacked functionality for general use and broke under high loads and boundary conditions. The fixes are part of a project and cannot be released because the license at the time made it impossible. What I leant from the exercise is to not depend on their drivers. That sounds like a quite bad case. So it's a good example for that discussion. Thanks for bringing it up. I view the repo as open but not open source ... if that sentence makes sense? I think I understand what you mean. But it's still a good example for the discussion. If a solution theoretically works with that case, it should work with a lot of other cases too. I feel what we considered stable will depend on the origin of the code and that will be case by case. Agreed. - BSPs rely on basic drivers from these libraries (like console or clock driver). If we link against the libraries, the testsuite wouldn't build any more without preinstalled libraries. Yes the mutual dependence if built externally and before RTEMS is not easy to solve. The idea of the HAL code being supplied as .h and a .a does let a user update the drivers without needing an RTEMS version update. Another solution could be to include libraties like that as submodules and build them using the RTEMS build system. We could clone the repos onto the RTEMS git server, and add necessary patches. Advantage would be that it is more similar to the process that we currently have. Another advantage is that we have a known-working version of the files. Upstream updates could be either merged or we could rebase our patches to a new version. See below for the problems this creates. From my point of view, the second option would be the better one especially because we have a tested, fixed version of the library instead telling the user to just use some random version that might or might not work. This is important. We need to define what a release is and it is a requirement we provide all code as tarball files. This implies the release process knows how to create the tarfiles. Regardless which aproach we use: We have to think about how to handle that on releases. In the link aproach (first case), we have to somehow archive source tar balls and some kind of build recipe. In the submodule aproach, we could checkout all submodules and pack the files into the RTEMS release tar ball. So I would expect that the second aproach has less impact here too. Comments? Improvements? Better suggestions? I would definitely prefer the submodule approach over the linking approach to avoid the test issues since some of these HALs bring core functionality. The Xilinx driver framework (embeddedsw repo on Github) would be well-suited to the submodule approach since it is already broken out into the shared driver space beca
Re: [PATCH rtems-libbsd] ipsec-tools: Fix copying fd_set prior to select
On 2023-05-24 02:33, Chris Johns wrote:
On 24/5/2023 9:13 am, Chris Johns wrote:
On 23/5/2023 5:30 pm, Christian MAUDERER wrote:
Hello Chris,
On 2023-05-23 08:53, Chris Johns wrote:
On 23/5/2023 4:25 pm, Christian MAUDERER wrote:
Hello Chris,
On 2023-05-23 03:36, Chris Johns wrote:
Hi,
I have been resolving this by adding:
#define preset_mask *preset_mask_prealloc
#define active_mask *active_mask_prealloc
as the assignment logic works as is. It does not catch FD_ZERO which is a shame
but is helps avoid us adding a special case.
Thanks for the suggestion. I used that solution already in the file during the
initial port. But it doesn't work in this case (and maybe we should check other
cases in libbsd too). It only copies the first element of the array of fd_sets.
The variables / defines are (in the patched version - see [1]):
static fd_set *allocated_preset_mask, *allocated_active_mask;
static struct fd_monitor *allocated_fd_monitors;
#define preset_mask (*allocated_preset_mask)
#define active_mask (*allocated_active_mask)
#define fd_monitors (allocated_fd_monitors)
They are allocated as follows (see [2]):
allocated_preset_mask = calloc(sizeof(fd_set),
howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
allocated_active_mask = calloc(sizeof(fd_set),
howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
allocated_fd_monitors = calloc(
rtems_libio_number_iops, sizeof(struct fd_monitor));
So basically it's a bunch of arrays of fd_sets. If I now use the following
(unpatched) assignment:
active_mask = preset_mask;
After the preprocessor the line will be
(*allocated_active_mask) = (*allocated_preset_mask);
Which copies only the first element. That's why I had to add the memcpy. Did I
miss some better solution?
I am using this in ntpd which I checked yesterday:
#ifdef __rtems__
#include
static size_t rtems_ntpd_fds_size;
static int rtems_fd_set_alloc(fd_set **setp) {
if (*setp == NULL) {
rtems_ntpd_fds_size = sizeof(fd_set) *
(howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
*setp = malloc(rtems_ntpd_fds_size);
if (*setp == NULL) {
errno = ENOMEM;
return -1;
}
memset(*setp, 0, rtems_ntpd_fds_size);
}
return 0;
}
#define activefds (*activefds_prealloc)
static fd_set *activefds_prealloc;
#define rtems_activefds_alloc() rtems_fd_set_alloc(_prealloc)
#else /* __rtems__ */
static fd_set activefds;
#endif /* __rtems__ */
and:
#if __rtems__
#define rdfdes (*rdfdes_prealloc)
static fd_set *rdfdes_prealloc;
#else /* __rtems__ */
fd_set rdfdes;
#endif /* __rtems__ */
int nfound;
#if __rtems__
if (rtems_fd_set_alloc(_prealloc) < 0) {
return;
}
memset(rdfdes_prealloc, 0, rtems_ntpd_fds_size);
#else /* __rtems__ */
FD_ZERO();
#endif /* __rtems__ */
with:
++handler_calls;
rdfdes = activefds;
But isn't that line resolving to
(*rdfdes_prealloc) = (*activefds_prealloc);
That would also copy only the first element.
Stepping:
Thread 9 hit Breakpoint 1, _ntp_io_handler () at
../../bsd/freebsd/contrib/ntp/ntpd/ntp_io.c:3727
3727 rdfdes = activefds;
(gdb) x /8bx activefds_prealloc
0x1083e650: 0x20 0x44 0x05 0x20 0x00 0x40 0x00 0x00
(gdb) x /8bx rdfdes_prealloc
0x108353a0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
(gdb) n
3736 t1.tv_usec = 0;
(gdb) x /8bx rdfdes_prealloc
0x108353a0: 0x20 0x44 0x05 0x20 0x00 0x40 0x00 0x00
Looks ok to me.
fd_set is 64 bit wide. So a copy of the first 64 bit works. Does it still work
if you have 256 files in the system?
Good question. I have not checked but I will.
FYI EPICS has set its limit to 64 because of this issue with select. I suspect
they do not want to hack their select calls like this and I understand them
taking that position.
Yes, I see the issue. The equate only works if the file ops count is the same as
the newlib defined fd_set.
Chris
Thanks for the confirmation. Do you see a better solution than the
memcpy in my patch?
Best regards
Christian
--
embedded brains GmbH & Co. KG
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
mobile: +49-176-152 206 08
Registergericht: Amtsgericht München
Registernummer: HRA 117265
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: Discussion: How to handle HALs, SDKs and libraries
Hello Chris, On 2023-05-24 03:44, Chris Johns wrote: Hi Christian, Thanks for raising this topic. It is a tough one. On 24/5/2023 12:11 am, Kinsey Moore wrote: On Tue, May 23, 2023 at 2:26 AM Christian MAUDERER mailto:christian.maude...@embedded-brains.de>> wrote: Hello, I recently updated the HAL in the i.MXRT BSP. I used the same approach that we use for a lot of similar cases: Import the sources into RTEMS and adapt them slightly so that they work for us. So basically a Clone-and-Own approach. During the discussion of the patches, some concerns were raised, whether we should find a better solution to handle HALs, SDKs and similar cases. We should start discussing a solution that can be used after the 6 release so that maybe someone can start to work on a prototype. Some example cases are: - the mcux_sdk in the imxrt BSP - the hal in the stm32h7 BSP - general ARM CMSIS files - zlib - libfdt One solution could be to build these libraries external and only link RTEMS with them. There are disadvantages to this aproach: - Also in my experience, the API of the HALs / SDKs / libraries seems to be quite stable, it's possible that there are combinations where some unexpected change breaks a driver or makes it impossible to link the applications. Xilinx with the more complex devices like the Versal have been moving things about. The Versal SMC call set is fluid and the PM (platform manager) seems to functionally align to Xilinx tools releases plus Petalinux versions. For example there are stable defined API calls in Versal Linux (XRT/zocl) that depends on PM code that is commented in the code as "to be removed". When I first used the Zynq I used Xilinx's drivers like OAR is currently with the Microblaze. I could not release the results because of the license at the time. I quickly found the drivers lacked functionality for general use and broke under high loads and boundary conditions. The fixes are part of a project and cannot be released because the license at the time made it impossible. What I leant from the exercise is to not depend on their drivers. That sounds like a quite bad case. So it's a good example for that discussion. Thanks for bringing it up. I feel what we considered stable will depend on the origin of the code and that will be case by case. Agreed. - BSPs rely on basic drivers from these libraries (like console or clock driver). If we link against the libraries, the testsuite wouldn't build any more without preinstalled libraries. Yes the mutual dependence if built externally and before RTEMS is not easy to solve. The idea of the HAL code being supplied as .h and a .a does let a user update the drivers without needing an RTEMS version update. Another solution could be to include libraties like that as submodules and build them using the RTEMS build system. We could clone the repos onto the RTEMS git server, and add necessary patches. Advantage would be that it is more similar to the process that we currently have. Another advantage is that we have a known-working version of the files. Upstream updates could be either merged or we could rebase our patches to a new version. See below for the problems this creates. From my point of view, the second option would be the better one especially because we have a tested, fixed version of the library instead telling the user to just use some random version that might or might not work. This is important. We need to define what a release is and it is a requirement we provide all code as tarball files. This implies the release process knows how to create the tarfiles. Regardless which aproach we use: We have to think about how to handle that on releases. In the link aproach (first case), we have to somehow archive source tar balls and some kind of build recipe. In the submodule aproach, we could checkout all submodules and pack the files into the RTEMS release tar ball. So I would expect that the second aproach has less impact here too. Comments? Improvements? Better suggestions? I would definitely prefer the submodule approach over the linking approach to avoid the test issues since some of these HALs bring core functionality. The Xilinx driver framework (embeddedsw repo on Github) would be well-suited to the submodule approach since it is already broken out into the shared driver space because it can apply to at least 3 architectures (ARM, AArch64, MicroBlaze). I suggest you avoid making that repo a submodule of anything. The code in that repo is "over the wall" and there is no continuity. I have it as a submodule in my XRT repo and a Xilinx push of the next release of tools broke the code. What I had depended on was removed and moved somewhere else. The Xilinx updates are
Re: Discussion: How to handle HALs, SDKs and libraries
On 2023-05-23 16:11, Kinsey Moore wrote: On Tue, May 23, 2023 at 2:26 AM Christian MAUDERER <mailto:christian.maude...@embedded-brains.de>> wrote: Hello, I recently updated the HAL in the i.MXRT BSP. I used the same approach that we use for a lot of similar cases: Import the sources into RTEMS and adapt them slightly so that they work for us. So basically a Clone-and-Own approach. During the discussion of the patches, some concerns were raised, whether we should find a better solution to handle HALs, SDKs and similar cases. We should start discussing a solution that can be used after the 6 release so that maybe someone can start to work on a prototype. Some example cases are: - the mcux_sdk in the imxrt BSP - the hal in the stm32h7 BSP - general ARM CMSIS files - zlib - libfdt One solution could be to build these libraries external and only link RTEMS with them. There are disadvantages to this aproach: - Also in my experience, the API of the HALs / SDKs / libraries seems to be quite stable, it's possible that there are combinations where some unexpected change breaks a driver or makes it impossible to link the applications. - BSPs rely on basic drivers from these libraries (like console or clock driver). If we link against the libraries, the testsuite wouldn't build any more without preinstalled libraries. Another solution could be to include libraties like that as submodules and build them using the RTEMS build system. We could clone the repos onto the RTEMS git server, and add necessary patches. Advantage would be that it is more similar to the process that we currently have. Another advantage is that we have a known-working version of the files. Upstream updates could be either merged or we could rebase our patches to a new version. From my point of view, the second option would be the better one especially because we have a tested, fixed version of the library instead telling the user to just use some random version that might or might not work. Regardless which aproach we use: We have to think about how to handle that on releases. In the link aproach (first case), we have to somehow archive source tar balls and some kind of build recipe. In the submodule aproach, we could checkout all submodules and pack the files into the RTEMS release tar ball. So I would expect that the second aproach has less impact here too. Comments? Improvements? Better suggestions? I would definitely prefer the submodule approach over the linking approach to avoid the test issues since some of these HALs bring core functionality. The Xilinx driver framework (embeddedsw repo on Github) would be well-suited to the submodule approach since it is already broken out into the shared driver space because it can apply to at least 3 architectures (ARM, AArch64, MicroBlaze). One issue with either approach is the need to modify the HAL source to suit RTEMS. As far as I'm aware, there is no tooling in place in git for applying patches to submodules and in the external build scenario we'd end up maintaining a branch of the origin repo with patches applied. Upstreaming the changes would be ideal, but I wouldn't expect them to accept RTEMS-specific patches. The Xilinx NAND driver already requires a minor modification because that driver doesn't expose an option and instead has a defined macro that determines how many chip selects are usable to address different parts of the NAND chip. Technically, this particular change could be worked around with some include path trickery to leave the original sources unmodified, but many other changes would not be suited by that type of workaround and it makes the source less maintainable. We would need to come up with our own tooling for submodule patch application and silencing of warnings about dirty submodule trees due to applied patches. Kinsey I would suggest that we maintain a branch on the git.rtems.org if adaptions are necessary and patches can't be upstreamed. We can either merge upstream changes or rebase that branch onto the latest upstream if we update. I think that is more intuitive and robust compared to a tool that applies RTEMS specific patches after cloning the submodule. Best regards Christian -- embedded brains GmbH & Co. KG Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 mobile: +49-176-152 206 08 Registergericht: Amtsgericht München Registernummer: HRA 117265 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list de
Re: [PATCH rtems-libbsd] ipsec-tools: Fix copying fd_set prior to select
Hello Chris,
On 2023-05-23 08:53, Chris Johns wrote:
On 23/5/2023 4:25 pm, Christian MAUDERER wrote:
Hello Chris,
On 2023-05-23 03:36, Chris Johns wrote:
Hi,
I have been resolving this by adding:
#define preset_mask *preset_mask_prealloc
#define active_mask *active_mask_prealloc
as the assignment logic works as is. It does not catch FD_ZERO which is a shame
but is helps avoid us adding a special case.
Thanks for the suggestion. I used that solution already in the file during the
initial port. But it doesn't work in this case (and maybe we should check other
cases in libbsd too). It only copies the first element of the array of fd_sets.
The variables / defines are (in the patched version - see [1]):
static fd_set *allocated_preset_mask, *allocated_active_mask;
static struct fd_monitor *allocated_fd_monitors;
#define preset_mask (*allocated_preset_mask)
#define active_mask (*allocated_active_mask)
#define fd_monitors (allocated_fd_monitors)
They are allocated as follows (see [2]):
allocated_preset_mask = calloc(sizeof(fd_set),
howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
allocated_active_mask = calloc(sizeof(fd_set),
howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
allocated_fd_monitors = calloc(
rtems_libio_number_iops, sizeof(struct fd_monitor));
So basically it's a bunch of arrays of fd_sets. If I now use the following
(unpatched) assignment:
active_mask = preset_mask;
After the preprocessor the line will be
(*allocated_active_mask) = (*allocated_preset_mask);
Which copies only the first element. That's why I had to add the memcpy. Did I
miss some better solution?
I am using this in ntpd which I checked yesterday:
#ifdef __rtems__
#include
static size_t rtems_ntpd_fds_size;
static int rtems_fd_set_alloc(fd_set **setp) {
if (*setp == NULL) {
rtems_ntpd_fds_size = sizeof(fd_set) *
(howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
*setp = malloc(rtems_ntpd_fds_size);
if (*setp == NULL) {
errno = ENOMEM;
return -1;
}
memset(*setp, 0, rtems_ntpd_fds_size);
}
return 0;
}
#define activefds (*activefds_prealloc)
static fd_set *activefds_prealloc;
#define rtems_activefds_alloc() rtems_fd_set_alloc(_prealloc)
#else /* __rtems__ */
static fd_set activefds;
#endif /* __rtems__ */
and:
#if __rtems__
#define rdfdes (*rdfdes_prealloc)
static fd_set *rdfdes_prealloc;
#else /* __rtems__ */
fd_set rdfdes;
#endif /* __rtems__ */
int nfound;
#if __rtems__
if (rtems_fd_set_alloc(_prealloc) < 0) {
return;
}
memset(rdfdes_prealloc, 0, rtems_ntpd_fds_size);
#else /* __rtems__ */
FD_ZERO();
#endif /* __rtems__ */
with:
++handler_calls;
rdfdes = activefds;
But isn't that line resolving to
(*rdfdes_prealloc) = (*activefds_prealloc);
That would also copy only the first element.
Stepping:
Thread 9 hit Breakpoint 1, _ntp_io_handler () at
../../bsd/freebsd/contrib/ntp/ntpd/ntp_io.c:3727
3727rdfdes = activefds;
(gdb) x /8bx activefds_prealloc
0x1083e650: 0x200x440x050x200x000x400x000x00
(gdb) x /8bx rdfdes_prealloc
0x108353a0: 0x000x000x000x000x000x000x000x00
(gdb) n
3736t1.tv_usec = 0;
(gdb) x /8bx rdfdes_prealloc
0x108353a0: 0x200x440x050x200x000x400x000x00
Looks ok to me.
fd_set is 64 bit wide. So a copy of the first 64 bit works. Does it
still work if you have 256 files in the system?
Best regards
Christian
Chris
--
embedded brains GmbH & Co. KG
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
mobile: +49-176-152 206 08
Registergericht: Amtsgericht München
Registernummer: HRA 117265
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
Discussion: How to handle HALs, SDKs and libraries
Hello, I recently updated the HAL in the i.MXRT BSP. I used the same approach that we use for a lot of similar cases: Import the sources into RTEMS and adapt them slightly so that they work for us. So basically a Clone-and-Own approach. During the discussion of the patches, some concerns were raised, whether we should find a better solution to handle HALs, SDKs and similar cases. We should start discussing a solution that can be used after the 6 release so that maybe someone can start to work on a prototype. Some example cases are: - the mcux_sdk in the imxrt BSP - the hal in the stm32h7 BSP - general ARM CMSIS files - zlib - libfdt One solution could be to build these libraries external and only link RTEMS with them. There are disadvantages to this aproach: - Also in my experience, the API of the HALs / SDKs / libraries seems to be quite stable, it's possible that there are combinations where some unexpected change breaks a driver or makes it impossible to link the applications. - BSPs rely on basic drivers from these libraries (like console or clock driver). If we link against the libraries, the testsuite wouldn't build any more without preinstalled libraries. Another solution could be to include libraties like that as submodules and build them using the RTEMS build system. We could clone the repos onto the RTEMS git server, and add necessary patches. Advantage would be that it is more similar to the process that we currently have. Another advantage is that we have a known-working version of the files. Upstream updates could be either merged or we could rebase our patches to a new version. From my point of view, the second option would be the better one especially because we have a tested, fixed version of the library instead telling the user to just use some random version that might or might not work. Regardless which aproach we use: We have to think about how to handle that on releases. In the link aproach (first case), we have to somehow archive source tar balls and some kind of build recipe. In the submodule aproach, we could checkout all submodules and pack the files into the RTEMS release tar ball. So I would expect that the second aproach has less impact here too. Comments? Improvements? Better suggestions? Best regards Christian -- embedded brains GmbH & Co. KG Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 mobile: +49-176-152 206 08 Registergericht: Amtsgericht München Registernummer: HRA 117265 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 rtems-libbsd] ipsec-tools: Fix copying fd_set prior to select
Hello Chris,
On 2023-05-23 03:36, Chris Johns wrote:
Hi,
I have been resolving this by adding:
#define preset_mask *preset_mask_prealloc
#define active_mask *active_mask_prealloc
as the assignment logic works as is. It does not catch FD_ZERO which is a shame
but is helps avoid us adding a special case.
Thanks for the suggestion. I used that solution already in the file
during the initial port. But it doesn't work in this case (and maybe we
should check other cases in libbsd too). It only copies the first
element of the array of fd_sets.
The variables / defines are (in the patched version - see [1]):
static fd_set *allocated_preset_mask, *allocated_active_mask;
static struct fd_monitor *allocated_fd_monitors;
#define preset_mask (*allocated_preset_mask)
#define active_mask (*allocated_active_mask)
#define fd_monitors (allocated_fd_monitors)
They are allocated as follows (see [2]):
allocated_preset_mask = calloc(sizeof(fd_set),
howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
allocated_active_mask = calloc(sizeof(fd_set),
howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
allocated_fd_monitors = calloc(
rtems_libio_number_iops, sizeof(struct fd_monitor));
So basically it's a bunch of arrays of fd_sets. If I now use the
following (unpatched) assignment:
active_mask = preset_mask;
After the preprocessor the line will be
(*allocated_active_mask) = (*allocated_preset_mask);
Which copies only the first element. That's why I had to add the memcpy.
Did I miss some better solution?
Best regards
Christian
[1]
https://git.rtems.org/rtems-libbsd/tree/ipsec-tools/src/racoon/session.c?id=16be3a7c7d3141018c48d5131a3069184cd3937a#n136
[2]
https://git.rtems.org/rtems-libbsd/tree/ipsec-tools/src/racoon/session.c?id=16be3a7c7d3141018c48d5131a3069184cd3937a#n218
Chris
On 22/5/2023 5:36 pm, Christian Mauderer wrote:
The racoon session code copies an fd_set from one variable into another
prior to calling select. That works well for simple structures.
In libbsd we have to allocate fd_sets instead of using fixed structures
to avoid a problem with file numbers bigger than FD_SETSIZE. The simple
assignment didn't work in that case.
This patch makes sure that a memcpy is used instead.
---
ipsec-tools/src/racoon/session.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/ipsec-tools/src/racoon/session.c b/ipsec-tools/src/racoon/session.c
index 7ea857ba..bd2bd316 100644
--- a/ipsec-tools/src/racoon/session.c
+++ b/ipsec-tools/src/racoon/session.c
@@ -215,6 +215,8 @@ session(void)
#ifndef __rtems__
FD_ZERO(_mask);
#else /* __rtems__ */
+ size_t allocated_mask_size = sizeof(fd_set) *
+ howmany(rtems_libio_number_iops, sizeof(fd_set) * 8);
allocated_preset_mask = calloc(sizeof(fd_set),
howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
if (allocated_preset_mask == NULL)
@@ -352,7 +354,12 @@ session(void)
/* schedular can change select() mask, so we reset
* the working copy here */
+#ifndef __rtems__
active_mask = preset_mask;
+#else /* __rtems__ */
+ memcpy(allocated_active_mask, allocated_preset_mask,
+ allocated_mask_size);
+#endif /* __rtems__ */
error = select(nfds + 1, _mask, NULL, NULL, timeout);
if (error < 0) {
--
embedded brains GmbH & Co. KG
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
mobile: +49-176-152 206 08
Registergericht: Amtsgericht München
Registernummer: HRA 117265
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 rtems v2 00/12] bsp/imxrt: Update SDK and prepare for new variant
Thanks. I pushed the patches. I'll start a discussion regarding the HALs soon. On 2023-05-15 15:53, Gedare Bloom wrote: I'm fine with the v2 now, thanks for reducing it. Do feel free to start a separate discussion / ticket about how we should handle HALs. I think this problem will only get worse not better. On Tue, May 9, 2023 at 6:11 AM Christian Mauderer wrote: Hello, this is the second version of the patch set to update the SDK files in the i.MXRT BSPs. Like said in the earlier version: I plan to add a i.MXRT1166 based BSP soon. The changes are: - I now only imported the SDK files for i.MXRT1050 and i.MXRT1166. With that the imported files (mainly first patch) are now only 18MB instead of 90MB. - The script to import the files is now removed. I added a link to it in the description of the import patch. I'll create a short note for the documentation soon. - I added some minor fixes that I noted during further tests. The full version of the two big patches (1 and 3) can be found on this branch: https://gitlab.com/c-mauderer/rtems/-/commits/cm/20230509_imxrt/ Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- embedded brains GmbH & Co. KG Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 mobile: +49-176-152 206 08 Registergericht: Amtsgericht München Registernummer: HRA 117265 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 rtems-libbsd] ipsec-tools: Fix copying fd_set prior to select
Hello,
I would like to apply this patch on 5 and 6 branches. I'll create
tickets before applying it.
Best regards
Christian
On 2023-05-22 09:36, Christian Mauderer wrote:
The racoon session code copies an fd_set from one variable into another
prior to calling select. That works well for simple structures.
In libbsd we have to allocate fd_sets instead of using fixed structures
to avoid a problem with file numbers bigger than FD_SETSIZE. The simple
assignment didn't work in that case.
This patch makes sure that a memcpy is used instead.
---
ipsec-tools/src/racoon/session.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/ipsec-tools/src/racoon/session.c b/ipsec-tools/src/racoon/session.c
index 7ea857ba..bd2bd316 100644
--- a/ipsec-tools/src/racoon/session.c
+++ b/ipsec-tools/src/racoon/session.c
@@ -215,6 +215,8 @@ session(void)
#ifndef __rtems__
FD_ZERO(_mask);
#else /* __rtems__ */
+ size_t allocated_mask_size = sizeof(fd_set) *
+ howmany(rtems_libio_number_iops, sizeof(fd_set) * 8);
allocated_preset_mask = calloc(sizeof(fd_set),
howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
if (allocated_preset_mask == NULL)
@@ -352,7 +354,12 @@ session(void)
/* schedular can change select() mask, so we reset
* the working copy here */
+#ifndef __rtems__
active_mask = preset_mask;
+#else /* __rtems__ */
+ memcpy(allocated_active_mask, allocated_preset_mask,
+ allocated_mask_size);
+#endif /* __rtems__ */
error = select(nfds + 1, _mask, NULL, NULL, timeout);
if (error < 0) {
--
embedded brains GmbH & Co. KG
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
mobile: +49-176-152 206 08
Registergericht: Amtsgericht München
Registernummer: HRA 117265
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
[PATCH rtems-libbsd] ipsec-tools: Fix copying fd_set prior to select
The racoon session code copies an fd_set from one variable into another
prior to calling select. That works well for simple structures.
In libbsd we have to allocate fd_sets instead of using fixed structures
to avoid a problem with file numbers bigger than FD_SETSIZE. The simple
assignment didn't work in that case.
This patch makes sure that a memcpy is used instead.
---
ipsec-tools/src/racoon/session.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/ipsec-tools/src/racoon/session.c b/ipsec-tools/src/racoon/session.c
index 7ea857ba..bd2bd316 100644
--- a/ipsec-tools/src/racoon/session.c
+++ b/ipsec-tools/src/racoon/session.c
@@ -215,6 +215,8 @@ session(void)
#ifndef __rtems__
FD_ZERO(_mask);
#else /* __rtems__ */
+ size_t allocated_mask_size = sizeof(fd_set) *
+ howmany(rtems_libio_number_iops, sizeof(fd_set) * 8);
allocated_preset_mask = calloc(sizeof(fd_set),
howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
if (allocated_preset_mask == NULL)
@@ -352,7 +354,12 @@ session(void)
/* schedular can change select() mask, so we reset
* the working copy here */
+#ifndef __rtems__
active_mask = preset_mask;
+#else /* __rtems__ */
+ memcpy(allocated_active_mask, allocated_preset_mask,
+ allocated_mask_size);
+#endif /* __rtems__ */
error = select(nfds + 1, _mask, NULL, NULL, timeout);
if (error < 0) {
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems v2 01/12] bsp/imxrt: Update support library from mcux-sdk
This imports new files from the mcux-sdk support library. NXP now offers the library as a git repository instead of a zip package. The git repository supports multiple CPUs from the i.MXRT family: https://github.com/nxp-mcuxpresso/mcux-sdk.git The imported files are from revision 2b9354539e6e4f722749e87b0bdc22966dc080d9 This revision is the same as MCUXpresso 2.13.0 with small bug fixes. For importing the files, a script has been used, that parses the mcux-sdk cmake files and creates the yaml files for RTEMS: https://raw.githubusercontent.com/c-mauderer/nxp-mcux-sdk/d21c3e61eb8602b2cf8f45fed0afa50c6aee932f/export_to_RTEMS.py NOTE: Due to the size, this is only the summary of the patch. You can find the full version here: https://gitlab.com/c-mauderer/rtems/-/commit/db46669083517749fea88b3440dbfc71adf6347c --- .../mcux-sdk/devices/MIMXRT1052/MIMXRT1052.h | 53558 + .../devices/MIMXRT1052/MIMXRT1052_features.h | 785 + .../devices/MIMXRT1052/drivers/fsl_clock.c| 1535 + .../devices/MIMXRT1052/drivers/fsl_clock.h| 2038 + .../MIMXRT1052/drivers/fsl_flexram_allocate.c |86 + .../MIMXRT1052/drivers/fsl_flexram_allocate.h |87 + .../devices/MIMXRT1052/drivers/fsl_iomuxc.h | 1241 + .../devices/MIMXRT1052/drivers/fsl_nic301.h | 308 + .../devices/MIMXRT1052/drivers/fsl_romapi.c | 162 + .../devices/MIMXRT1052/drivers/fsl_romapi.h | 565 + .../devices/MIMXRT1052/fsl_device_registers.h |36 + .../MIMXRT1052/gcc/startup_MIMXRT1052.S | 1077 + .../devices/MIMXRT1052/system_MIMXRT1052.c| 242 + .../devices/MIMXRT1052/system_MIMXRT1052.h| 131 + .../MIMXRT1052/xip/fsl_flexspi_nor_boot.c |49 + .../MIMXRT1052/xip/fsl_flexspi_nor_boot.h | 124 + .../devices/MIMXRT1166/MIMXRT1166_cm4.h | 93964 .../MIMXRT1166/MIMXRT1166_cm4_features.h | 903 + .../devices/MIMXRT1166/MIMXRT1166_cm7.h | 93031 +++ .../MIMXRT1166/MIMXRT1166_cm7_features.h | 890 + .../MIMXRT1166/drivers/cm4/fsl_cache.c| 507 + .../MIMXRT1166/drivers/cm4/fsl_cache.h| 340 + .../MIMXRT1166/drivers/cm7/fsl_cache.c| 602 + .../MIMXRT1166/drivers/cm7/fsl_cache.h| 463 + .../MIMXRT1166/drivers/fsl_anatop_ai.c| 357 + .../MIMXRT1166/drivers/fsl_anatop_ai.h| 533 + .../devices/MIMXRT1166/drivers/fsl_clock.c| 1929 + .../devices/MIMXRT1166/drivers/fsl_clock.h| 3308 + .../devices/MIMXRT1166/drivers/fsl_dcdc.c | 518 + .../devices/MIMXRT1166/drivers/fsl_dcdc.h | 1013 + .../MIMXRT1166/drivers/fsl_flexram_allocate.c |92 + .../MIMXRT1166/drivers/fsl_flexram_allocate.h |87 + .../devices/MIMXRT1166/drivers/fsl_gpc.c | 335 + .../devices/MIMXRT1166/drivers/fsl_gpc.h | 651 + .../devices/MIMXRT1166/drivers/fsl_iomuxc.h | 1770 + .../devices/MIMXRT1166/drivers/fsl_memory.h |89 + .../devices/MIMXRT1166/drivers/fsl_nic301.h | 293 + .../devices/MIMXRT1166/drivers/fsl_pgmc.c | 461 + .../devices/MIMXRT1166/drivers/fsl_pgmc.h | 783 + .../devices/MIMXRT1166/drivers/fsl_pmu.c | 959 + .../devices/MIMXRT1166/drivers/fsl_pmu.h | 855 + .../devices/MIMXRT1166/drivers/fsl_romapi.c | 250 + .../devices/MIMXRT1166/drivers/fsl_romapi.h | 724 + .../MIMXRT1166/drivers/fsl_soc_mipi_csi2rx.c |71 + .../MIMXRT1166/drivers/fsl_soc_mipi_csi2rx.h |66 + .../devices/MIMXRT1166/drivers/fsl_soc_src.c | 183 + .../devices/MIMXRT1166/drivers/fsl_soc_src.h | 754 + .../devices/MIMXRT1166/fsl_device_registers.h |44 + .../MIMXRT1166/gcc/startup_MIMXRT1166_cm4.S | 1421 + .../MIMXRT1166/gcc/startup_MIMXRT1166_cm7.S | 1421 + .../MIMXRT1166/system_MIMXRT1166_cm4.c| 176 + .../MIMXRT1166/system_MIMXRT1166_cm4.h| 118 + .../MIMXRT1166/system_MIMXRT1166_cm7.c| 159 + .../MIMXRT1166/system_MIMXRT1166_cm7.h| 118 + .../MIMXRT1166/xip/fsl_flexspi_nor_boot.c |49 + .../MIMXRT1166/xip/fsl_flexspi_nor_boot.h | 149 + .../imxrt/mcux-sdk/drivers/acmp/fsl_acmp.c| 662 + .../imxrt/mcux-sdk/drivers/acmp/fsl_acmp.h| 536 + .../drivers/adc_12b1msps_sar/fsl_adc.c| 395 + .../drivers/adc_12b1msps_sar/fsl_adc.h| 427 + .../mcux-sdk/drivers/adc_etc/fsl_adc_etc.c| 464 + .../mcux-sdk/drivers/adc_etc/fsl_adc_etc.h| 352 + bsps/arm/imxrt/mcux-sdk/drivers/aoi/fsl_aoi.c | 214 + bsps/arm/imxrt/mcux-sdk/drivers/aoi/fsl_aoi.h | 186 + .../imxrt/mcux-sdk/drivers/asrc/fsl_asrc.c| 1031 + .../imxrt/mcux-sdk/drivers/asrc/fsl_asrc.h| 761 + .../mcux-sdk/drivers/asrc/fsl_asrc_edma.c | 470 + .../mcux-sdk/drivers/asrc/fsl_asrc_edma.h | 245 + bsps/arm/imxrt/mcux-sdk/drivers/bee/fsl_bee.c | 303 + bsps/arm/imxrt/mcux-sdk/drivers/bee/fsl_bee.h | 254 + .../drivers/cache/armv7-m7/fsl_cache.c| 602 + .../drivers/cache/armv7-m7/fsl_cache.h| 463 +
[PATCH rtems v2 02/12] bsps/imxrt: (Re-)Apply RTEMS patches to new lib
Reapply patches used in the old version of the NXP library and apply
patches necessary for the new version of the library.
---
.../devices/MIMXRT1052/fsl_device_registers.h | 3 +
.../MIMXRT1052/xip/fsl_flexspi_nor_boot.h | 4 +
.../devices/MIMXRT1166/fsl_device_registers.h | 3 +
.../MIMXRT1166/xip/fsl_flexspi_nor_boot.h | 4 +
.../mcux-sdk/drivers/common/fsl_common.h | 310 ++
.../mcux-sdk/drivers/lpuart/fsl_lpuart.c | 17 +
.../mcux-sdk/drivers/lpuart/fsl_lpuart.h | 4 +
.../imxrt/mcux-sdk/drivers/qtmr_1/fsl_qtmr.c | 40 +++
.../imxrt/mcux-sdk/drivers/qtmr_1/fsl_qtmr.h | 34 ++
9 files changed, 419 insertions(+)
diff --git a/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1052/fsl_device_registers.h
b/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1052/fsl_device_registers.h
index 54caf43ca6..35e988f1b3 100644
--- a/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1052/fsl_device_registers.h
+++ b/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1052/fsl_device_registers.h
@@ -10,6 +10,9 @@
#ifndef __FSL_DEVICE_REGISTERS_H__
#define __FSL_DEVICE_REGISTERS_H__
+#ifdef __rtems__
+#include
+#endif /* __rtems__ */
/*
* Include the cpu specific register header files.
*
diff --git
a/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1052/xip/fsl_flexspi_nor_boot.h
b/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1052/xip/fsl_flexspi_nor_boot.h
index 38d5d1833e..5f81090890 100644
--- a/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1052/xip/fsl_flexspi_nor_boot.h
+++ b/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1052/xip/fsl_flexspi_nor_boot.h
@@ -10,9 +10,11 @@
#include
#include "fsl_common.h"
+#ifndef __rtems__
#ifndef BOARD_FLASH_SIZE
#include "board.h"
#endif
+#endif /* __rtems__ */
/*! @name Driver version */
/*@{*/
@@ -108,11 +110,13 @@ typedef struct _boot_data_
#define FLASH_BASE FlexSPI_AMBA_BASE
#endif
+#ifndef __rtems__
#if defined(BOARD_FLASH_SIZE)
#define FLASH_SIZE BOARD_FLASH_SIZE
#else
#error "Please define macro BOARD_FLASH_SIZE"
#endif
+#endif /* __rtems__ */
#define PLUGIN_FLAG (uint32_t)0
/* External Variables */
diff --git a/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1166/fsl_device_registers.h
b/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1166/fsl_device_registers.h
index a2a9ae8c82..4508d6634f 100644
--- a/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1166/fsl_device_registers.h
+++ b/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1166/fsl_device_registers.h
@@ -10,6 +10,9 @@
#ifndef __FSL_DEVICE_REGISTERS_H__
#define __FSL_DEVICE_REGISTERS_H__
+#ifdef __rtems__
+#include
+#endif /* __rtems__ */
/*
* Include the cpu specific register header files.
*
diff --git
a/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1166/xip/fsl_flexspi_nor_boot.h
b/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1166/xip/fsl_flexspi_nor_boot.h
index 6aeb096486..16c0c0a6be 100644
--- a/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1166/xip/fsl_flexspi_nor_boot.h
+++ b/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1166/xip/fsl_flexspi_nor_boot.h
@@ -10,9 +10,11 @@
#include
#include "fsl_common.h"
+#ifndef __rtems__
#ifndef BOARD_FLASH_SIZE
#include "board.h"
#endif
+#endif /* __rtems__ */
/*! @name Driver version */
/*@{*/
@@ -133,11 +135,13 @@ typedef struct _boot_data_
#define FLASH_BASE FlexSPI1_ALIAS_BASE
#endif
+#ifndef __rtems__
#if defined(BOARD_FLASH_SIZE)
#define FLASH_SIZE BOARD_FLASH_SIZE
#else
#error "Please define macro BOARD_FLASH_SIZE"
#endif
+#endif /* __rtems__ */
#define PLUGIN_FLAG (uint32_t)0
/* External Variables */
diff --git a/bsps/arm/imxrt/mcux-sdk/drivers/common/fsl_common.h
b/bsps/arm/imxrt/mcux-sdk/drivers/common/fsl_common.h
index 84c7f9d2f0..17eaadb84d 100644
--- a/bsps/arm/imxrt/mcux-sdk/drivers/common/fsl_common.h
+++ b/bsps/arm/imxrt/mcux-sdk/drivers/common/fsl_common.h
@@ -21,6 +21,10 @@
#include "fsl_device_registers.h"
+#ifdef __rtems__
+/* Usually provided by modern CMSIS */
+#define __STATIC_FORCEINLINE __attribute__((always_inline)) static inline
+#endif /* __rtems__ */
/*!
* @addtogroup ksdk_common
* @{
@@ -314,6 +318,312 @@ void SDK_Free(void *ptr);
*/
void SDK_DelayAtLeastUs(uint32_t delayTime_us, uint32_t coreClock_Hz);
+#ifdef __rtems__
+/* Prototypes for IRQHandlers */
+void ADMA_FLEXCAN0_INT_DriverIRQHandler(void);
+void ADMA_FLEXCAN1_INT_DriverIRQHandler(void);
+void ADMA_FLEXCAN2_INT_DriverIRQHandler(void);
+void ADMA_I2C0_INT_DriverIRQHandler(void);
+void ADMA_I2C1_INT_DriverIRQHandler(void);
+void ADMA_I2C2_INT_DriverIRQHandler(void);
+void ADMA_I2C3_INT_DriverIRQHandler(void);
+void ADMA_I2C4_INT_DriverIRQHandler(void);
+void ADMA_SAI0_INT_DriverIRQHandler(void);
+void ADMA_SAI1_INT_DriverIRQHandler(void);
+void ADMA_SAI2_INT_DriverIRQHandler(void);
+void ADMA_SAI3_INT_DriverIRQHandler(void);
+void ADMA_SAI4_INT_DriverIRQHandler(void);
+void ADMA_SAI5_INT_DriverIRQHandler(void);
+void ADMA_SPI0_INT_DriverIRQHandler(void);
+void ADMA_SPI1_INT_DriverIRQHandler(void);
+void ADMA_SPI2_INT_DriverIRQHandler(void);
+void ADMA_SPI3_INT_DriverIRQHandler(void);
[PATCH rtems v2 12/12] imx_iomux: Don't set reserved bits in PAD_CTL
On most i.MX* the upper bits in SW_PAD_CTL are reserved. On some chips,
like the i.MXRT1166, they are a domain write protection. Setting them to
1 can have unexpected side effects.
The device tree uses these bits for some flags. Make sure that they are
not accidentally written to some value.
---
bsps/arm/shared/pins/imx_iomux.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/bsps/arm/shared/pins/imx_iomux.c b/bsps/arm/shared/pins/imx_iomux.c
index 1ff4186360..e6c604481a 100644
--- a/bsps/arm/shared/pins/imx_iomux.c
+++ b/bsps/arm/shared/pins/imx_iomux.c
@@ -307,7 +307,17 @@ int imx_iomux_configure_pins(const void *fdt, uint32_t
cfgxref)
WR4(sc, cfg->mux_reg, cfg->mux_val | sion);
iomux_configure_input(sc, cfg->input_reg, cfg->input_val);
if ((cfg->padconf_val & PADCONF_NONE) == 0)
+#ifndef __rtems__
WR4(sc, cfg->padconf_reg, cfg->padconf_val);
+#else /* __rtems__ */
+ /*
+* Need to mask the flags. On (for example) i.MXRT1166
+* they are used for domain write protection. On other
+* i.MX* these are Reserved.
+*/
+ WR4(sc, cfg->padconf_reg, cfg->padconf_val
+ & ~(PADCONF_SION | PADCONF_NONE));
+#endif /* __rtems__ */
#ifndef __rtems__
if (bootverbose) {
char name[32];
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems v2 05/12] bsps/imxrt: Get clock for IMXRT11xx in drivers
The mcux_sdk has a different interface for getting the clock for
IMXRT11xx than for getting it in IMXRT10xx. Adapt simple drivers to
support that interface.
---
bsps/arm/imxrt/console/console.c | 35 +--
bsps/arm/imxrt/i2c/imxrt-lpi2c.c | 18 --
.../imxrt/mcux-sdk/drivers/qtmr_1/fsl_qtmr.c | 8 +
bsps/arm/imxrt/spi/imxrt-lpspi.c | 18 --
4 files changed, 73 insertions(+), 6 deletions(-)
diff --git a/bsps/arm/imxrt/console/console.c b/bsps/arm/imxrt/console/console.c
index 05320f2c4c..e3f6a091c6 100644
--- a/bsps/arm/imxrt/console/console.c
+++ b/bsps/arm/imxrt/console/console.c
@@ -53,6 +53,7 @@ typedef struct {
volatile LPUART_Type *regs;
rtems_vector_number irq;
const char *path;
+ clock_ip_name_t clock_ip;
uint32_t src_clock_hz;
lpuart_config_t config;
} imxrt_lpuart_context;
@@ -174,12 +175,15 @@ static bool imxrt_lpuart_set_attributes(
return true;
}
-static uint32_t imxrt_lpuart_get_src_freq(void)
+static uint32_t imxrt_lpuart_get_src_freq(clock_ip_name_t clock_ip)
{
uint32_t freq;
+#if IMXRT_IS_MIMXRT10xx
uint32_t mux;
uint32_t divider;
+ (void) clock_ip; /* Not necessary for i.MXRT1050 */
+
mux = CLOCK_GetMux(kCLOCK_UartMux);
divider = 1;
@@ -197,10 +201,36 @@ static uint32_t imxrt_lpuart_get_src_freq(void)
divider *= CLOCK_GetDiv(kCLOCK_UartDiv) + 1U;
freq /= divider;
+#elif IMXRT_IS_MIMXRT11xx
+ /*
+ * FIXME: A future version of the mcux_sdk might provide a better method to
+ * get the clock instead of this hack.
+ */
+ clock_root_t clock_root = clock_ip + kCLOCK_Root_Lpuart1 - kCLOCK_Lpuart1;
+
+ freq = CLOCK_GetRootClockFreq(clock_root);
+#else
+ #error Getting UART clock frequency is not implemented for this chip
+#endif
return freq;
}
+static clock_ip_name_t imxrt_lpuart_clock_ip(volatile LPUART_Type *regs)
+{
+ LPUART_Type *const base_addresses[] = LPUART_BASE_PTRS;
+ static const clock_ip_name_t lpuart_clocks[] = LPUART_CLOCKS;
+ size_t i;
+
+ for (i = 0; i < RTEMS_ARRAY_SIZE(base_addresses); ++i) {
+if (base_addresses[i] == regs) {
+ return lpuart_clocks[i];
+}
+ }
+
+ return kCLOCK_IpInvalid;
+}
+
static void imxrt_lpuart_init_hardware(imxrt_lpuart_context *ctx)
{
(void) LPUART_Init((LPUART_Type *)ctx->regs, >config,
@@ -378,7 +408,8 @@ static void imxrt_lpuart_init_context_from_fdt(
bsp_fatal(IMXRT_FATAL_LPI2C_INVALID_FDT);
}
- ctx->src_clock_hz = imxrt_lpuart_get_src_freq();
+ ctx->clock_ip = imxrt_lpuart_clock_ip(ctx->regs);
+ ctx->src_clock_hz = imxrt_lpuart_get_src_freq(ctx->clock_ip);
LPUART_GetDefaultConfig(>config);
ctx->config.enableTx = true;
diff --git a/bsps/arm/imxrt/i2c/imxrt-lpi2c.c b/bsps/arm/imxrt/i2c/imxrt-lpi2c.c
index 783c6e18e6..d3aebc45e0 100644
--- a/bsps/arm/imxrt/i2c/imxrt-lpi2c.c
+++ b/bsps/arm/imxrt/i2c/imxrt-lpi2c.c
@@ -373,12 +373,15 @@ static int imxrt_lpi2c_hw_init(struct imxrt_lpi2c_bus
*bus)
return 0;
}
-static uint32_t imxrt_lpi2c_get_src_freq(void)
+static uint32_t imxrt_lpi2c_get_src_freq(clock_ip_name_t clock_ip)
{
uint32_t freq;
+#if IMXRT_IS_MIMXRT10xx
uint32_t mux;
uint32_t divider;
+ (void) clock_ip; /* Not necessary for i.MXRT1050 */
+
mux = CLOCK_GetMux(kCLOCK_Lpi2cMux);
divider = 1;
@@ -396,6 +399,17 @@ static uint32_t imxrt_lpi2c_get_src_freq(void)
divider *= CLOCK_GetDiv(kCLOCK_Lpi2cDiv) + 1;
freq /= divider;
+#elif IMXRT_IS_MIMXRT11xx
+ /*
+ * FIXME: A future version of the mcux_sdk might provide a better method to
+ * get the clock instead of this hack.
+ */
+ clock_root_t clock_root = clock_ip + kCLOCK_Root_Lpi2c1 - kCLOCK_Lpi2c1;
+
+ freq = CLOCK_GetRootClockFreq(clock_root);
+#else
+ #error Getting I2C frequency is not implemented for this chip.
+#endif
return freq;
}
@@ -457,7 +471,7 @@ void imxrt_lpi2c_init(void)
}
bus->clock_ip = imxrt_lpi2c_clock_ip(bus->regs);
- bus->src_clock_hz = imxrt_lpi2c_get_src_freq();
+ bus->src_clock_hz = imxrt_lpi2c_get_src_freq(bus->clock_ip);
eno = imxrt_lpi2c_hw_init(bus);
if (eno != 0) {
diff --git a/bsps/arm/imxrt/mcux-sdk/drivers/qtmr_1/fsl_qtmr.c
b/bsps/arm/imxrt/mcux-sdk/drivers/qtmr_1/fsl_qtmr.c
index a4e393896b..4c8bd71be5 100644
--- a/bsps/arm/imxrt/mcux-sdk/drivers/qtmr_1/fsl_qtmr.c
+++ b/bsps/arm/imxrt/mcux-sdk/drivers/qtmr_1/fsl_qtmr.c
@@ -92,9 +92,17 @@ rtems_vector_number QTMR_get_IRQ_from_fdt(const void *fdt,
int node)
uint32_t QTMR_get_src_clk(TMR_Type *base)
{
+#if IMXRT_IS_MIMXRT10xx
(void) base;
return CLOCK_GetFreq(kCLOCK_IpgClk);
+#elif IMXRT_IS_MIMXRT11xx
+(void) base;
+
+return CLOCK_GetRootClockMux(kCLOCK_Root_Bus);
+#else
+ #error Getting Timer clock frequency is not implemented for this chip
+#endif
}
#endif /* __rtems__ */
diff --git a/bsps/arm/imxrt/spi/imxrt-lpspi.c b/bsps/arm/imxrt/spi/imxrt-lpspi.c
index 80b47f9663..62503e4bd8 100644
---
[PATCH rtems v2 08/12] bsps/imxrt: Support more chip variants in header
The different variants of the i.MXRT have some minimal differences in
the fsl_flexspi_nor_config.h. Make sure that the header supports the
different chips.
---
.../imxrt/include/fsl_flexspi_nor_config.h| 49 +++
1 file changed, 40 insertions(+), 9 deletions(-)
diff --git a/bsps/arm/imxrt/include/fsl_flexspi_nor_config.h
b/bsps/arm/imxrt/include/fsl_flexspi_nor_config.h
index 4a2a158f50..541eb7e68a 100644
--- a/bsps/arm/imxrt/include/fsl_flexspi_nor_config.h
+++ b/bsps/arm/imxrt/include/fsl_flexspi_nor_config.h
@@ -1,13 +1,14 @@
/*
- * Copyright (c) 2016, Freescale Semiconductor, Inc.
- * Copyright 2016-2017 NXP
+ * Copyright 2017-2020 NXP
* All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
+ *
+ * Based on file for EVKBIMSRT1050 with values for other EVKs integrated.
*/
-#ifndef __EVKBIMXRT1050_FLEXSPI_NOR_CONFIG__
-#define __EVKBIMXRT1050_FLEXSPI_NOR_CONFIG__
+#ifndef __FSL_FLEXSPI_NOR_CONFIG__
+#define __FSL_FLEXSPI_NOR_CONFIG__
#include
#include
@@ -15,8 +16,8 @@
/*! @name Driver version */
/*@{*/
-/*! @brief XIP_BOARD driver version 2.0.0. */
-#define FSL_XIP_BOARD_DRIVER_VERSION (MAKE_VERSION(2, 0, 0))
+/*! @brief XIP_BOARD driver version 2.0.1. */
+#define FSL_XIP_BOARD_DRIVER_VERSION (MAKE_VERSION(2, 0, 1))
/*@}*/
/* FLEXSPI memory config block related defintions */
@@ -82,11 +83,39 @@ typedef enum _FlexSpiSerialClockFreq
kFlexSpiSerialClk_30MHz = 1,
kFlexSpiSerialClk_50MHz = 2,
kFlexSpiSerialClk_60MHz = 3,
+#if defined(MIMXRT1011_SERIES)
+kFlexSpiSerialClk_75MHz = 4,
+kFlexSpiSerialClk_80MHz = 5,
+kFlexSpiSerialClk_100MHz = 6,
+kFlexSpiSerialClk_120MHz = 7,
+kFlexSpiSerialClk_133MHz = 8,
+#elif defined(MIMXRT1015_SERIES) || defined(MIMXRT1021_SERIES) ||
defined(MIMXRT1024_SERIES)
+kFlexSpiSerialClk_75MHz = 4,
+kFlexSpiSerialClk_80MHz = 5,
+kFlexSpiSerialClk_100MHz = 6,
+kFlexSpiSerialClk_133MHz = 7,
+#elif defined(MIMXRT1052_SERIES)
kFlexSpiSerialClk_75MHz = 4,
kFlexSpiSerialClk_80MHz = 5,
kFlexSpiSerialClk_100MHz = 6,
kFlexSpiSerialClk_133MHz = 7,
kFlexSpiSerialClk_166MHz = 8,
+#elif defined(MIMXRT1042_SERIES) || defined(MIMXRT1062_SERIES) ||
defined(MIMXRT1064_SERIES)
+kFlexSpiSerialClk_75MHz = 4,
+kFlexSpiSerialClk_80MHz = 5,
+kFlexSpiSerialClk_100MHz = 6,
+kFlexSpiSerialClk_120MHz = 7,
+kFlexSpiSerialClk_133MHz = 8,
+kFlexSpiSerialClk_166MHz = 9,
+#elif defined(MIMXRT1166_cm4_SERIES) || defined(MIMXRT1166_cm7_SERIES) || \
+ defined(MIMXRT1176_cm4_SERIES) || defined(MIMXRT1176_cm7_SERIES)
+kFlexSpiSerialClk_80MHz = 4,
+kFlexSpiSerialClk_100MHz = 5,
+kFlexSpiSerialClk_120MHz = 6,
+kFlexSpiSerialClk_133MHz = 7,
+kFlexSpiSerialClk_166MHz = 8,
+kFlexSpiSerialClk_200MHz = 9,
+#endif
} flexspi_serial_clk_freq_t;
//!@brief FlexSPI clock configuration type
@@ -249,13 +278,15 @@ typedef struct _flexspi_nor_config
uint32_t sectorSize;//!< Sector size of Serial NOR
uint8_t ipcmdSerialClkFreq; //!< Clock frequency for IP command
uint8_t isUniformBlockSize; //!< Sector/Block size is the same
-uint8_t reserved0[2]; //!< Reserved for future use
+uint8_t isDataOrderSwapped; //!< The data order is swapped in OPI DDR
mode (only i.MXRT11*)
+uint8_t reserved0; //!< Reserved for future use
uint8_t serialNorType; //!< Serial NOR Flash type: 0/1/2/3
uint8_t needExitNoCmdMode; //!< Need to exit NoCmd mode before other
IP command
uint8_t halfClkForNonReadCmd; //!< Half the Serial Clock for non-read
command: true/false
uint8_t needRestoreNoCmdMode; //!< Need to Restore NoCmd mode after IP
commmand execution
uint32_t blockSize; //!< Block size
-uint32_t reserve2[11]; //!< Reserved for future use
+uint32_t FlashStateCtx; //!< Flash State Context after being
configured (only i.MXRT11*)
+uint32_t reserve2[10]; //!< Reserved for future use
} flexspi_nor_config_t;
#ifdef __cplusplus
@@ -265,4 +296,4 @@ extern "C" {
#ifdef __cplusplus
}
#endif
-#endif /* __EVKBIMXRT1050_FLEXSPI_NOR_CONFIG__ */
+#endif /* __FSL_FLEXSPI_NOR_CONFIG__ */
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems v2 07/12] bsps/imxrt: Remove unmaintained defines
The defines for the different clock frequencies in the fsl_clock_config.h do not represent the clock frequencies that have been set up in the registers. Remove them to avoid someone trusting in correct values. --- bsps/arm/imxrt/include/fsl_clock_config.h | 58 +-- .../nxp/boards/evkbimxrt1050/clock_config.c | 2 +- 2 files changed, 4 insertions(+), 56 deletions(-) diff --git a/bsps/arm/imxrt/include/fsl_clock_config.h b/bsps/arm/imxrt/include/fsl_clock_config.h index f213ac7e23..5c09daf59d 100644 --- a/bsps/arm/imxrt/include/fsl_clock_config.h +++ b/bsps/arm/imxrt/include/fsl_clock_config.h @@ -8,6 +8,7 @@ #ifndef _CLOCK_CONFIG_H_ #define _CLOCK_CONFIG_H_ +#include #include "fsl_common.h" /*** @@ -34,61 +35,7 @@ void BOARD_InitBootClocks(void); } #endif /* __cplusplus*/ -/*** - ** Configuration BOARD_BootClockRUN *** - **/ -/*** - * Definitions for BOARD_BootClockRUN configuration - **/ -#define BOARD_BOOTCLOCKRUN_CORE_CLOCK 6U /*!< Core clock frequency: 6Hz */ - -/* Clock outputs (values are in Hz): */ -#define BOARD_BOOTCLOCKRUN_AHB_CLK_ROOT 6UL -#define BOARD_BOOTCLOCKRUN_CAN_CLK_ROOT 4000UL -#define BOARD_BOOTCLOCKRUN_CKIL_SYNC_CLK_ROOT 32768UL -#define BOARD_BOOTCLOCKRUN_CLKO1_CLK 0UL -#define BOARD_BOOTCLOCKRUN_CLKO2_CLK 0UL -#define BOARD_BOOTCLOCKRUN_CLK_1M 100UL -#define BOARD_BOOTCLOCKRUN_CLK_24M 2400UL -#define BOARD_BOOTCLOCKRUN_CSI_CLK_ROOT 1200UL -#define BOARD_BOOTCLOCKRUN_ENET1_TX_CLK 240UL -#define BOARD_BOOTCLOCKRUN_ENET_125M_CLK 240UL -#define BOARD_BOOTCLOCKRUN_ENET_25M_REF_CLK 120UL -#define BOARD_BOOTCLOCKRUN_FLEXIO1_CLK_ROOT 3000UL -#define BOARD_BOOTCLOCKRUN_FLEXIO2_CLK_ROOT 3000UL -#define BOARD_BOOTCLOCKRUN_FLEXSPI_CLK_ROOT 16000UL -#define BOARD_BOOTCLOCKRUN_GPT1_IPG_CLK_HIGHFREQ 7500UL -#define BOARD_BOOTCLOCKRUN_GPT2_IPG_CLK_HIGHFREQ 7500UL -#define BOARD_BOOTCLOCKRUN_IPG_CLK_ROOT 15000UL -#define BOARD_BOOTCLOCKRUN_LCDIF_CLK_ROOT 9642857UL -#define BOARD_BOOTCLOCKRUN_LPI2C_CLK_ROOT 6000UL -#define BOARD_BOOTCLOCKRUN_LPSPI_CLK_ROOT 10560UL -#define BOARD_BOOTCLOCKRUN_LVDS1_CLK 12UL -#define BOARD_BOOTCLOCKRUN_MQS_MCLK 63529411UL -#define BOARD_BOOTCLOCKRUN_PERCLK_CLK_ROOT 7500UL -#define BOARD_BOOTCLOCKRUN_PLL7_MAIN_CLK 2400UL -#define BOARD_BOOTCLOCKRUN_SAI1_CLK_ROOT 63529411UL -#define BOARD_BOOTCLOCKRUN_SAI1_MCLK1 63529411UL -#define BOARD_BOOTCLOCKRUN_SAI1_MCLK2 63529411UL -#define BOARD_BOOTCLOCKRUN_SAI1_MCLK3 3000UL -#define BOARD_BOOTCLOCKRUN_SAI2_CLK_ROOT 63529411UL -#define BOARD_BOOTCLOCKRUN_SAI2_MCLK1 63529411UL -#define BOARD_BOOTCLOCKRUN_SAI2_MCLK2 0UL -#define BOARD_BOOTCLOCKRUN_SAI2_MCLK3 3000UL -#define BOARD_BOOTCLOCKRUN_SAI3_CLK_ROOT 63529411UL -#define BOARD_BOOTCLOCKRUN_SAI3_MCLK1 63529411UL -#define BOARD_BOOTCLOCKRUN_SAI3_MCLK2 0UL -#define BOARD_BOOTCLOCKRUN_SAI3_MCLK3 3000UL -#define BOARD_BOOTCLOCKRUN_SEMC_CLK_ROOT 7500UL -#define BOARD_BOOTCLOCKRUN_SPDIF0_CLK_ROOT 3000UL -#define BOARD_BOOTCLOCKRUN_SPDIF0_EXTCLK_OUT 0UL -#define BOARD_BOOTCLOCKRUN_TRACE_CLK_ROOT 11733UL -#define BOARD_BOOTCLOCKRUN_UART_CLK_ROOT 8000UL -#define BOARD_BOOTCLOCKRUN_USBPHY1_CLK 0UL -#define BOARD_BOOTCLOCKRUN_USBPHY2_CLK 0UL -#define BOARD_BOOTCLOCKRUN_USDHC1_CLK_ROOT 19800UL -#define BOARD_BOOTCLOCKRUN_USDHC2_CLK_ROOT 19800UL - +#if IMXRT_IS_MIMXRT10xx /*! @brief Arm PLL set for BOARD_BootClockRUN configuration. */ extern const clock_arm_pll_config_t armPllConfig_BOARD_BootClockRUN; @@ -98,6 +45,7 @@ extern const clock_usb_pll_config_t usb1PllConfig_BOARD_BootClockRUN; /*! @brief Sys PLL for BOARD_BootClockRUN configuration. */ extern const clock_sys_pll_config_t sysPllConfig_BOARD_BootClockRUN; +#endif /*** * API for BOARD_BootClockRUN configuration diff --git a/bsps/arm/imxrt/nxp/boards/evkbimxrt1050/clock_config.c b/bsps/arm/imxrt/nxp/boards/evkbimxrt1050/clock_config.c index 4ab5216ee1..8f6980d0ef 100644 --- a/bsps/arm/imxrt/nxp/boards/evkbimxrt1050/clock_config.c +++ b/bsps/arm/imxrt/nxp/boards/evkbimxrt1050/clock_config.c @@ -487,5 +487,5 @@ void BOARD_BootClockRUN(void) /* Set GPT2 High frequency reference clock source. */ IOMUXC_GPR->GPR5 &= ~IOMUXC_GPR_GPR5_VREF_1M_CLK_GPT2_MASK; /* Set SystemCoreClock variable. */ -SystemCoreClock = BOARD_BOOTCLOCKRUN_CORE_CLOCK; +SystemCoreClock = 6U; } -- 2.35.3 ___
[PATCH rtems v2 03/12] bsps/imxrt: Adapt to new mcux-sdk version
Remove the old NXP MCUXpresso SDK and adapt the BSP so that it uses the new mcux-sdk. NOTE: Due to the size, this is only the summary of the patch. You can find the full version here: https://gitlab.com/c-mauderer/rtems/-/commit/2c979bc53bdf633b1fdabc7c5ecf2b1d90a85ac6 --- bsps/arm/imxrt/include/MIMXRT1052.h | 46183 bsps/arm/imxrt/include/MIMXRT1052_features.h | 688 - bsps/arm/imxrt/include/bsp.h | 1 + bsps/arm/imxrt/include/chip.h | 3 +- bsps/arm/imxrt/include/fsl_adc.h | 427 - bsps/arm/imxrt/include/fsl_adc_etc.h | 336 - bsps/arm/imxrt/include/fsl_aipstz.h | 134 - bsps/arm/imxrt/include/fsl_aoi.h | 186 - bsps/arm/imxrt/include/fsl_bee.h | 254 - bsps/arm/imxrt/include/fsl_cache.h| 457 - bsps/arm/imxrt/include/fsl_clock.h| 1550 - bsps/arm/imxrt/include/fsl_cmp.h | 321 - bsps/arm/imxrt/include/fsl_common.h | 967 - bsps/arm/imxrt/include/fsl_csi.h | 724 - bsps/arm/imxrt/include/fsl_dcdc.h | 496 - bsps/arm/imxrt/include/fsl_dcp.h | 569 - bsps/arm/imxrt/include/fsl_device_registers.h |41 - bsps/arm/imxrt/include/fsl_dmamux.h | 177 - bsps/arm/imxrt/include/fsl_edma.h | 951 - bsps/arm/imxrt/include/fsl_elcdif.h | 747 - bsps/arm/imxrt/include/fsl_enc.h | 458 - bsps/arm/imxrt/include/fsl_enet.h | 1855 - bsps/arm/imxrt/include/fsl_ewm.h | 218 - bsps/arm/imxrt/include/fsl_flexcan.h | 1422 - bsps/arm/imxrt/include/fsl_flexio.h | 700 - bsps/arm/imxrt/include/fsl_flexio_camera.h| 230 - .../imxrt/include/fsl_flexio_camera_edma.h| 130 - .../arm/imxrt/include/fsl_flexio_i2c_master.h | 486 - bsps/arm/imxrt/include/fsl_flexio_i2s.h | 560 - bsps/arm/imxrt/include/fsl_flexio_i2s_edma.h | 203 - bsps/arm/imxrt/include/fsl_flexio_mculcd.h| 685 - .../imxrt/include/fsl_flexio_mculcd_edma.h| 153 - bsps/arm/imxrt/include/fsl_flexio_spi.h | 702 - bsps/arm/imxrt/include/fsl_flexio_spi_edma.h | 207 - bsps/arm/imxrt/include/fsl_flexio_uart.h | 570 - bsps/arm/imxrt/include/fsl_flexio_uart_edma.h | 178 - bsps/arm/imxrt/include/fsl_flexram.h | 276 - bsps/arm/imxrt/include/fsl_flexram_allocate.h |99 - bsps/arm/imxrt/include/fsl_flexspi.h | 837 - bsps/arm/imxrt/include/fsl_flexspi_nor_boot.h | 130 - bsps/arm/imxrt/include/fsl_gpc.h | 231 - bsps/arm/imxrt/include/fsl_gpio.h | 342 - bsps/arm/imxrt/include/fsl_gpt.h | 509 - bsps/arm/imxrt/include/fsl_iomuxc.h | 1242 - bsps/arm/imxrt/include/fsl_kpp.h | 180 - bsps/arm/imxrt/include/fsl_lpi2c.h| 1266 - bsps/arm/imxrt/include/fsl_lpi2c_edma.h | 157 - bsps/arm/imxrt/include/fsl_lpspi.h| 1122 - bsps/arm/imxrt/include/fsl_lpspi_edma.h | 301 - bsps/arm/imxrt/include/fsl_lpuart.h | 866 - bsps/arm/imxrt/include/fsl_lpuart_edma.h | 173 - bsps/arm/imxrt/include/fsl_ocotp.h| 153 - bsps/arm/imxrt/include/fsl_pin_mux.h | 942 - bsps/arm/imxrt/include/fsl_pit.h | 332 - bsps/arm/imxrt/include/fsl_pmu.h | 671 - bsps/arm/imxrt/include/fsl_pwm.h | 987 - bsps/arm/imxrt/include/fsl_pxp.h | 1438 - bsps/arm/imxrt/include/fsl_qtmr.h | 473 - bsps/arm/imxrt/include/fsl_rtwdog.h | 425 - bsps/arm/imxrt/include/fsl_sai.h | 1572 - bsps/arm/imxrt/include/fsl_sai_edma.h | 268 - bsps/arm/imxrt/include/fsl_semc.h | 831 - bsps/arm/imxrt/include/fsl_snvs_hp.h | 626 - bsps/arm/imxrt/include/fsl_snvs_lp.h | 555 - bsps/arm/imxrt/include/fsl_spdif.h| 746 - bsps/arm/imxrt/include/fsl_spdif_edma.h | 192 - bsps/arm/imxrt/include/fsl_src.h | 602 - bsps/arm/imxrt/include/fsl_tempmon.h | 126 - bsps/arm/imxrt/include/fsl_trng.h | 228 - bsps/arm/imxrt/include/fsl_tsc.h | 524 - bsps/arm/imxrt/include/fsl_usdhc.h| 1581 - bsps/arm/imxrt/include/fsl_wdog.h | 305 - bsps/arm/imxrt/include/fsl_xbara.h| 183 - bsps/arm/imxrt/include/fsl_xbarb.h|82 - bsps/arm/imxrt/include/system_MIMXRT1052.h| 129 - .../imxrt/nxp/boards/evkbimxrt1050/pin_mux.c | 1073 +- .../nxp/devices/MIMXRT1052/drivers/fsl_adc.c | 395 - .../devices/MIMXRT1052/drivers/fsl_adc_etc.c | 433 - .../devices/MIMXRT1052/drivers/fsl_aipstz.c |51 - .../nxp/devices/MIMXRT1052/drivers/fsl_aoi.c | 214 - .../nxp/devices/MIMXRT1052/drivers/fsl_bee.c | 303 - .../devices/MIMXRT1052/drivers/fsl_cache.c| 602 -
[PATCH rtems v2 10/12] bsps/imxrt: Move board specific files
Move the files that are board specific and not specific to the chip
family into a separate folder.
---
.../evkbimxrt1050}/clock-arm-pll-config.c | 0
.../boards/evkbimxrt1050/clock_config.c | 0
.../evkbimxrt1050}/flash-dcd.c| 0
.../{nxp => }/boards/evkbimxrt1050/pin_mux.c | 0
spec/build/bsps/arm/imxrt/bspimxrt1052.yml| 19 ---
spec/build/bsps/arm/imxrt/obj.yml | 7 ---
6 files changed, 16 insertions(+), 10 deletions(-)
rename bsps/arm/imxrt/{start => boards/evkbimxrt1050}/clock-arm-pll-config.c
(100%)
rename bsps/arm/imxrt/{nxp => }/boards/evkbimxrt1050/clock_config.c (100%)
rename bsps/arm/imxrt/{start => boards/evkbimxrt1050}/flash-dcd.c (100%)
rename bsps/arm/imxrt/{nxp => }/boards/evkbimxrt1050/pin_mux.c (100%)
diff --git a/bsps/arm/imxrt/start/clock-arm-pll-config.c
b/bsps/arm/imxrt/boards/evkbimxrt1050/clock-arm-pll-config.c
similarity index 100%
rename from bsps/arm/imxrt/start/clock-arm-pll-config.c
rename to bsps/arm/imxrt/boards/evkbimxrt1050/clock-arm-pll-config.c
diff --git a/bsps/arm/imxrt/nxp/boards/evkbimxrt1050/clock_config.c
b/bsps/arm/imxrt/boards/evkbimxrt1050/clock_config.c
similarity index 100%
rename from bsps/arm/imxrt/nxp/boards/evkbimxrt1050/clock_config.c
rename to bsps/arm/imxrt/boards/evkbimxrt1050/clock_config.c
diff --git a/bsps/arm/imxrt/start/flash-dcd.c
b/bsps/arm/imxrt/boards/evkbimxrt1050/flash-dcd.c
similarity index 100%
rename from bsps/arm/imxrt/start/flash-dcd.c
rename to bsps/arm/imxrt/boards/evkbimxrt1050/flash-dcd.c
diff --git a/bsps/arm/imxrt/nxp/boards/evkbimxrt1050/pin_mux.c
b/bsps/arm/imxrt/boards/evkbimxrt1050/pin_mux.c
similarity index 100%
rename from bsps/arm/imxrt/nxp/boards/evkbimxrt1050/pin_mux.c
rename to bsps/arm/imxrt/boards/evkbimxrt1050/pin_mux.c
diff --git a/spec/build/bsps/arm/imxrt/bspimxrt1052.yml
b/spec/build/bsps/arm/imxrt/bspimxrt1052.yml
index 348b90bcdb..6c2b3339f9 100644
--- a/spec/build/bsps/arm/imxrt/bspimxrt1052.yml
+++ b/spec/build/bsps/arm/imxrt/bspimxrt1052.yml
@@ -8,10 +8,23 @@ copyrights:
cppflags: []
enabled-by: true
family: imxrt
-includes: []
-install: []
+includes:
+- bsps/arm/imxrt/mcux-sdk/drivers/common
+- bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1052
+- bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1052/drivers
+- bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1052/xip
+install:
+- destination: ${BSP_INCLUDEDIR}/imxrt
+ source:
+ - bsps/arm/imxrt/include/imxrt/imxrt1050.dtsi
+ - bsps/arm/imxrt/include/imxrt/imxrt1050-pinfunc.h
links:
- role: build-dependency
uid: obj-mimxrt1052
-source: []
+source:
+- bsps/arm/imxrt/boards/evkbimxrt1050/clock_config.c
+- bsps/arm/imxrt/boards/evkbimxrt1050/flash-dcd.c
+- bsps/arm/imxrt/boards/evkbimxrt1050/pin_mux.c
+- bsps/arm/imxrt/boards/evkbimxrt1050/clock-arm-pll-config.c
+- bsps/arm/imxrt/dts/imxrt1050-evkb.c
type: build
diff --git a/spec/build/bsps/arm/imxrt/obj.yml
b/spec/build/bsps/arm/imxrt/obj.yml
index b2c1d6fa4f..85cb350dd2 100644
--- a/spec/build/bsps/arm/imxrt/obj.yml
+++ b/spec/build/bsps/arm/imxrt/obj.yml
@@ -25,8 +25,6 @@ install:
- bsps/arm/include/bsp/imx-iomux.h
- destination: ${BSP_INCLUDEDIR}/imxrt
source:
- - bsps/arm/imxrt/include/imxrt/imxrt1050.dtsi
- - bsps/arm/imxrt/include/imxrt/imxrt1050-pinfunc.h
- bsps/arm/imxrt/include/imxrt/lpspi.h
- bsps/arm/imxrt/include/imxrt/memory.h
- bsps/arm/imxrt/include/imxrt/mpu-config.h
@@ -38,16 +36,11 @@ install:
links: []
source:
- bsps/arm/imxrt/console/console.c
-- bsps/arm/imxrt/dts/imxrt1050-evkb.c
- bsps/arm/imxrt/i2c/imxrt-lpi2c.c
-- bsps/arm/imxrt/nxp/boards/evkbimxrt1050/clock_config.c
-- bsps/arm/imxrt/nxp/boards/evkbimxrt1050/pin_mux.c
- bsps/arm/imxrt/spi/imxrt-lpspi.c
- bsps/arm/imxrt/start/bspstart.c
- bsps/arm/imxrt/start/bspstarthooks.c
-- bsps/arm/imxrt/start/clock-arm-pll-config.c
- bsps/arm/imxrt/start/flash-boot-data.c
-- bsps/arm/imxrt/start/flash-dcd.c
- bsps/arm/imxrt/start/flash-flexspi-config.c
- bsps/arm/imxrt/start/flash-ivt.c
- bsps/arm/imxrt/start/imxrt-ffec-init.c
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems v2 11/12] bsps/imxrt: Make the OCRAM address configurable
Depending on the chip variant, the OCRAM can have different addresses.
Make it configurable.
---
spec/build/bsps/arm/imxrt/grp.yml | 2 ++
spec/build/bsps/arm/imxrt/linkcmdsmemory.yml| 4 ++--
spec/build/bsps/arm/imxrt/optmemocramorigin.yml | 17 +
3 files changed, 21 insertions(+), 2 deletions(-)
create mode 100644 spec/build/bsps/arm/imxrt/optmemocramorigin.yml
diff --git a/spec/build/bsps/arm/imxrt/grp.yml
b/spec/build/bsps/arm/imxrt/grp.yml
index 17b4f48dab..feda472401 100644
--- a/spec/build/bsps/arm/imxrt/grp.yml
+++ b/spec/build/bsps/arm/imxrt/grp.yml
@@ -46,6 +46,8 @@ links:
uid: optmemnullsz
- role: build-dependency
uid: optmemocramnocachesz
+- role: build-dependency
+ uid: optmemocramorigin
- role: build-dependency
uid: optmemocramsz
- role: build-dependency
diff --git a/spec/build/bsps/arm/imxrt/linkcmdsmemory.yml
b/spec/build/bsps/arm/imxrt/linkcmdsmemory.yml
index 2d8187052f..cf66966b5d 100644
--- a/spec/build/bsps/arm/imxrt/linkcmdsmemory.yml
+++ b/spec/build/bsps/arm/imxrt/linkcmdsmemory.yml
@@ -5,8 +5,8 @@ content: |
NULL : ORIGIN = 0x, LENGTH =
${IMXRT_MEMORY_NULL_SIZE:#010x}
ITCM : ORIGIN = ${IMXRT_MEMORY_NULL_SIZE:#010x}, LENGTH =
${IMXRT_MEMORY_ITCM_SIZE:#010x}
DTCM : ORIGIN = 0x2000, LENGTH =
${IMXRT_MEMORY_DTCM_SIZE:#010x}
-OCRAM : ORIGIN = 0x2020, LENGTH =
${IMXRT_MEMORY_OCRAM_SIZE:#010x} - ${IMXRT_MEMORY_OCRAM_NOCACHE_SIZE:#010x}
-OCRAM_NOCACHE : ORIGIN = 0x2020 + ${IMXRT_MEMORY_OCRAM_SIZE:#010x} -
${IMXRT_MEMORY_OCRAM_NOCACHE_SIZE:#010x}, LENGTH =
${IMXRT_MEMORY_OCRAM_NOCACHE_SIZE:#010x}
+OCRAM : ORIGIN = ${IMXRT_MEMORY_OCRAM_ORIGIN}, LENGTH =
${IMXRT_MEMORY_OCRAM_SIZE:#010x} - ${IMXRT_MEMORY_OCRAM_NOCACHE_SIZE:#010x}
+OCRAM_NOCACHE : ORIGIN = ${IMXRT_MEMORY_OCRAM_ORIGIN} +
${IMXRT_MEMORY_OCRAM_SIZE:#010x} - ${IMXRT_MEMORY_OCRAM_NOCACHE_SIZE:#010x},
LENGTH = ${IMXRT_MEMORY_OCRAM_NOCACHE_SIZE:#010x}
PERIPHERAL : ORIGIN = 0x4000, LENGTH = 0x2000
FLASH_CONFIG : ORIGIN = ${IMXRT_MEMORY_FLASH_ORIGIN:#010x}, LENGTH =
${IMXRT_MEMORY_FLASH_CFG_SIZE:#010x}
FLASH_IVT : ORIGIN = ${IMXRT_MEMORY_FLASH_ORIGIN:#010x} +
${IMXRT_MEMORY_FLASH_CFG_SIZE:#010x}, LENGTH =
${IMXRT_MEMORY_FLASH_IVT_SIZE:#010x}
diff --git a/spec/build/bsps/arm/imxrt/optmemocramorigin.yml
b/spec/build/bsps/arm/imxrt/optmemocramorigin.yml
new file mode 100644
index 00..c3d08918a7
--- /dev/null
+++ b/spec/build/bsps/arm/imxrt/optmemocramorigin.yml
@@ -0,0 +1,17 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-integer: null
+- env-assign: null
+build-type: option
+copyrights:
+- Copyright (C) 2023 embedded brains GmbH (http://www.embedded-brains.de)
+default:
+- enabled-by: true
+ value: 0x2020
+description: |
+ Origin of the OCRAM.
+enabled-by: true
+format: '{:#010x}'
+links: []
+name: IMXRT_MEMORY_OCRAM_ORIGIN
+type: build
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems v2 06/12] bsps/shared: Fix header for fsl-edma
If a different chip variant is used in the i.mxrt BSP, a different header would have to be included. Make sure that the fsl-edma driver uses a header that doesn't have to be adapted. --- bsps/shared/dev/dma/fsl-edma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsps/shared/dev/dma/fsl-edma.c b/bsps/shared/dev/dma/fsl-edma.c index b3e1bb2fc5..3cb91c14e6 100644 --- a/bsps/shared/dev/dma/fsl-edma.c +++ b/bsps/shared/dev/dma/fsl-edma.c @@ -40,7 +40,7 @@ #include #include #ifdef LIBBSP_ARM_IMXRT_BSP_H -#include +#include #endif #define EDMA_CHANNELS_PER_GROUP 32U -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems v2 09/12] bsps/imxrt: Make chip start code chip specific
Some parts of the startup code don't apply for all chips. Make that part
chip specific.
---
bsps/arm/imxrt/start/bspstart.c | 4
bsps/arm/imxrt/start/bspstarthooks.c | 2 ++
2 files changed, 6 insertions(+)
diff --git a/bsps/arm/imxrt/start/bspstart.c b/bsps/arm/imxrt/start/bspstart.c
index 445af04563..6d873f4afd 100644
--- a/bsps/arm/imxrt/start/bspstart.c
+++ b/bsps/arm/imxrt/start/bspstart.c
@@ -47,6 +47,7 @@ uint32_t imxrt_systick_frequency(void)
static void imxrt_disable_wait_mode(void)
{
+#if IMXRT_IS_MIMXRT10xx
/*
* Prevent processor from entering WAIT or SLEEP mode when a WFI is executed.
* This would switch off the normal interrupt controller and activate an
@@ -58,6 +59,9 @@ static void imxrt_disable_wait_mode(void)
* every WFI.
*/
CLOCK_SetMode(kCLOCK_ModeRun);
+#else
+ #error Disabling wait mode not implemented for this chip.
+#endif
}
void bsp_start(void)
diff --git a/bsps/arm/imxrt/start/bspstarthooks.c
b/bsps/arm/imxrt/start/bspstarthooks.c
index a84f2a427f..5bd847b1cf 100644
--- a/bsps/arm/imxrt/start/bspstarthooks.c
+++ b/bsps/arm/imxrt/start/bspstarthooks.c
@@ -58,9 +58,11 @@ BSP_START_TEXT_SECTION void bsp_start_hook_1(void)
BOARD_BootClockRUN();
BOARD_InitDEBUG_UARTPins();
+#if IMXRT_IS_MIMXRT10xx
/* Reduce frequency for I2C */
CLOCK_SetDiv(kCLOCK_Lpi2cDiv, 5);
/* Enable EDMA clock. We initialize the EDMA so we need the clock. */
CLOCK_EnableClock(kCLOCK_Dma);
+#endif
}
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems v2 00/12] bsp/imxrt: Update SDK and prepare for new variant
Hello, this is the second version of the patch set to update the SDK files in the i.MXRT BSPs. Like said in the earlier version: I plan to add a i.MXRT1166 based BSP soon. The changes are: - I now only imported the SDK files for i.MXRT1050 and i.MXRT1166. With that the imported files (mainly first patch) are now only 18MB instead of 90MB. - The script to import the files is now removed. I added a link to it in the description of the import patch. I'll create a short note for the documentation soon. - I added some minor fixes that I noted during further tests. The full version of the two big patches (1 and 3) can be found on this branch: https://gitlab.com/c-mauderer/rtems/-/commits/cm/20230509_imxrt/ Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems v2 04/12] bsps/imxrt1052: PLL config based on speed grade
---
bsps/arm/imxrt/start/clock-arm-pll-config.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/bsps/arm/imxrt/start/clock-arm-pll-config.c
b/bsps/arm/imxrt/start/clock-arm-pll-config.c
index 12ad1867eb..2a0148e73a 100644
--- a/bsps/arm/imxrt/start/clock-arm-pll-config.c
+++ b/bsps/arm/imxrt/start/clock-arm-pll-config.c
@@ -26,8 +26,15 @@
*/
#include "fsl_clock_config.h"
+#include
const clock_arm_pll_config_t armPllConfig_BOARD_BootClockRUN = {
+#if (IMXRT_SPEEDGRADE == '6')
.loopDivider = 100,
+#elif (IMXRT_SPEEDGRADE == '5')
+.loopDivider = 88,
+#else
+#error unknown speed grade of i.MXRT processor
+#endif
.src = 0,
};
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 12/12] bsps/imxrt: Make the OCRAM address configurable
Depending on the chip variant, the OCRAM can have different addresses.
Make it configurable.
---
spec/build/bsps/arm/imxrt/grp.yml | 2 ++
spec/build/bsps/arm/imxrt/linkcmdsmemory.yml| 4 ++--
spec/build/bsps/arm/imxrt/optmemocramorigin.yml | 17 +
3 files changed, 21 insertions(+), 2 deletions(-)
create mode 100644 spec/build/bsps/arm/imxrt/optmemocramorigin.yml
diff --git a/spec/build/bsps/arm/imxrt/grp.yml
b/spec/build/bsps/arm/imxrt/grp.yml
index 17b4f48dab..feda472401 100644
--- a/spec/build/bsps/arm/imxrt/grp.yml
+++ b/spec/build/bsps/arm/imxrt/grp.yml
@@ -46,6 +46,8 @@ links:
uid: optmemnullsz
- role: build-dependency
uid: optmemocramnocachesz
+- role: build-dependency
+ uid: optmemocramorigin
- role: build-dependency
uid: optmemocramsz
- role: build-dependency
diff --git a/spec/build/bsps/arm/imxrt/linkcmdsmemory.yml
b/spec/build/bsps/arm/imxrt/linkcmdsmemory.yml
index 2d8187052f..cf66966b5d 100644
--- a/spec/build/bsps/arm/imxrt/linkcmdsmemory.yml
+++ b/spec/build/bsps/arm/imxrt/linkcmdsmemory.yml
@@ -5,8 +5,8 @@ content: |
NULL : ORIGIN = 0x, LENGTH =
${IMXRT_MEMORY_NULL_SIZE:#010x}
ITCM : ORIGIN = ${IMXRT_MEMORY_NULL_SIZE:#010x}, LENGTH =
${IMXRT_MEMORY_ITCM_SIZE:#010x}
DTCM : ORIGIN = 0x2000, LENGTH =
${IMXRT_MEMORY_DTCM_SIZE:#010x}
-OCRAM : ORIGIN = 0x2020, LENGTH =
${IMXRT_MEMORY_OCRAM_SIZE:#010x} - ${IMXRT_MEMORY_OCRAM_NOCACHE_SIZE:#010x}
-OCRAM_NOCACHE : ORIGIN = 0x2020 + ${IMXRT_MEMORY_OCRAM_SIZE:#010x} -
${IMXRT_MEMORY_OCRAM_NOCACHE_SIZE:#010x}, LENGTH =
${IMXRT_MEMORY_OCRAM_NOCACHE_SIZE:#010x}
+OCRAM : ORIGIN = ${IMXRT_MEMORY_OCRAM_ORIGIN}, LENGTH =
${IMXRT_MEMORY_OCRAM_SIZE:#010x} - ${IMXRT_MEMORY_OCRAM_NOCACHE_SIZE:#010x}
+OCRAM_NOCACHE : ORIGIN = ${IMXRT_MEMORY_OCRAM_ORIGIN} +
${IMXRT_MEMORY_OCRAM_SIZE:#010x} - ${IMXRT_MEMORY_OCRAM_NOCACHE_SIZE:#010x},
LENGTH = ${IMXRT_MEMORY_OCRAM_NOCACHE_SIZE:#010x}
PERIPHERAL : ORIGIN = 0x4000, LENGTH = 0x2000
FLASH_CONFIG : ORIGIN = ${IMXRT_MEMORY_FLASH_ORIGIN:#010x}, LENGTH =
${IMXRT_MEMORY_FLASH_CFG_SIZE:#010x}
FLASH_IVT : ORIGIN = ${IMXRT_MEMORY_FLASH_ORIGIN:#010x} +
${IMXRT_MEMORY_FLASH_CFG_SIZE:#010x}, LENGTH =
${IMXRT_MEMORY_FLASH_IVT_SIZE:#010x}
diff --git a/spec/build/bsps/arm/imxrt/optmemocramorigin.yml
b/spec/build/bsps/arm/imxrt/optmemocramorigin.yml
new file mode 100644
index 00..c3d08918a7
--- /dev/null
+++ b/spec/build/bsps/arm/imxrt/optmemocramorigin.yml
@@ -0,0 +1,17 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-integer: null
+- env-assign: null
+build-type: option
+copyrights:
+- Copyright (C) 2023 embedded brains GmbH (http://www.embedded-brains.de)
+default:
+- enabled-by: true
+ value: 0x2020
+description: |
+ Origin of the OCRAM.
+enabled-by: true
+format: '{:#010x}'
+links: []
+name: IMXRT_MEMORY_OCRAM_ORIGIN
+type: build
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 11/12] bsps/imxrt: Move board specific files
Move the files that are board specific and not specific to the chip
family into a separate folder.
---
.../evkbimxrt1050}/clock-arm-pll-config.c | 0
.../boards/evkbimxrt1050/clock_config.c | 0
.../evkbimxrt1050}/flash-dcd.c| 0
.../{nxp => }/boards/evkbimxrt1050/pin_mux.c | 0
spec/build/bsps/arm/imxrt/bspimxrt1052.yml| 19 ---
spec/build/bsps/arm/imxrt/obj.yml | 7 ---
6 files changed, 16 insertions(+), 10 deletions(-)
rename bsps/arm/imxrt/{start => boards/evkbimxrt1050}/clock-arm-pll-config.c
(100%)
rename bsps/arm/imxrt/{nxp => }/boards/evkbimxrt1050/clock_config.c (100%)
rename bsps/arm/imxrt/{start => boards/evkbimxrt1050}/flash-dcd.c (100%)
rename bsps/arm/imxrt/{nxp => }/boards/evkbimxrt1050/pin_mux.c (100%)
diff --git a/bsps/arm/imxrt/start/clock-arm-pll-config.c
b/bsps/arm/imxrt/boards/evkbimxrt1050/clock-arm-pll-config.c
similarity index 100%
rename from bsps/arm/imxrt/start/clock-arm-pll-config.c
rename to bsps/arm/imxrt/boards/evkbimxrt1050/clock-arm-pll-config.c
diff --git a/bsps/arm/imxrt/nxp/boards/evkbimxrt1050/clock_config.c
b/bsps/arm/imxrt/boards/evkbimxrt1050/clock_config.c
similarity index 100%
rename from bsps/arm/imxrt/nxp/boards/evkbimxrt1050/clock_config.c
rename to bsps/arm/imxrt/boards/evkbimxrt1050/clock_config.c
diff --git a/bsps/arm/imxrt/start/flash-dcd.c
b/bsps/arm/imxrt/boards/evkbimxrt1050/flash-dcd.c
similarity index 100%
rename from bsps/arm/imxrt/start/flash-dcd.c
rename to bsps/arm/imxrt/boards/evkbimxrt1050/flash-dcd.c
diff --git a/bsps/arm/imxrt/nxp/boards/evkbimxrt1050/pin_mux.c
b/bsps/arm/imxrt/boards/evkbimxrt1050/pin_mux.c
similarity index 100%
rename from bsps/arm/imxrt/nxp/boards/evkbimxrt1050/pin_mux.c
rename to bsps/arm/imxrt/boards/evkbimxrt1050/pin_mux.c
diff --git a/spec/build/bsps/arm/imxrt/bspimxrt1052.yml
b/spec/build/bsps/arm/imxrt/bspimxrt1052.yml
index 348b90bcdb..6c2b3339f9 100644
--- a/spec/build/bsps/arm/imxrt/bspimxrt1052.yml
+++ b/spec/build/bsps/arm/imxrt/bspimxrt1052.yml
@@ -8,10 +8,23 @@ copyrights:
cppflags: []
enabled-by: true
family: imxrt
-includes: []
-install: []
+includes:
+- bsps/arm/imxrt/mcux-sdk/drivers/common
+- bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1052
+- bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1052/drivers
+- bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1052/xip
+install:
+- destination: ${BSP_INCLUDEDIR}/imxrt
+ source:
+ - bsps/arm/imxrt/include/imxrt/imxrt1050.dtsi
+ - bsps/arm/imxrt/include/imxrt/imxrt1050-pinfunc.h
links:
- role: build-dependency
uid: obj-mimxrt1052
-source: []
+source:
+- bsps/arm/imxrt/boards/evkbimxrt1050/clock_config.c
+- bsps/arm/imxrt/boards/evkbimxrt1050/flash-dcd.c
+- bsps/arm/imxrt/boards/evkbimxrt1050/pin_mux.c
+- bsps/arm/imxrt/boards/evkbimxrt1050/clock-arm-pll-config.c
+- bsps/arm/imxrt/dts/imxrt1050-evkb.c
type: build
diff --git a/spec/build/bsps/arm/imxrt/obj.yml
b/spec/build/bsps/arm/imxrt/obj.yml
index 96d487dd8b..30ed2fb1d2 100644
--- a/spec/build/bsps/arm/imxrt/obj.yml
+++ b/spec/build/bsps/arm/imxrt/obj.yml
@@ -26,8 +26,6 @@ install:
- bsps/arm/include/bsp/imx-iomux.h
- destination: ${BSP_INCLUDEDIR}/imxrt
source:
- - bsps/arm/imxrt/include/imxrt/imxrt1050.dtsi
- - bsps/arm/imxrt/include/imxrt/imxrt1050-pinfunc.h
- bsps/arm/imxrt/include/imxrt/lpspi.h
- bsps/arm/imxrt/include/imxrt/memory.h
- bsps/arm/imxrt/include/imxrt/mpu-config.h
@@ -39,16 +37,11 @@ install:
links: []
source:
- bsps/arm/imxrt/console/console.c
-- bsps/arm/imxrt/dts/imxrt1050-evkb.c
- bsps/arm/imxrt/i2c/imxrt-lpi2c.c
-- bsps/arm/imxrt/nxp/boards/evkbimxrt1050/clock_config.c
-- bsps/arm/imxrt/nxp/boards/evkbimxrt1050/pin_mux.c
- bsps/arm/imxrt/spi/imxrt-lpspi.c
- bsps/arm/imxrt/start/bspstart.c
- bsps/arm/imxrt/start/bspstarthooks.c
-- bsps/arm/imxrt/start/clock-arm-pll-config.c
- bsps/arm/imxrt/start/flash-boot-data.c
-- bsps/arm/imxrt/start/flash-dcd.c
- bsps/arm/imxrt/start/flash-flexspi-config.c
- bsps/arm/imxrt/start/flash-ivt.c
- bsps/arm/imxrt/start/imxrt-ffec-init.c
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 10/12] bsps/imxrt: Make chip start code chip specific
Some parts of the startup code don't apply for all chips. Make that part
chip specific.
---
bsps/arm/imxrt/start/bspstart.c | 4
bsps/arm/imxrt/start/bspstarthooks.c | 2 ++
2 files changed, 6 insertions(+)
diff --git a/bsps/arm/imxrt/start/bspstart.c b/bsps/arm/imxrt/start/bspstart.c
index 445af04563..6d873f4afd 100644
--- a/bsps/arm/imxrt/start/bspstart.c
+++ b/bsps/arm/imxrt/start/bspstart.c
@@ -47,6 +47,7 @@ uint32_t imxrt_systick_frequency(void)
static void imxrt_disable_wait_mode(void)
{
+#if IMXRT_IS_MIMXRT10xx
/*
* Prevent processor from entering WAIT or SLEEP mode when a WFI is executed.
* This would switch off the normal interrupt controller and activate an
@@ -58,6 +59,9 @@ static void imxrt_disable_wait_mode(void)
* every WFI.
*/
CLOCK_SetMode(kCLOCK_ModeRun);
+#else
+ #error Disabling wait mode not implemented for this chip.
+#endif
}
void bsp_start(void)
diff --git a/bsps/arm/imxrt/start/bspstarthooks.c
b/bsps/arm/imxrt/start/bspstarthooks.c
index a84f2a427f..5bd847b1cf 100644
--- a/bsps/arm/imxrt/start/bspstarthooks.c
+++ b/bsps/arm/imxrt/start/bspstarthooks.c
@@ -58,9 +58,11 @@ BSP_START_TEXT_SECTION void bsp_start_hook_1(void)
BOARD_BootClockRUN();
BOARD_InitDEBUG_UARTPins();
+#if IMXRT_IS_MIMXRT10xx
/* Reduce frequency for I2C */
CLOCK_SetDiv(kCLOCK_Lpi2cDiv, 5);
/* Enable EDMA clock. We initialize the EDMA so we need the clock. */
CLOCK_EnableClock(kCLOCK_Dma);
+#endif
}
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 03/12] bsps/imxrt: (Re-)Apply RTEMS patches to new lib
Reapply patches used in the old version of the NXP library and apply
patches necessary for the new version of the library.
---
.../devices/MIMXRT1011/fsl_device_registers.h | 3 +
.../MIMXRT1011/xip/fsl_flexspi_nor_boot.h | 4 +
.../devices/MIMXRT1015/fsl_device_registers.h | 3 +
.../MIMXRT1015/xip/fsl_flexspi_nor_boot.h | 4 +
.../devices/MIMXRT1024/fsl_device_registers.h | 3 +
.../MIMXRT1024/xip/fsl_flexspi_nor_boot.h | 4 +
.../devices/MIMXRT1042/fsl_device_registers.h | 3 +
.../MIMXRT1042/xip/fsl_flexspi_nor_boot.h | 4 +
.../devices/MIMXRT1051/fsl_device_registers.h | 3 +
.../devices/MIMXRT1052/fsl_device_registers.h | 3 +
.../MIMXRT1052/xip/fsl_flexspi_nor_boot.h | 4 +
.../devices/MIMXRT1061/fsl_device_registers.h | 3 +
.../devices/MIMXRT1062/fsl_device_registers.h | 3 +
.../MIMXRT1062/xip/fsl_flexspi_nor_boot.h | 4 +
.../devices/MIMXRT1064/fsl_device_registers.h | 3 +
.../MIMXRT1064/xip/fsl_flexspi_nor_boot.h | 4 +
.../devices/MIMXRT1165/fsl_device_registers.h | 3 +
.../devices/MIMXRT1166/fsl_device_registers.h | 3 +
.../MIMXRT1166/xip/fsl_flexspi_nor_boot.h | 4 +
.../devices/MIMXRT1171/fsl_device_registers.h | 3 +
.../devices/MIMXRT1172/fsl_device_registers.h | 3 +
.../devices/MIMXRT1173/fsl_device_registers.h | 3 +
.../devices/MIMXRT1175/fsl_device_registers.h | 3 +
.../devices/MIMXRT1176/fsl_device_registers.h | 3 +
.../MIMXRT1176/xip/fsl_flexspi_nor_boot.h | 4 +
.../mcux-sdk/drivers/common/fsl_common.h | 310 ++
.../mcux-sdk/drivers/lpuart/fsl_lpuart.c | 17 +
.../mcux-sdk/drivers/lpuart/fsl_lpuart.h | 4 +
.../imxrt/mcux-sdk/drivers/qtmr_1/fsl_qtmr.c | 40 +++
.../imxrt/mcux-sdk/drivers/qtmr_1/fsl_qtmr.h | 34 ++
30 files changed, 489 insertions(+)
diff --git a/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1011/fsl_device_registers.h
b/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1011/fsl_device_registers.h
index 53c8f43a30..43c5531aee 100644
--- a/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1011/fsl_device_registers.h
+++ b/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1011/fsl_device_registers.h
@@ -10,6 +10,9 @@
#ifndef __FSL_DEVICE_REGISTERS_H__
#define __FSL_DEVICE_REGISTERS_H__
+#ifdef __rtems__
+#include
+#endif /* __rtems__ */
/*
* Include the cpu specific register header files.
*
diff --git
a/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1011/xip/fsl_flexspi_nor_boot.h
b/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1011/xip/fsl_flexspi_nor_boot.h
index 38d5d1833e..5f81090890 100644
--- a/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1011/xip/fsl_flexspi_nor_boot.h
+++ b/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1011/xip/fsl_flexspi_nor_boot.h
@@ -10,9 +10,11 @@
#include
#include "fsl_common.h"
+#ifndef __rtems__
#ifndef BOARD_FLASH_SIZE
#include "board.h"
#endif
+#endif /* __rtems__ */
/*! @name Driver version */
/*@{*/
@@ -108,11 +110,13 @@ typedef struct _boot_data_
#define FLASH_BASE FlexSPI_AMBA_BASE
#endif
+#ifndef __rtems__
#if defined(BOARD_FLASH_SIZE)
#define FLASH_SIZE BOARD_FLASH_SIZE
#else
#error "Please define macro BOARD_FLASH_SIZE"
#endif
+#endif /* __rtems__ */
#define PLUGIN_FLAG (uint32_t)0
/* External Variables */
diff --git a/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1015/fsl_device_registers.h
b/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1015/fsl_device_registers.h
index 49f3013f6e..93b5c23d36 100644
--- a/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1015/fsl_device_registers.h
+++ b/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1015/fsl_device_registers.h
@@ -10,6 +10,9 @@
#ifndef __FSL_DEVICE_REGISTERS_H__
#define __FSL_DEVICE_REGISTERS_H__
+#ifdef __rtems__
+#include
+#endif /* __rtems__ */
/*
* Include the cpu specific register header files.
*
diff --git
a/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1015/xip/fsl_flexspi_nor_boot.h
b/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1015/xip/fsl_flexspi_nor_boot.h
index 38d5d1833e..5f81090890 100644
--- a/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1015/xip/fsl_flexspi_nor_boot.h
+++ b/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1015/xip/fsl_flexspi_nor_boot.h
@@ -10,9 +10,11 @@
#include
#include "fsl_common.h"
+#ifndef __rtems__
#ifndef BOARD_FLASH_SIZE
#include "board.h"
#endif
+#endif /* __rtems__ */
/*! @name Driver version */
/*@{*/
@@ -108,11 +110,13 @@ typedef struct _boot_data_
#define FLASH_BASE FlexSPI_AMBA_BASE
#endif
+#ifndef __rtems__
#if defined(BOARD_FLASH_SIZE)
#define FLASH_SIZE BOARD_FLASH_SIZE
#else
#error "Please define macro BOARD_FLASH_SIZE"
#endif
+#endif /* __rtems__ */
#define PLUGIN_FLAG (uint32_t)0
/* External Variables */
diff --git a/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1024/fsl_device_registers.h
b/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1024/fsl_device_registers.h
index edc59521dd..8b33d081e6 100644
--- a/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1024/fsl_device_registers.h
+++ b/bsps/arm/imxrt/mcux-sdk/devices/MIMXRT1024/fsl_device_registers.h
@@ -10,6 +10,9 @@
#ifndef
[PATCH rtems 02/12] bsp/imxrt: Update support library from mcux-sdk
This imports new files from the mcux-sdk support library. NXP now offers the library as a git repository instead of a zip package. The git repository supports multiple CPUs from the i.MXRT family: https://github.com/nxp-mcuxpresso/mcux-sdk.git The imported files are from revision 2b9354539e6e4f722749e87b0bdc22966dc080d9 This revision is the same as MCUXpresso 2.13.0 with small bug fixes. NOTE: Due to the size, this is only the summary of the patch. You can find the full version here: https://gitlab.com/c-mauderer/rtems/-/commit/2a871672767a95598e5af42373bfebd3eb9440d3 --- .../mcux-sdk/devices/MIMXRT1011/MIMXRT1011.h | 36631 + .../devices/MIMXRT1011/MIMXRT1011_features.h |572 + .../devices/MIMXRT1011/drivers/fsl_clock.c| 1224 + .../devices/MIMXRT1011/drivers/fsl_clock.h| 1574 + .../MIMXRT1011/drivers/fsl_flexram_allocate.c | 86 + .../MIMXRT1011/drivers/fsl_flexram_allocate.h | 87 + .../devices/MIMXRT1011/drivers/fsl_iomuxc.h |591 + .../devices/MIMXRT1011/drivers/fsl_nic301.h |294 + .../devices/MIMXRT1011/fsl_device_registers.h | 35 + .../MIMXRT1011/gcc/startup_MIMXRT1011.S |861 + .../devices/MIMXRT1011/system_MIMXRT1011.c|221 + .../devices/MIMXRT1011/system_MIMXRT1011.h|120 + .../MIMXRT1011/xip/fsl_flexspi_nor_boot.c | 49 + .../MIMXRT1011/xip/fsl_flexspi_nor_boot.h |124 + .../mcux-sdk/devices/MIMXRT1015/MIMXRT1015.h | 39826 ++ .../devices/MIMXRT1015/MIMXRT1015_features.h |581 + .../devices/MIMXRT1015/drivers/fsl_clock.c| 1201 + .../devices/MIMXRT1015/drivers/fsl_clock.h| 1648 + .../MIMXRT1015/drivers/fsl_flexram_allocate.c | 86 + .../MIMXRT1015/drivers/fsl_flexram_allocate.h | 87 + .../devices/MIMXRT1015/drivers/fsl_iomuxc.h |570 + .../devices/MIMXRT1015/drivers/fsl_nic301.h |294 + .../devices/MIMXRT1015/drivers/fsl_romapi.c |170 + .../devices/MIMXRT1015/drivers/fsl_romapi.h |554 + .../devices/MIMXRT1015/fsl_device_registers.h | 35 + .../MIMXRT1015/gcc/startup_MIMXRT1015.S |924 + .../devices/MIMXRT1015/system_MIMXRT1015.c|225 + .../devices/MIMXRT1015/system_MIMXRT1015.h|122 + .../MIMXRT1015/xip/fsl_flexspi_nor_boot.c | 49 + .../MIMXRT1015/xip/fsl_flexspi_nor_boot.h |124 + .../mcux-sdk/devices/MIMXRT1024/MIMXRT1024.h | 47174 +++ .../devices/MIMXRT1024/MIMXRT1024_features.h |746 + .../devices/MIMXRT1024/drivers/fsl_clock.c| 1249 + .../devices/MIMXRT1024/drivers/fsl_clock.h| 1806 + .../MIMXRT1024/drivers/fsl_flexram_allocate.c | 86 + .../MIMXRT1024/drivers/fsl_flexram_allocate.h | 87 + .../devices/MIMXRT1024/drivers/fsl_iomuxc.h |954 + .../devices/MIMXRT1024/drivers/fsl_nic301.h |294 + .../devices/MIMXRT1024/drivers/fsl_romapi.c |170 + .../devices/MIMXRT1024/drivers/fsl_romapi.h |554 + .../devices/MIMXRT1024/fsl_device_registers.h | 36 + .../MIMXRT1024/gcc/startup_MIMXRT1024.S | 1058 + .../devices/MIMXRT1024/system_MIMXRT1024.c|251 + .../devices/MIMXRT1024/system_MIMXRT1024.h|114 + .../MIMXRT1024/xip/fsl_flexspi_nor_boot.c | 49 + .../MIMXRT1024/xip/fsl_flexspi_nor_boot.h |124 + .../mcux-sdk/devices/MIMXRT1042/MIMXRT1042.h | 53934 .../devices/MIMXRT1042/MIMXRT1042_features.h |783 + .../devices/MIMXRT1042/drivers/fsl_clock.c| 1434 + .../devices/MIMXRT1042/drivers/fsl_clock.h| 1985 + .../MIMXRT1042/drivers/fsl_flexram_allocate.c | 86 + .../MIMXRT1042/drivers/fsl_flexram_allocate.h | 87 + .../devices/MIMXRT1042/drivers/fsl_iomuxc.h | 1156 + .../devices/MIMXRT1042/drivers/fsl_nic301.h |313 + .../devices/MIMXRT1042/drivers/fsl_romapi.c |196 + .../devices/MIMXRT1042/drivers/fsl_romapi.h |639 + .../devices/MIMXRT1042/fsl_device_registers.h | 35 + .../MIMXRT1042/gcc/startup_MIMXRT1042.S | 1100 + .../devices/MIMXRT1042/system_MIMXRT1042.c|229 + .../devices/MIMXRT1042/system_MIMXRT1042.h|118 + .../MIMXRT1042/xip/fsl_flexspi_nor_boot.c | 49 + .../MIMXRT1042/xip/fsl_flexspi_nor_boot.h |124 + .../mcux-sdk/devices/MIMXRT1051/MIMXRT1051.h | 49292 +++ .../devices/MIMXRT1051/MIMXRT1051_features.h |759 + .../devices/MIMXRT1051/drivers/fsl_clock.c| 1531 + .../devices/MIMXRT1051/drivers/fsl_clock.h| 2039 + .../MIMXRT1051/drivers/fsl_flexram_allocate.c | 86 + .../MIMXRT1051/drivers/fsl_flexram_allocate.h | 87 + .../devices/MIMXRT1051/drivers/fsl_iomuxc.h | 1241 + .../devices/MIMXRT1051/drivers/fsl_nic301.h |308 + .../devices/MIMXRT1051/drivers/fsl_romapi.c |162 + .../devices/MIMXRT1051/drivers/fsl_romapi.h |565 + .../devices/MIMXRT1051/fsl_device_registers.h | 36 + .../MIMXRT1051/gcc/startup_MIMXRT1051.S | 1077 + .../devices/MIMXRT1051/system_MIMXRT1051.c|242 +
[PATCH rtems 07/12] bsps/shared: Fix header for fsl-edma
If a different chip variant is used in the i.mxrt BSP, a different header would have to be included. Make sure that the fsl-edma driver uses a header that doesn't have to be adapted. --- bsps/shared/dev/dma/fsl-edma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsps/shared/dev/dma/fsl-edma.c b/bsps/shared/dev/dma/fsl-edma.c index b3e1bb2fc5..3cb91c14e6 100644 --- a/bsps/shared/dev/dma/fsl-edma.c +++ b/bsps/shared/dev/dma/fsl-edma.c @@ -40,7 +40,7 @@ #include #include #ifdef LIBBSP_ARM_IMXRT_BSP_H -#include +#include #endif #define EDMA_CHANNELS_PER_GROUP 32U -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 08/12] bsps/imxrt: Remove unmaintained defines
The defines for the different clock frequencies in the fsl_clock_config.h do not represent the clock frequencies that have been set up in the registers. Remove them to avoid someone trusting in correct values. --- bsps/arm/imxrt/include/fsl_clock_config.h | 58 +-- .../nxp/boards/evkbimxrt1050/clock_config.c | 2 +- 2 files changed, 4 insertions(+), 56 deletions(-) diff --git a/bsps/arm/imxrt/include/fsl_clock_config.h b/bsps/arm/imxrt/include/fsl_clock_config.h index f213ac7e23..5c09daf59d 100644 --- a/bsps/arm/imxrt/include/fsl_clock_config.h +++ b/bsps/arm/imxrt/include/fsl_clock_config.h @@ -8,6 +8,7 @@ #ifndef _CLOCK_CONFIG_H_ #define _CLOCK_CONFIG_H_ +#include #include "fsl_common.h" /*** @@ -34,61 +35,7 @@ void BOARD_InitBootClocks(void); } #endif /* __cplusplus*/ -/*** - ** Configuration BOARD_BootClockRUN *** - **/ -/*** - * Definitions for BOARD_BootClockRUN configuration - **/ -#define BOARD_BOOTCLOCKRUN_CORE_CLOCK 6U /*!< Core clock frequency: 6Hz */ - -/* Clock outputs (values are in Hz): */ -#define BOARD_BOOTCLOCKRUN_AHB_CLK_ROOT 6UL -#define BOARD_BOOTCLOCKRUN_CAN_CLK_ROOT 4000UL -#define BOARD_BOOTCLOCKRUN_CKIL_SYNC_CLK_ROOT 32768UL -#define BOARD_BOOTCLOCKRUN_CLKO1_CLK 0UL -#define BOARD_BOOTCLOCKRUN_CLKO2_CLK 0UL -#define BOARD_BOOTCLOCKRUN_CLK_1M 100UL -#define BOARD_BOOTCLOCKRUN_CLK_24M 2400UL -#define BOARD_BOOTCLOCKRUN_CSI_CLK_ROOT 1200UL -#define BOARD_BOOTCLOCKRUN_ENET1_TX_CLK 240UL -#define BOARD_BOOTCLOCKRUN_ENET_125M_CLK 240UL -#define BOARD_BOOTCLOCKRUN_ENET_25M_REF_CLK 120UL -#define BOARD_BOOTCLOCKRUN_FLEXIO1_CLK_ROOT 3000UL -#define BOARD_BOOTCLOCKRUN_FLEXIO2_CLK_ROOT 3000UL -#define BOARD_BOOTCLOCKRUN_FLEXSPI_CLK_ROOT 16000UL -#define BOARD_BOOTCLOCKRUN_GPT1_IPG_CLK_HIGHFREQ 7500UL -#define BOARD_BOOTCLOCKRUN_GPT2_IPG_CLK_HIGHFREQ 7500UL -#define BOARD_BOOTCLOCKRUN_IPG_CLK_ROOT 15000UL -#define BOARD_BOOTCLOCKRUN_LCDIF_CLK_ROOT 9642857UL -#define BOARD_BOOTCLOCKRUN_LPI2C_CLK_ROOT 6000UL -#define BOARD_BOOTCLOCKRUN_LPSPI_CLK_ROOT 10560UL -#define BOARD_BOOTCLOCKRUN_LVDS1_CLK 12UL -#define BOARD_BOOTCLOCKRUN_MQS_MCLK 63529411UL -#define BOARD_BOOTCLOCKRUN_PERCLK_CLK_ROOT 7500UL -#define BOARD_BOOTCLOCKRUN_PLL7_MAIN_CLK 2400UL -#define BOARD_BOOTCLOCKRUN_SAI1_CLK_ROOT 63529411UL -#define BOARD_BOOTCLOCKRUN_SAI1_MCLK1 63529411UL -#define BOARD_BOOTCLOCKRUN_SAI1_MCLK2 63529411UL -#define BOARD_BOOTCLOCKRUN_SAI1_MCLK3 3000UL -#define BOARD_BOOTCLOCKRUN_SAI2_CLK_ROOT 63529411UL -#define BOARD_BOOTCLOCKRUN_SAI2_MCLK1 63529411UL -#define BOARD_BOOTCLOCKRUN_SAI2_MCLK2 0UL -#define BOARD_BOOTCLOCKRUN_SAI2_MCLK3 3000UL -#define BOARD_BOOTCLOCKRUN_SAI3_CLK_ROOT 63529411UL -#define BOARD_BOOTCLOCKRUN_SAI3_MCLK1 63529411UL -#define BOARD_BOOTCLOCKRUN_SAI3_MCLK2 0UL -#define BOARD_BOOTCLOCKRUN_SAI3_MCLK3 3000UL -#define BOARD_BOOTCLOCKRUN_SEMC_CLK_ROOT 7500UL -#define BOARD_BOOTCLOCKRUN_SPDIF0_CLK_ROOT 3000UL -#define BOARD_BOOTCLOCKRUN_SPDIF0_EXTCLK_OUT 0UL -#define BOARD_BOOTCLOCKRUN_TRACE_CLK_ROOT 11733UL -#define BOARD_BOOTCLOCKRUN_UART_CLK_ROOT 8000UL -#define BOARD_BOOTCLOCKRUN_USBPHY1_CLK 0UL -#define BOARD_BOOTCLOCKRUN_USBPHY2_CLK 0UL -#define BOARD_BOOTCLOCKRUN_USDHC1_CLK_ROOT 19800UL -#define BOARD_BOOTCLOCKRUN_USDHC2_CLK_ROOT 19800UL - +#if IMXRT_IS_MIMXRT10xx /*! @brief Arm PLL set for BOARD_BootClockRUN configuration. */ extern const clock_arm_pll_config_t armPllConfig_BOARD_BootClockRUN; @@ -98,6 +45,7 @@ extern const clock_usb_pll_config_t usb1PllConfig_BOARD_BootClockRUN; /*! @brief Sys PLL for BOARD_BootClockRUN configuration. */ extern const clock_sys_pll_config_t sysPllConfig_BOARD_BootClockRUN; +#endif /*** * API for BOARD_BootClockRUN configuration diff --git a/bsps/arm/imxrt/nxp/boards/evkbimxrt1050/clock_config.c b/bsps/arm/imxrt/nxp/boards/evkbimxrt1050/clock_config.c index 4ab5216ee1..8f6980d0ef 100644 --- a/bsps/arm/imxrt/nxp/boards/evkbimxrt1050/clock_config.c +++ b/bsps/arm/imxrt/nxp/boards/evkbimxrt1050/clock_config.c @@ -487,5 +487,5 @@ void BOARD_BootClockRUN(void) /* Set GPT2 High frequency reference clock source. */ IOMUXC_GPR->GPR5 &= ~IOMUXC_GPR_GPR5_VREF_1M_CLK_GPT2_MASK; /* Set SystemCoreClock variable. */ -SystemCoreClock = BOARD_BOOTCLOCKRUN_CORE_CLOCK; +SystemCoreClock = 6U; } -- 2.35.3 ___
[PATCH rtems 09/12] bsps/imxrt: Support more chip variants in header
The different variants of the i.MXRT have some minimal differences in
the fsl_flexspi_nor_config.h. Make sure that the header supports the
different chips.
---
.../imxrt/include/fsl_flexspi_nor_config.h| 49 +++
1 file changed, 40 insertions(+), 9 deletions(-)
diff --git a/bsps/arm/imxrt/include/fsl_flexspi_nor_config.h
b/bsps/arm/imxrt/include/fsl_flexspi_nor_config.h
index 4a2a158f50..541eb7e68a 100644
--- a/bsps/arm/imxrt/include/fsl_flexspi_nor_config.h
+++ b/bsps/arm/imxrt/include/fsl_flexspi_nor_config.h
@@ -1,13 +1,14 @@
/*
- * Copyright (c) 2016, Freescale Semiconductor, Inc.
- * Copyright 2016-2017 NXP
+ * Copyright 2017-2020 NXP
* All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
+ *
+ * Based on file for EVKBIMSRT1050 with values for other EVKs integrated.
*/
-#ifndef __EVKBIMXRT1050_FLEXSPI_NOR_CONFIG__
-#define __EVKBIMXRT1050_FLEXSPI_NOR_CONFIG__
+#ifndef __FSL_FLEXSPI_NOR_CONFIG__
+#define __FSL_FLEXSPI_NOR_CONFIG__
#include
#include
@@ -15,8 +16,8 @@
/*! @name Driver version */
/*@{*/
-/*! @brief XIP_BOARD driver version 2.0.0. */
-#define FSL_XIP_BOARD_DRIVER_VERSION (MAKE_VERSION(2, 0, 0))
+/*! @brief XIP_BOARD driver version 2.0.1. */
+#define FSL_XIP_BOARD_DRIVER_VERSION (MAKE_VERSION(2, 0, 1))
/*@}*/
/* FLEXSPI memory config block related defintions */
@@ -82,11 +83,39 @@ typedef enum _FlexSpiSerialClockFreq
kFlexSpiSerialClk_30MHz = 1,
kFlexSpiSerialClk_50MHz = 2,
kFlexSpiSerialClk_60MHz = 3,
+#if defined(MIMXRT1011_SERIES)
+kFlexSpiSerialClk_75MHz = 4,
+kFlexSpiSerialClk_80MHz = 5,
+kFlexSpiSerialClk_100MHz = 6,
+kFlexSpiSerialClk_120MHz = 7,
+kFlexSpiSerialClk_133MHz = 8,
+#elif defined(MIMXRT1015_SERIES) || defined(MIMXRT1021_SERIES) ||
defined(MIMXRT1024_SERIES)
+kFlexSpiSerialClk_75MHz = 4,
+kFlexSpiSerialClk_80MHz = 5,
+kFlexSpiSerialClk_100MHz = 6,
+kFlexSpiSerialClk_133MHz = 7,
+#elif defined(MIMXRT1052_SERIES)
kFlexSpiSerialClk_75MHz = 4,
kFlexSpiSerialClk_80MHz = 5,
kFlexSpiSerialClk_100MHz = 6,
kFlexSpiSerialClk_133MHz = 7,
kFlexSpiSerialClk_166MHz = 8,
+#elif defined(MIMXRT1042_SERIES) || defined(MIMXRT1062_SERIES) ||
defined(MIMXRT1064_SERIES)
+kFlexSpiSerialClk_75MHz = 4,
+kFlexSpiSerialClk_80MHz = 5,
+kFlexSpiSerialClk_100MHz = 6,
+kFlexSpiSerialClk_120MHz = 7,
+kFlexSpiSerialClk_133MHz = 8,
+kFlexSpiSerialClk_166MHz = 9,
+#elif defined(MIMXRT1166_cm4_SERIES) || defined(MIMXRT1166_cm7_SERIES) || \
+ defined(MIMXRT1176_cm4_SERIES) || defined(MIMXRT1176_cm7_SERIES)
+kFlexSpiSerialClk_80MHz = 4,
+kFlexSpiSerialClk_100MHz = 5,
+kFlexSpiSerialClk_120MHz = 6,
+kFlexSpiSerialClk_133MHz = 7,
+kFlexSpiSerialClk_166MHz = 8,
+kFlexSpiSerialClk_200MHz = 9,
+#endif
} flexspi_serial_clk_freq_t;
//!@brief FlexSPI clock configuration type
@@ -249,13 +278,15 @@ typedef struct _flexspi_nor_config
uint32_t sectorSize;//!< Sector size of Serial NOR
uint8_t ipcmdSerialClkFreq; //!< Clock frequency for IP command
uint8_t isUniformBlockSize; //!< Sector/Block size is the same
-uint8_t reserved0[2]; //!< Reserved for future use
+uint8_t isDataOrderSwapped; //!< The data order is swapped in OPI DDR
mode (only i.MXRT11*)
+uint8_t reserved0; //!< Reserved for future use
uint8_t serialNorType; //!< Serial NOR Flash type: 0/1/2/3
uint8_t needExitNoCmdMode; //!< Need to exit NoCmd mode before other
IP command
uint8_t halfClkForNonReadCmd; //!< Half the Serial Clock for non-read
command: true/false
uint8_t needRestoreNoCmdMode; //!< Need to Restore NoCmd mode after IP
commmand execution
uint32_t blockSize; //!< Block size
-uint32_t reserve2[11]; //!< Reserved for future use
+uint32_t FlashStateCtx; //!< Flash State Context after being
configured (only i.MXRT11*)
+uint32_t reserve2[10]; //!< Reserved for future use
} flexspi_nor_config_t;
#ifdef __cplusplus
@@ -265,4 +296,4 @@ extern "C" {
#ifdef __cplusplus
}
#endif
-#endif /* __EVKBIMXRT1050_FLEXSPI_NOR_CONFIG__ */
+#endif /* __FSL_FLEXSPI_NOR_CONFIG__ */
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 06/12] bsps/imxrt: Get clock for IMXRT11xx in drivers
The mcux_sdk has a different interface for getting the clock for
IMXRT11xx than for getting it in IMXRT10xx. Adapt simple drivers to
support that interface.
---
bsps/arm/imxrt/console/console.c | 35 +--
bsps/arm/imxrt/i2c/imxrt-lpi2c.c | 18 --
.../imxrt/mcux-sdk/drivers/qtmr_1/fsl_qtmr.c | 8 +
bsps/arm/imxrt/spi/imxrt-lpspi.c | 18 --
4 files changed, 73 insertions(+), 6 deletions(-)
diff --git a/bsps/arm/imxrt/console/console.c b/bsps/arm/imxrt/console/console.c
index 05320f2c4c..e3f6a091c6 100644
--- a/bsps/arm/imxrt/console/console.c
+++ b/bsps/arm/imxrt/console/console.c
@@ -53,6 +53,7 @@ typedef struct {
volatile LPUART_Type *regs;
rtems_vector_number irq;
const char *path;
+ clock_ip_name_t clock_ip;
uint32_t src_clock_hz;
lpuart_config_t config;
} imxrt_lpuart_context;
@@ -174,12 +175,15 @@ static bool imxrt_lpuart_set_attributes(
return true;
}
-static uint32_t imxrt_lpuart_get_src_freq(void)
+static uint32_t imxrt_lpuart_get_src_freq(clock_ip_name_t clock_ip)
{
uint32_t freq;
+#if IMXRT_IS_MIMXRT10xx
uint32_t mux;
uint32_t divider;
+ (void) clock_ip; /* Not necessary for i.MXRT1050 */
+
mux = CLOCK_GetMux(kCLOCK_UartMux);
divider = 1;
@@ -197,10 +201,36 @@ static uint32_t imxrt_lpuart_get_src_freq(void)
divider *= CLOCK_GetDiv(kCLOCK_UartDiv) + 1U;
freq /= divider;
+#elif IMXRT_IS_MIMXRT11xx
+ /*
+ * FIXME: A future version of the mcux_sdk might provide a better method to
+ * get the clock instead of this hack.
+ */
+ clock_root_t clock_root = clock_ip + kCLOCK_Root_Lpuart1 - kCLOCK_Lpuart1;
+
+ freq = CLOCK_GetRootClockFreq(clock_root);
+#else
+ #error Getting UART clock frequency is not implemented for this chip
+#endif
return freq;
}
+static clock_ip_name_t imxrt_lpuart_clock_ip(volatile LPUART_Type *regs)
+{
+ LPUART_Type *const base_addresses[] = LPUART_BASE_PTRS;
+ static const clock_ip_name_t lpuart_clocks[] = LPUART_CLOCKS;
+ size_t i;
+
+ for (i = 0; i < RTEMS_ARRAY_SIZE(base_addresses); ++i) {
+if (base_addresses[i] == regs) {
+ return lpuart_clocks[i];
+}
+ }
+
+ return kCLOCK_IpInvalid;
+}
+
static void imxrt_lpuart_init_hardware(imxrt_lpuart_context *ctx)
{
(void) LPUART_Init((LPUART_Type *)ctx->regs, >config,
@@ -378,7 +408,8 @@ static void imxrt_lpuart_init_context_from_fdt(
bsp_fatal(IMXRT_FATAL_LPI2C_INVALID_FDT);
}
- ctx->src_clock_hz = imxrt_lpuart_get_src_freq();
+ ctx->clock_ip = imxrt_lpuart_clock_ip(ctx->regs);
+ ctx->src_clock_hz = imxrt_lpuart_get_src_freq(ctx->clock_ip);
LPUART_GetDefaultConfig(>config);
ctx->config.enableTx = true;
diff --git a/bsps/arm/imxrt/i2c/imxrt-lpi2c.c b/bsps/arm/imxrt/i2c/imxrt-lpi2c.c
index 783c6e18e6..d3aebc45e0 100644
--- a/bsps/arm/imxrt/i2c/imxrt-lpi2c.c
+++ b/bsps/arm/imxrt/i2c/imxrt-lpi2c.c
@@ -373,12 +373,15 @@ static int imxrt_lpi2c_hw_init(struct imxrt_lpi2c_bus
*bus)
return 0;
}
-static uint32_t imxrt_lpi2c_get_src_freq(void)
+static uint32_t imxrt_lpi2c_get_src_freq(clock_ip_name_t clock_ip)
{
uint32_t freq;
+#if IMXRT_IS_MIMXRT10xx
uint32_t mux;
uint32_t divider;
+ (void) clock_ip; /* Not necessary for i.MXRT1050 */
+
mux = CLOCK_GetMux(kCLOCK_Lpi2cMux);
divider = 1;
@@ -396,6 +399,17 @@ static uint32_t imxrt_lpi2c_get_src_freq(void)
divider *= CLOCK_GetDiv(kCLOCK_Lpi2cDiv) + 1;
freq /= divider;
+#elif IMXRT_IS_MIMXRT11xx
+ /*
+ * FIXME: A future version of the mcux_sdk might provide a better method to
+ * get the clock instead of this hack.
+ */
+ clock_root_t clock_root = clock_ip + kCLOCK_Root_Lpi2c1 - kCLOCK_Lpi2c1;
+
+ freq = CLOCK_GetRootClockFreq(clock_root);
+#else
+ #error Getting I2C frequency is not implemented for this chip.
+#endif
return freq;
}
@@ -457,7 +471,7 @@ void imxrt_lpi2c_init(void)
}
bus->clock_ip = imxrt_lpi2c_clock_ip(bus->regs);
- bus->src_clock_hz = imxrt_lpi2c_get_src_freq();
+ bus->src_clock_hz = imxrt_lpi2c_get_src_freq(bus->clock_ip);
eno = imxrt_lpi2c_hw_init(bus);
if (eno != 0) {
diff --git a/bsps/arm/imxrt/mcux-sdk/drivers/qtmr_1/fsl_qtmr.c
b/bsps/arm/imxrt/mcux-sdk/drivers/qtmr_1/fsl_qtmr.c
index a4e393896b..4c8bd71be5 100644
--- a/bsps/arm/imxrt/mcux-sdk/drivers/qtmr_1/fsl_qtmr.c
+++ b/bsps/arm/imxrt/mcux-sdk/drivers/qtmr_1/fsl_qtmr.c
@@ -92,9 +92,17 @@ rtems_vector_number QTMR_get_IRQ_from_fdt(const void *fdt,
int node)
uint32_t QTMR_get_src_clk(TMR_Type *base)
{
+#if IMXRT_IS_MIMXRT10xx
(void) base;
return CLOCK_GetFreq(kCLOCK_IpgClk);
+#elif IMXRT_IS_MIMXRT11xx
+(void) base;
+
+return CLOCK_GetRootClockMux(kCLOCK_Root_Bus);
+#else
+ #error Getting Timer clock frequency is not implemented for this chip
+#endif
}
#endif /* __rtems__ */
diff --git a/bsps/arm/imxrt/spi/imxrt-lpspi.c b/bsps/arm/imxrt/spi/imxrt-lpspi.c
index 80b47f9663..62503e4bd8 100644
---
[PATCH rtems 04/12] bsps/imxrt: Adapt to new mcux-sdk version
Remove the old NXP MCUXpresso SDK and adapt the BSP so that it uses the new mcux-sdk. NOTE: Due to the size, this is only the summary of the patch. You can find the full version here: https://gitlab.com/c-mauderer/rtems/-/commit/2a871672767a95598e5af42373bfebd3eb9440d3 --- bsps/arm/imxrt/include/MIMXRT1052.h | 46183 bsps/arm/imxrt/include/MIMXRT1052_features.h | 688 - bsps/arm/imxrt/include/bsp.h | 1 + bsps/arm/imxrt/include/chip.h | 3 +- bsps/arm/imxrt/include/fsl_adc.h | 427 - bsps/arm/imxrt/include/fsl_adc_etc.h | 336 - bsps/arm/imxrt/include/fsl_aipstz.h | 134 - bsps/arm/imxrt/include/fsl_aoi.h | 186 - bsps/arm/imxrt/include/fsl_bee.h | 254 - bsps/arm/imxrt/include/fsl_cache.h| 457 - bsps/arm/imxrt/include/fsl_clock.h| 1550 - bsps/arm/imxrt/include/fsl_cmp.h | 321 - bsps/arm/imxrt/include/fsl_common.h | 967 - bsps/arm/imxrt/include/fsl_csi.h | 724 - bsps/arm/imxrt/include/fsl_dcdc.h | 496 - bsps/arm/imxrt/include/fsl_dcp.h | 569 - bsps/arm/imxrt/include/fsl_device_registers.h |41 - bsps/arm/imxrt/include/fsl_dmamux.h | 177 - bsps/arm/imxrt/include/fsl_edma.h | 951 - bsps/arm/imxrt/include/fsl_elcdif.h | 747 - bsps/arm/imxrt/include/fsl_enc.h | 458 - bsps/arm/imxrt/include/fsl_enet.h | 1855 - bsps/arm/imxrt/include/fsl_ewm.h | 218 - bsps/arm/imxrt/include/fsl_flexcan.h | 1422 - bsps/arm/imxrt/include/fsl_flexio.h | 700 - bsps/arm/imxrt/include/fsl_flexio_camera.h| 230 - .../imxrt/include/fsl_flexio_camera_edma.h| 130 - .../arm/imxrt/include/fsl_flexio_i2c_master.h | 486 - bsps/arm/imxrt/include/fsl_flexio_i2s.h | 560 - bsps/arm/imxrt/include/fsl_flexio_i2s_edma.h | 203 - bsps/arm/imxrt/include/fsl_flexio_mculcd.h| 685 - .../imxrt/include/fsl_flexio_mculcd_edma.h| 153 - bsps/arm/imxrt/include/fsl_flexio_spi.h | 702 - bsps/arm/imxrt/include/fsl_flexio_spi_edma.h | 207 - bsps/arm/imxrt/include/fsl_flexio_uart.h | 570 - bsps/arm/imxrt/include/fsl_flexio_uart_edma.h | 178 - bsps/arm/imxrt/include/fsl_flexram.h | 276 - bsps/arm/imxrt/include/fsl_flexram_allocate.h |99 - bsps/arm/imxrt/include/fsl_flexspi.h | 837 - bsps/arm/imxrt/include/fsl_flexspi_nor_boot.h | 130 - bsps/arm/imxrt/include/fsl_gpc.h | 231 - bsps/arm/imxrt/include/fsl_gpio.h | 342 - bsps/arm/imxrt/include/fsl_gpt.h | 509 - bsps/arm/imxrt/include/fsl_iomuxc.h | 1242 - bsps/arm/imxrt/include/fsl_kpp.h | 180 - bsps/arm/imxrt/include/fsl_lpi2c.h| 1266 - bsps/arm/imxrt/include/fsl_lpi2c_edma.h | 157 - bsps/arm/imxrt/include/fsl_lpspi.h| 1122 - bsps/arm/imxrt/include/fsl_lpspi_edma.h | 301 - bsps/arm/imxrt/include/fsl_lpuart.h | 866 - bsps/arm/imxrt/include/fsl_lpuart_edma.h | 173 - bsps/arm/imxrt/include/fsl_ocotp.h| 153 - bsps/arm/imxrt/include/fsl_pin_mux.h | 942 - bsps/arm/imxrt/include/fsl_pit.h | 332 - bsps/arm/imxrt/include/fsl_pmu.h | 671 - bsps/arm/imxrt/include/fsl_pwm.h | 987 - bsps/arm/imxrt/include/fsl_pxp.h | 1438 - bsps/arm/imxrt/include/fsl_qtmr.h | 473 - bsps/arm/imxrt/include/fsl_rtwdog.h | 425 - bsps/arm/imxrt/include/fsl_sai.h | 1572 - bsps/arm/imxrt/include/fsl_sai_edma.h | 268 - bsps/arm/imxrt/include/fsl_semc.h | 831 - bsps/arm/imxrt/include/fsl_snvs_hp.h | 626 - bsps/arm/imxrt/include/fsl_snvs_lp.h | 555 - bsps/arm/imxrt/include/fsl_spdif.h| 746 - bsps/arm/imxrt/include/fsl_spdif_edma.h | 192 - bsps/arm/imxrt/include/fsl_src.h | 602 - bsps/arm/imxrt/include/fsl_tempmon.h | 126 - bsps/arm/imxrt/include/fsl_trng.h | 228 - bsps/arm/imxrt/include/fsl_tsc.h | 524 - bsps/arm/imxrt/include/fsl_usdhc.h| 1581 - bsps/arm/imxrt/include/fsl_wdog.h | 305 - bsps/arm/imxrt/include/fsl_xbara.h| 183 - bsps/arm/imxrt/include/fsl_xbarb.h|82 - bsps/arm/imxrt/include/system_MIMXRT1052.h| 129 - .../imxrt/nxp/boards/evkbimxrt1050/pin_mux.c | 1073 +- .../nxp/devices/MIMXRT1052/drivers/fsl_adc.c | 395 - .../devices/MIMXRT1052/drivers/fsl_adc_etc.c | 433 - .../devices/MIMXRT1052/drivers/fsl_aipstz.c |51 - .../nxp/devices/MIMXRT1052/drivers/fsl_aoi.c | 214 - .../nxp/devices/MIMXRT1052/drivers/fsl_bee.c | 303 - .../devices/MIMXRT1052/drivers/fsl_cache.c| 602 -
[PATCH rtems 00/12] bsp/imxrt: Update SDK and prepare for new variant
Hello, this patch set for the arm/imxrt BSP family updates the SDK files to the latest version of the mcux-sdk from NXP and prepares the BSP for further chip variants. I plan to add a BSP that uses the IMXRT1166 soon. As a base for the mcux-sdk files, I now use the NXP git repository instead of zip files that can be downloaded from NXP. I kept the exact file system structure to make future updates simpler. To import the files, I used a script. It is not a clean script and it was only tested on a Linux machine. Despite that, I added that script to the BSP directory in case someone else ever wants to update the mcux-sdk. Updating the SDK is also possible without the script. It's just a lot more manual work. So if we don't want a script in that state in the repository, I can also just keep it on a private branch. The patches that import the new SDK files (patch 0002) and remove the old ones (patch 0004) are too big for the list. I'll only send the summary. You can find the full patches here: 0002: https://gitlab.com/c-mauderer/rtems/-/commit/2a871672767a95598e5af42373bfebd3eb9440d3 0004: https://gitlab.com/c-mauderer/rtems/-/commit/2a3e104fa808d7f34a1930344d7b39d11cf39f3d The complete patch set is on this branch: https://gitlab.com/c-mauderer/rtems/-/commits/cm/20230504_imxrt/ At the moment, I import the support files for all currently available i.MXRT* variants. The headers for the CPU registers are really big (a few megabytes per header) which makes the complete source tree of the mcux-sdk bigger than 90MB. If preferred, I can remove most variants and only keep the ones that are currently used or will be used soon (IMXRT1052 and IMXRT1166) to reduce the size. Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 01/12] bsp/imxrt: Add script to import mcux-sdk
NXP now offers the support library in a mcux-sdk git repository instead
of in zip files. The git repository supports multiple controllers of the
i.MXRT family instead of a single one.
This commit adds a script that is a (very hacky) parser for the the
cmake files in the mcux-sdk. It copies all necessary files and creates
yml spec files for the controllers that have been imported.
The script is only intended as a helper for updating the files. It is
not necessary for using the BSP.
---
bsps/arm/imxrt/import_from_mcux_sdk.py | 293 +
1 file changed, 293 insertions(+)
create mode 100755 bsps/arm/imxrt/import_from_mcux_sdk.py
diff --git a/bsps/arm/imxrt/import_from_mcux_sdk.py
b/bsps/arm/imxrt/import_from_mcux_sdk.py
new file mode 100755
index 00..2dfe224865
--- /dev/null
+++ b/bsps/arm/imxrt/import_from_mcux_sdk.py
@@ -0,0 +1,293 @@
+#!/usr/bin/env python3
+
+""" Parse the cmake files from mcux_sdk and import the sources to RTEMS.
+This script is a ugly hack and it might doesn't work with newer mcux_sdk
+versions.
+
+Provide a number of the cmake files in `devices/MIMXRT*/all_lib_device_*.cmake`
+as parameter to this script. The file format is expected to be quite fixed.
+Don't give anything else to the script. It won't work.
+"""
+
+import argparse
+import logging
+from enum import Enum
+from pathlib import Path
+import re
+from slugify import slugify
+import shutil
+import yaml
+
+class states(Enum):
+IDLE = 0
+ADD_MODULE_PATH = 1
+ADD_CFILES = 2
+ADD_HFILES = 3
+SKIP_TILL_ENDIF = 4
+
+def find_file(name, paths):
+for p in paths:
+path = Path(p)
+f = path / f'{name}.cmake'
+if f.exists():
+return f.resolve(strict=True)
+return None
+
+def get_path_from_line(line, cmake, rel_to = None):
+current_list_dir = str(Path(cmake.name).parent.resolve())
+path = line.strip().replace("${CMAKE_CURRENT_LIST_DIR}", current_list_dir)
+path = Path(path)
+if rel_to is not None:
+p = Path(path)
+path = p.relative_to(rel_to)
+return path
+
+def parse_cmake(cmake, mcux_device, module_path = [], rel_to = None, stack =
[]):
+logger.info(f"Parse file: {cmake.name}")
+if rel_to is None:
+rel_to = Path(cmake.name).parent.resolve()
+mod_path = module_path.copy()
+state = states.IDLE
+cfiles = []
+hpaths = []
+
+# prevent loops
+if cmake.name in stack:
+logger.warning(f"Loop detected: {' -> '.join(stack)}")
+return cfiles, hpaths
+# Use a shallow copy!
+stack_work = stack[:] + [cmake.name]
+
+for line in cmake:
+logger.debug(f"state: {state}; file: {cmake.name}; line
'{line.strip()}'")
+
+if state == states.IDLE:
+if "if(${MCUX_DEVICE} STREQUAL " in line:
+equal_to = re.search(r'"(.*)"', line).group(1)
+if equal_to == mcux_device:
+logger.debug(f"MCUX matches {equal_to}")
+else:
+logger.debug(f"MCUX ({mcux_device}) not equal to
{equal_to}")
+state = states.SKIP_TILL_ENDIF
+elif "endif()" in line:
+state = states.IDLE
+elif ("list" in line) and ("APPEND" in line) and
("CMAKE_MODULE_PATH" in line):
+state = states.ADD_MODULE_PATH
+elif ("target_sources" in line):
+state = states.ADD_CFILES
+elif ("target_include_directories" in line):
+state = states.ADD_HFILES
+elif ("include(" in line):
+# NOTE: This will also include commented lines. This is
+# necessary because NXP only added the includes as an example
to
+# the all_lib_device_*.cmake files.
+to_include = re.search(r"\((.*)\)", line).group(1)
+included = find_file(to_include, mod_path)
+logger.debug(f"Search include file: {to_include}; found
{included}")
+if included is None:
+# log unexpected misses
+if not (to_include.startswith("middleware") or \
+to_include.startswith("CMSIS")):
+logger.error(f"can't find {to_include}")
+elif "rtos" in to_include:
+logger.info("Skip include for other RTOS: ${to_include}")
+elif "utility" in to_include:
+logger.info("Skip utilities: ${to_include}")
+elif "caam" in to_include:
+logger.info("Filter non working driver: ${to_include}")
+elif included.relative_to(rel_to).parts[0] == "drivers" or \
+included.relative_to(rel_to).parts[0] == "devices":
+# we are only interested in drivers
+with open(included, "r") as f:
+cf, hp = parse_cmake(f, mcux_device, mod_path, rel_to,
[PATCH rtems 05/12] bsps/imxrt1052: PLL config based on speed grade
---
bsps/arm/imxrt/start/clock-arm-pll-config.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/bsps/arm/imxrt/start/clock-arm-pll-config.c
b/bsps/arm/imxrt/start/clock-arm-pll-config.c
index 12ad1867eb..2a0148e73a 100644
--- a/bsps/arm/imxrt/start/clock-arm-pll-config.c
+++ b/bsps/arm/imxrt/start/clock-arm-pll-config.c
@@ -26,8 +26,15 @@
*/
#include "fsl_clock_config.h"
+#include
const clock_arm_pll_config_t armPllConfig_BOARD_BootClockRUN = {
+#if (IMXRT_SPEEDGRADE == '6')
.loopDivider = 100,
+#elif (IMXRT_SPEEDGRADE == '5')
+.loopDivider = 88,
+#else
+#error unknown speed grade of i.MXRT processor
+#endif
.src = 0,
};
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: New GPIO-API merged?
Hello Jan, Duc Doan worked on that topic during his GSoC project last year: https://github.com/dtbpkmte/GSoC-2022-RTEMS https://github.com/dtbpkmte/GSoC-2022-RTEMS/commit/0aec268f1209c https://medium.com/@dtbpkmte The results looked quite interesting (even if some functions were still missing like switching GPIO groups). But at the end there was a problem with the Apache license of the STM libraries so that the new API would have been left without a reference implementation. The API in the current bsp/gpio.h is designed to match a certain GPIO hardware module structure. It is currently implemented only on raspberry and beagle. For every GPIO module that doesn't match the structure, it adds quite some overhead. For example on the i.MX I tried to use it and gave up soon because mapping the structure would have wasted a lot of CPU cycles. Best regards Christian On 2023-02-28 10:06, jan.som...@dlr.de wrote: We now found this general GPIO API here: https://github.com/RTEMS/rtems/blob/master/bsps/include/bsp/gpio.h Is this the current one to use when implementing a new GPIO driver? -Original Message- From: devel On Behalf Of jan.som...@dlr.de Sent: Mittwoch, 15. Februar 2023 08:40 To: devel@rtems.org Subject: New GPIO-API merged? Hello everyone, Alex' patch reminded me that there was work done related a new general GPIO-API. Has that been finished? I tried to find the corresponding header files, but couldn't. So, I was wondering what the current status is. Best regards, Jan Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR) German Aerospace Center Institute for Software Technology | Software for Space Systems and Interactive Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany ___ 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 -- embedded brains GmbH Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 mobile: +49-176-152 206 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
