Re: RPi 4B MMU seems to be enabled but throwing aarch64-default-exception error
Hey Noor, I probably have more questions than answers at this point, as I'm just learning how all of this works too. Some comments inline below: On Sun, Sep 4, 2022 at 6:13 AM Noor Aman wrote: > Hey, > Some doubts here: > 1) On inspecting the raspberry pi 3 config table, I only seem to have 2 > entries, one is for peripheral base, the other one for core local > peripherals. I have updated the MMU with peripheral base, ARM local > registers, and ARMC register. If I'm correct then, the Videocore should > handle every address of uarts, spi and others, right? or am I missing > something? > Does the RAM need to be included? For example, the xilinx-versal BSP has an entry for RAM, but the xilinx-zynqmp does not. The RT-Thread Memory/MMU table has more entries than we need for GIC/UART/Timer/RAM right now, but would those ranges cover the complete set of peripherals and RAM? I'm not sure why the memory entry they have only covers 100Mbytes of RAM: https://github.com/RT-Thread/rt-thread/blob/master/bsp/raspberry-pi/raspi4-64/driver/board.c#L25 > 2) Raspberry pi 3 kernel starts from 0x20 and the MMU is mapped > starting from 0x10. My question is if the aarch64 kernel starts from > 0x8, then where should the MMU start from? I'm assuming it does not > start from 0x0 because my current code's MMU starts from that and it's very > likely that this is causing problems. > > Figure 1 in the BCM2711 shows the different memory mapping modes: https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf I believe we should be looking at the one on the right "ARM view of the address map in low peripheral mode". The "ARM view" here shows the RAM at 0x0. Having the kernel at 0x8 fits in this view. In other words, the ARM view has memory start at 0 and the kernel is loaded at the 0x8 offset. 3) Any more suggestions? Glad to receive them. > In the bsp.h file, I think the defines need to be changed: #define BSP_RPI4_PL011_BASE 0x7e201000 should be #define BSP_RPI4_PL011_BASE 0xFE201000 That matches what I see in RT-Thread, and makes sense given the following from the peripherals guide: "If the VPU enables "Low Peripheral" mode then the ARM (only) has Main peripherals available from 0x0_FC00_ to 0x0_FF7F_ and ARM Local peripherals available from 0x0_FF80_ to 0x0__. So a peripheral described in this document as being at legacy address 0x7Enn_ is available in the 35-bit address space at 0x4_7Enn_, and visible to the ARM at 0x0_FEnn_ if Low Peripheral mode is enabled." So what about the GIC addresses? In bsp.h you have: #define BSP_ARM_GIC_CPUIF_BASE 0x0801 #define BSP_ARM_GIC_DIST_BASE 0x0800 #define BSP_ARM_GIC_REDIST_BASE 0x080A In RT-Thread they use addresses starting at 0xFF84 (I think..) Should these be offset as well? Thanks, Alan > Thanks, > Noor > > On Sat, 3 Sept 2022 at 22:05, Alan Cudmore wrote: > >> Hi Noor, >> >> Nice blog entry on the JTAG setup. I ordered the FT232H board like yours >> to see if I can get the same setup working. I have my Pi 4 running the bare >> metal OS examples, and I have built your branch, so I hope to start looking >> at the code. >> >> What needs to be in the MMU table? I see different entries in the Aarch64 >> BSPs. For example the Xilinx-versal BSP has entries for the GIC, >> peripherals, and memory. Can you cover RAM and I/O space on the Pi 4 with >> just one entry? >> >> Looking at the RT-Thread OS, they have the following Pi4/Aarch64 MMU >> table: >> >> >> https://github.com/RT-Thread/rt-thread/blob/master/bsp/raspberry-pi/raspi4-64/driver/board.c#L25 >> >> >> >> Alan >> >> *From: *Noor Aman >> *Sent: *Friday, September 2, 2022 2:18 PM >> *To: *Alan Cudmore >> *Cc: *Hesham Moustafa ; William Moore >> ; rtems-de...@rtems.org >> *Subject: *Re: RPi 4B MMU seems to be enabled but throwing >> aarch64-default-exception error >> >> >> >> Openocd connection is on my website. Here's the link to that. >> https://0xnoor.hashnode.dev/setup-openocd-with-jtag-uart-on-raspberry-pi-4-using-ft232h >> >> >> >> I pushed the code to my github repo. Be sure to checkout noor-dev branch. >> Here's the link for that. https://github.com/0xnoor/rtems >> >> >> >> And yes the code looks bad as of now, I'll do optimization and everything >> soon. >> >> >> >> Thanks >> >> >> >> On Fri, 2 Sept 2022 at 23:31, Alan Cudmore >> wrote: >> >> Hi Noor, >> >> Can you describe the setup you use for testing the BSP? >> >> I can set up my Pi 4 to try running your code as you update it. How do >> you setup the OCD connection? >> >> >> >> Thanks, >> >> Alan >> >> >> >> On Fri, Sep 2, 2022 at 11:48 AM Noor Aman wrote: >> >> Hey all, >> >> Raspberry Pi 4B MMU seems to be enabled, as reported by openocd but gdb >> is showing to run in a loop from aarch64-defaulit-exception.S file starting >> from code line number 143 to 220. >> >> >> >> From what I can gather, it is being caused by the wrong MMU address. >> >> Here's a RAM and MMU allocation sizes
Re: [PATCH rtems-lwip 4/5] lwip.py: Add STM32 lwIP port to build
Hello Chris,
Thank you for pointing them out. I'll fix them in the next patch set.
Best,
Duc
On Mon, 2022-09-05 at 09:05 +1000, Chris Johns wrote:
> On 4/9/2022 11:25 am, Duc Doan wrote:
> > ---
> > lwip.py | 20 +++-
> > 1 file changed, 19 insertions(+), 1 deletion(-)
> >
> > diff --git a/lwip.py b/lwip.py
> > index 84eef2c..d806b64 100644
> > --- a/lwip.py
> > +++ b/lwip.py
> > @@ -92,6 +92,17 @@ common_source_files = [
> > 'rtemslwip/bsd_compat/rtems-kernel-program.c'
> > ]
> >
> > +stm32f4_drv_incl = [
> > + 'rtemslwip/stm32f4',
> > + 'stm32',
> > + 'stm32/driver'
> > +]
> > +
> > +stm32f4_drv_src = [
> > + 'stm32',
> > + 'stm32/driver'
> > +]
> > +
>
> Please group the BSP specific file sets together rather than
> spreading them
> across the common source files. I suggest after the Xilinx ones.
>
> > def build(bld):
> > source_files = []
> > @@ -150,13 +161,20 @@ def build(bld):
> >
> > driver_source.extend(walk_sources('rtemslwip/zynqmp_hardware'))
> > driver_source.extend(xilinx_aarch64_driver_source)
> > drv_incl.extend(xilinx_aarch64_drv_incl)
> > +
> > + # These files will only compile for STM32F4 BSPs
> > + if bld.env.RTEMS_ARCH_BSP.startswith('arm-rtems6-stm32f4'):
>
> This is wrong because the version is hard coded. I see you have
> copied what is
> in the file and they are also wrong.
>
> The formal arch and bsp format is arch/bsp and these tests expose an
> internal
> implementation detail from rtems_waf.
>
> I suggest the code be changed to add:
>
> arch = rtems.arch(bld.env.RTEMS_ARCH_BSP)
> bsp = rtems.bsp(bld.env.RTEMS_ARCH_BSP)
>
> and all the tests changed to:
>
> if arch == 'arm' and bsp == 'stm32f4':
>
> > + driver_source.extend(walk_sources('rtemslwip/stm32f4'))
> > + drv_incl.extend(stm32f4_drv_incl)
> > + for s in stm32f4_drv_src:
> > + driver_source.extend(walk_sources(s))
> >
> > lwip_obj_incl = []
> > lwip_obj_incl.extend(drv_incl)
> > lwip_obj_incl.extend(bsd_compat_incl)
> > lwip_obj_incl.extend(common_includes)
> >
> > - bld(features='c',
> > + bld(features ='c',
>
> The coding standard tool has the previous format.
>
> > target='lwip_obj',
> > cflags='-g -Wall -O0',
> > includes=' '.join(lwip_obj_incl),
>
> Thanks
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip 4/5] lwip.py: Add STM32 lwIP port to build
On 4/9/2022 11:25 am, Duc Doan wrote:
> ---
> lwip.py | 20 +++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/lwip.py b/lwip.py
> index 84eef2c..d806b64 100644
> --- a/lwip.py
> +++ b/lwip.py
> @@ -92,6 +92,17 @@ common_source_files = [
> 'rtemslwip/bsd_compat/rtems-kernel-program.c'
> ]
>
> +stm32f4_drv_incl = [
> +'rtemslwip/stm32f4',
> +'stm32',
> +'stm32/driver'
> +]
> +
> +stm32f4_drv_src = [
> +'stm32',
> +'stm32/driver'
> +]
> +
Please group the BSP specific file sets together rather than spreading them
across the common source files. I suggest after the Xilinx ones.
> def build(bld):
> source_files = []
> @@ -150,13 +161,20 @@ def build(bld):
>
> driver_source.extend(walk_sources('rtemslwip/zynqmp_hardware'))
> driver_source.extend(xilinx_aarch64_driver_source)
> drv_incl.extend(xilinx_aarch64_drv_incl)
> +
> +# These files will only compile for STM32F4 BSPs
> +if bld.env.RTEMS_ARCH_BSP.startswith('arm-rtems6-stm32f4'):
This is wrong because the version is hard coded. I see you have copied what is
in the file and they are also wrong.
The formal arch and bsp format is arch/bsp and these tests expose an internal
implementation detail from rtems_waf.
I suggest the code be changed to add:
arch = rtems.arch(bld.env.RTEMS_ARCH_BSP)
bsp = rtems.bsp(bld.env.RTEMS_ARCH_BSP)
and all the tests changed to:
if arch == 'arm' and bsp == 'stm32f4':
> +driver_source.extend(walk_sources('rtemslwip/stm32f4'))
> +drv_incl.extend(stm32f4_drv_incl)
> +for s in stm32f4_drv_src:
> +driver_source.extend(walk_sources(s))
>
> lwip_obj_incl = []
> lwip_obj_incl.extend(drv_incl)
> lwip_obj_incl.extend(bsd_compat_incl)
> lwip_obj_incl.extend(common_includes)
>
> -bld(features='c',
> +bld(features ='c',
The coding standard tool has the previous format.
> target='lwip_obj',
> cflags='-g -Wall -O0',
> includes=' '.join(lwip_obj_incl),
Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: RPi 4B MMU seems to be enabled but throwing aarch64-default-exception error
Hey,
Some doubts here:
1) On inspecting the raspberry pi 3 config table, I only seem to have 2
entries, one is for peripheral base, the other one for core local
peripherals. I have updated the MMU with peripheral base, ARM local
registers, and ARMC register. If I'm correct then, the Videocore should
handle every address of uarts, spi and others, right? or am I missing
something?
2) Raspberry pi 3 kernel starts from 0x20 and the MMU is mapped
starting from 0x10. My question is if the aarch64 kernel starts from
0x8, then where should the MMU start from? I'm assuming it does not
start from 0x0 because my current code's MMU starts from that and it's very
likely that this is causing problems.
3) Any more suggestions? Glad to receive them.
Thanks,
Noor
On Sat, 3 Sept 2022 at 22:05, Alan Cudmore wrote:
> Hi Noor,
>
> Nice blog entry on the JTAG setup. I ordered the FT232H board like yours
> to see if I can get the same setup working. I have my Pi 4 running the bare
> metal OS examples, and I have built your branch, so I hope to start looking
> at the code.
>
> What needs to be in the MMU table? I see different entries in the Aarch64
> BSPs. For example the Xilinx-versal BSP has entries for the GIC,
> peripherals, and memory. Can you cover RAM and I/O space on the Pi 4 with
> just one entry?
>
> Looking at the RT-Thread OS, they have the following Pi4/Aarch64 MMU table:
>
>
> https://github.com/RT-Thread/rt-thread/blob/master/bsp/raspberry-pi/raspi4-64/driver/board.c#L25
>
>
>
> Alan
>
> *From: *Noor Aman
> *Sent: *Friday, September 2, 2022 2:18 PM
> *To: *Alan Cudmore
> *Cc: *Hesham Moustafa ; William Moore
> ; rtems-de...@rtems.org
> *Subject: *Re: RPi 4B MMU seems to be enabled but throwing
> aarch64-default-exception error
>
>
>
> Openocd connection is on my website. Here's the link to that.
> https://0xnoor.hashnode.dev/setup-openocd-with-jtag-uart-on-raspberry-pi-4-using-ft232h
>
>
>
> I pushed the code to my github repo. Be sure to checkout noor-dev branch.
> Here's the link for that. https://github.com/0xnoor/rtems
>
>
>
> And yes the code looks bad as of now, I'll do optimization and everything
> soon.
>
>
>
> Thanks
>
>
>
> On Fri, 2 Sept 2022 at 23:31, Alan Cudmore wrote:
>
> Hi Noor,
>
> Can you describe the setup you use for testing the BSP?
>
> I can set up my Pi 4 to try running your code as you update it. How do you
> setup the OCD connection?
>
>
>
> Thanks,
>
> Alan
>
>
>
> On Fri, Sep 2, 2022 at 11:48 AM Noor Aman wrote:
>
> Hey all,
>
> Raspberry Pi 4B MMU seems to be enabled, as reported by openocd but gdb is
> showing to run in a loop from aarch64-defaulit-exception.S file starting
> from code line number 143 to 220.
>
>
>
> From what I can gather, it is being caused by the wrong MMU address.
>
> Here's a RAM and MMU allocation sizes and base
>
>
>
> MEMORY {
> RAM_MMU : ORIGIN = 0x0, LENGTH = (0x1000 *
> ${AARCH64_MMU_TRANSLATION_TABLE_PAGES})
> RAM : ORIGIN = 0x8, LENGTH = 1024M
> }
>
>
>
> Relevant Openocd info
>
>
>
> bcm2711.cpu0 halted in AArch64 state due to debug-request, current mode:
> EL1T
> cpsr: 0x23c4 pc: 0x8e208
> MMU: enabled, D-Cache: enabled, I-Cache: enabled
> Info : New GDB Connection: 1, Target bcm2711.cpu0, state: halted
>
>
>
> Any ideas?
>
>
>
> Thanks,
>
> Noor
>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
