• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 265 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM62P: Bare Metal Jailhouse demos, change from UART1 to UART2 not working.

Michael Williamson
Expert 1995 points
Part Number: AM62P
Other Parts Discussed in Thread: SYSCONFIG, AM625, OMAP-L137, AM62D-Q1

Tool/software:

Hello,

We are trying to reproduce the jailhouse demo as outlined in the AM62P processor SDK documentation here:

https://software-dl.ti.com/processor-sdk-linux/esd/AM62PX/11_00_09_04/exports/docs/linux/Foundational_Components/Hypervisor/Jailhouse.html

However, we cannot use UART1 as that is dedicated to another resource on our hardware, we need to use UART2.  We applied the patch to the ti-jailhouse git repository used in the yocto recipes shown below.

We have been able to run the LINUX inmate demonstration programs (ping, ivshmem-demo) successfully and get the proper data on the inmate console port on UART2.

However, the BARE-METAL demo programs don't work (uart-demo.bin and gic-demo.bin).  We don't get any output on the UART2 port / console.

Is it possible that additional code must be written to bring UART2 out of a reset condition or configure the clocks, etc., in the bare metal code?  In our main linux DTS, we have forced the UART2 pin-mux pins to always be applied while keeping the device marked as "reserved".

I can't see anything else to modify in the ti-jailhouse,git repository to make the baremetal examples run with UART2.

iff --git a/configs/arm64/dts/inmate-k3-am62p5-sk.dts b/configs/arm64/dts/inmate-k3-am62p5-sk.dts
index 047f9621..70787aab 100644
--- a/configs/arm64/dts/inmate-k3-am62p5-sk.dts
+++ b/configs/arm64/dts/inmate-k3-am62p5-sk.dts
@@ -10,7 +10,7 @@
        #size-cells = <2>;

        aliases {
-               serial1 = &main_uart1;
+               serial1 = &main_uart2;
        };

        chosen {
@@ -87,11 +87,11 @@
                        interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
                };

-               main_uart1: serial@2810000 {
+               main_uart2: serial@2820000 {
                        compatible = "ti,am64-uart", "ti,am654-uart";
-                       reg = <0x00 0x02810000 0x00 0x100>;
-                       interrupts = <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>;
-                       power-domains = <&k3_pds 152 1>;
+                       reg = <0x00 0x02820000 0x00 0x100>;
+                       interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>;
+                       power-domains = <&k3_pds 153 0>;
                        current-speed = <115200>;
                        clock-frequency = <48000000>;
                };
diff --git a/configs/arm64/k3-am62p5-sk-inmate-demo.c b/configs/arm64/k3-am62p5-sk-inmate-demo.c
index 0190aa3c..3014ff84 100644
--- a/configs/arm64/k3-am62p5-sk-inmate-demo.c
+++ b/configs/arm64/k3-am62p5-sk-inmate-demo.c
@@ -37,7 +37,7 @@ struct {
                .num_pci_devices = 0,

                .console = {
-                       .address = 0x02810000,
+                       .address = 0x02820000,
                        .divider = 0x1b,
                        .type = JAILHOUSE_CON_TYPE_8250,
                        .flags = JAILHOUSE_CON_ACCESS_MMIO |
@@ -50,9 +50,9 @@ struct {
        },

        .mem_regions = {
-               /* MAIN UART1 */ {
-                       .phys_start = 0x02810000,
-                       .virt_start = 0x02810000,
+               /* MAIN UART2 */ {
+                       .phys_start = 0x02820000,
+                       .virt_start = 0x02820000,
                        .size = 0x10000,
                        .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
                                JAILHOUSE_MEM_IO,
diff --git a/configs/arm64/k3-am62p5-sk-linux-demo.c b/configs/arm64/k3-am62p5-sk-linux-demo.c
index b9c07342..aa37f983 100644
--- a/configs/arm64/k3-am62p5-sk-linux-demo.c
+++ b/configs/arm64/k3-am62p5-sk-linux-demo.c
@@ -2,7 +2,7 @@
  * Jailhouse, a Linux-based partitioning hypervisor
  *
  * Configuration for Linux inmate on AM62P5 based platforms
- * 3 CPUs, 512MB RAM, 1 serial port (MAIN UART1)
+ * 3 CPUs, 512MB RAM, 1 serial port (MAIN UART2)
  *
  * Copyright (c) 2023 Texas Instruments Incorporated - http://www.ti.com/
  *
@@ -43,7 +43,7 @@ struct {
                .vpci_irq_base = 189 - 32,

                .console = {
-                       .address = 0x02810000,
+                       .address = 0x02820000,
                        .divider = 0x1b,
                        .type = JAILHOUSE_CON_TYPE_8250,
                        .flags = JAILHOUSE_CON_ACCESS_MMIO |
@@ -107,9 +107,9 @@ struct {
                                JAILHOUSE_MEM_EXECUTE | JAILHOUSE_MEM_DMA |
                                JAILHOUSE_MEM_LOADABLE,
                },
-               /* MAIN UART1 */ {
-                       .phys_start = 0x02810000,
-                       .virt_start = 0x02810000,
+               /* MAIN UART2 */ {
+                       .phys_start = 0x02820000,
+                       .virt_start = 0x02820000,
                        .size = 0x10000,
                        .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
                                                       JAILHOUSE_MEM_IO,
@@ -185,8 +185,8 @@ struct {
                        /* vpci */
                        1 << (189 - 160) |
                        1 << (190 - 160),
-                       /* uart */
-                       1 << (211 - 192),
+                       /* uart 2 */
+                       1 << (212 - 192),
                        0, 0,
                        },
                },

Also, in the yocto recipe, it would be useful to provide an option to use a compressed image of the cpio file for the initrd file.  We were about to use ....cpio.xz for our initrd which allowed the use of a larger initrd file / ramfs.

Thanks,

Mike

  • 0
    Expert 1995 points

    As an update.  If I load the linux inmate / demo, shut that down (jailhouse cell shutdown; jailhouse cell destroy) and then run the bare metal demo the UART2 starts working.

    So it seams there is something needed for setting up / enabling the UART2 in the bare metal example that the linux inmate is correctly doing.

    Not sure what it is at this point.

    -Mike

  • 0
    TI__Guru** 101910 points

    Hello Mike,

    This is my first time taking a look at jailhouse, so I will be learning alongside you.

    Is there a working baseline?

    Do the bare metal demos work as expected before making any modifications to UART1/UART2?

    Ramblings about peripheral allocation

    With our MCU+ applications running on the MCU R5F & DM R5F, we need to explicitly request the desired peripherals in SysConfig. For more information about peripheral allocation between different processor cores, refer to AM62Px academy > Multicore > Peripherals
    https://dev.ti.com/tirex/explore/node?node=A__AcGdexDmDxV8k7XSDZd.4w__AM62P-ACADEMY__fp5YxRM__LATEST 

    I don't see anything like that in the jailhouse source code. Off the top of my head I am not sure if it is sufficient to specify the peripherals to be used in
    configs/arm64/k3-am62p5-sk-inmate-demo.c

    or if there is somewhere else that the device manager (DM) firmware needs to be messaged in order to allocate UART2 for the peripheral. (e.g., if the peripheral actually needs to be marked as "okay" in the initial Linux boot so that the peripheral gets initialized, before the bare metal attaches to the peripherals that Linux has already allocated on behalf of the inmates?)

    Double-checking system design 

    Can you tell me a bit more about the system design? Before we spend too much time digging into Jailhouse, I want to check to make sure that this implementation makes sense for your needs. e.g., if MCU R5F is not currently getting programmed, it might make sense to program that core instead of impacting your Linux A53 performance.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Expert 1995 points

    Hi Nick,

    As background, we are a SOM designer, and are validating that jailhouse can be made to work with our hardware as we have had customer inquiries about it.  We support AM62x, AM62P, and AM62A devices.

    Is there a working baseline?

    I don't have access to an AM62P EVM here only our SOM + DevKit at the moment, so I can't test it with UART1 / unmodified as those pins go elsewhere.  I will check if I can get one.  We had to run the yocto build to generate an image for us here for our hardware, but that is a process we are very familiar with and the SDK instructions were straightforward..  As I said, I think it's OK / working minus the UART1 setup in bare-metal mode.

    I suspect that you are correct in that the jailhouse example bare-metal code doesn't really do much in terms of configuring peripherals.   I don't see anything related to pin-mux configuration or pulling the peripheral out of reset (not sure if that is required) or ensuring the clocks to feed the device are enabled (again, not sure without digging around the TRM).  And that's OK, but I would recommend that TI add some text in their SDK documentation that your mileage may vary and perhaps add some hints about what developers should be looking to configure if they are using this feature.  

    I also noted that the instructions for the linux inmate about adding additional examples could use some clarification.  The initrd size modifications that are added to the working DTB will need to be adjusted if new code is added to the CPIO ramfs filesystem in the example.

    As far as system design, we have had a couple of customers that are looking to refresh older L137's and L138's designs consider both AM625 as well as AM62P.  That want the peripheral set and they want an easier migration path for their DSP code.  But their codebase is somewhat large - it won't fit into just the on chip RAMs.  Other jacinto (?? AM57 and the like) devices might be a more natural path, but they are too power hungry.

    One customer attempted to use the M4 (400 MHz) on the 62x, but it wasn't up to the task, primarily because it was memory and memory bandwidth limited.  They are now investigating the MCU R5 (800 MHz) on the AM62P, which is definitely better but the jury is still out if it will be good enough.

    So... we are investigating the performance and possibility of using jailhouse, likely with free RTOS or perhaps an RT enabled inmate linux kernel.

    With regards,

    MIke

  • 0 in reply to Michael Williamson
    TI__Guru** 101910 points

    Hello Mike,

    Got it.

    Another core to keep in mind is the DM (Device manager) R5F. Its primary job is to run the device management task, but it is also user-programmable for AM62x & AM62Px. However, we do not support low power modes if you put user-programmed code on the DM R5F, so if low power is a need then it would not be a good fit.

    What is your timeframe of need here? The team member who has more experience with jailhouse is out of office for the rest of the week. I can ask around, but not sure if I've got any other resources on this side beyond what we would find on a google search.

    Our brand-new AM62Dx might be another potential fit for your customer's usecase - that's the most natural followup to OMAP-L137/138 off the top of my head. Currently we only support RTOS on the A53 cluster, not sure if there are plans to add Linux. Also not sure if we are planning on opening up the C7 on that processor for development, and if so what the timeline is. But you could create a separate e2e thread to ask about software plans that device if it might be interesting for your usecase: https://www.ti.com/product/AM62D-Q1 

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Expert 1995 points

    Hi Nick,

    The AM62Dx would be ideal except that there does not appear to be provisions for any sort of local display.  The VOUT, OLDI, DSI outputs on the 62x family looks to be defeatured and the DSS removed.  This isn't necessarily a complete roadblock but there are some customers that use a local panel display for benchtop instrumentation with the L138.

    We are holding out some hope that perhaps the 62A C7 will be opened up at some point, but not as of yet.  

    I can wait until next week if that makes resolving this easier on your end.

    With regards,

    Mike

  • 0 in reply to Michael Williamson
    TI__Guru** 101910 points

    Hello Mike,

    Sounds good, I will discuss the Jailhouse question with my team member next week. Please ping the thread if I have not replied by Tuesday of next week, that will make sure I do not lose your thread.

    AM62A C7 development?

    On C7 development on AM62A, this is what I got from the team:
    "Our offering at this time is focused on vision and EdgeAI, so we do not currently support use of C7x on AM62A as a general purpose DSP. However, we would like to understand your near term needs to consider it in our future planning. Please, reach out to your local TI contact to discuss this further."

    So I wouldn't plan on anything within 2025, but we are still deciding where to put development and support resources over the next couple of years. So talking with your local FAE can be helpful in potentially influencing what decisions are made later on.

    AM62D display? 

    I have confirmed that we do not enable display on the automotive grade part AM62D-Q1. However, there is an upcoming part that does have display. I cannot discuss on the forums, please reach out to your local TI FAE for more details.

    Regards,

    Nick