On 23/08/2021 13:04, Moustafa Nofal wrote:
> 
>     >Please do _not_ reply with html mails in future. It's almost
>     impossible
>     >to figure out where you exactly responded. And please always reply
>     to all.
>     Okay, sure.

Last warning. :)

You answer in html inside response and use strange formatting: it's
really hard to read your mails and a fiddling finding out the spots
where you responded.

>     >
>     >  
>     >
>     > > What could be a clean way, to add such headers into jailhouse, I
>     > have my
>     > > own header-which describes addresses of GPIO registers- added to
>     > > /inmates/lib/include, but is there any possible way to add these
>     > headers?
> 
>     >>>Sorry, I think I don't understand the question. Of course, if you
>     have
>     >>>custom modifications, you can place you headers there.
> 
>  
> 
>     I want to avoid such headers as much as possible.
> 
>  
> 
> 
> 
>     >>The device tree is only required if you use Linux in your inmate.
>     If you
>     >>want to use the bare-metal inmate library, then you only need to
>     adjust
>     >>the configuration of your inmate.
>     Okay, I understand it now.
> 
>     >
>     > >2. Map that address to your inmate using map_range()
>     > >(instead of opening /dev/mem, there is no semantic at all for
>     devices
>     > >in our tiny libinmate)
>     >
>     >  
>     > Yes, that was my problem, I tried accessing the registers directly,
>     > but it must be mapped first, there are two solutions for this,
>     > either using assembly code or use such a function.
>     > I did not know about map_range, or whether jailhouse uses it, but I
>     > will check and get back to you.
> 
>     >map_range is a routine of libinmate, it /belongs/ to jailhouse. Use
>     "git
>     >grep map_range" to see how it is used.
>     I tried map_range
>     #define GPIO_BASE               0xFE200000
>         map_range((void*)GPIO_BASE, 0xb4,MAP_CACHED);

You need to use MAP_UNCACHED for MMIO devices. But keep in mind that we
use huge pages on arm, so 2MiB will get mapped, but that shouldn't be an
issue in your case.

>     I could not find a signature, but I think I need a void pointer with
>     address as an argument, am I correct?

How can you even not find the signature? There's nothing easier like that:
$ git grep map_range
void map_range(void *start, unsigned long size, enum map_type map_type)

But yes, besides you should use MAP_UNCACHED, this looks good.

> 
> 
>     > On the other hand, I found mmio_write32() for writing registers, but
>     > I could not find the source file. Also timer_start(), I do not know
>     > where is the definition of this function.
> 
>     >After you mapped the physical memory, you can then access registers
>     with
>     >mmio_write()-accessors. To find the definition of those routines, just
>     >use git grep:
> 
>     >lib/arm-common/include/inmate.h:static inline void mmio_write32
> 
>     Okay, great!, I am not sure about the signature as well, but am sure

OK - I think I don't understand what you refer to with "signature".

>     of the address and I added the whole memory starting from 0xFE200000
>     to 0xFE2000B4 to the inmate-demo.c
> 
>     here
>                                /*GPIO*/{
>                 .phys_start = 0xfe200000,
>                 .virt_start = 0xfe200000,
>                 .size = 0xb4,
>                 .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
>                 JAILHOUSE_MEM_IO,

Ok, now things get a bit complicated:

Usually, the finest granularity for assigning memory is the PAGE_SIZE,
which is, in case of ARM, 4KiB (0x1000). If you map anything below
0x1000 (e.g., 0xb4), then Jailhouse implements subpaging: The hypervisor
will trap on access, and dispatch the access. In this case, you must
specify JAILHOUSE_MEM_IO_${WIDTH} (with WIDTH=8,16,32,64), in order to
allow access within a specified width.

>             },
> 
>     and in gic-demo.c
> 
>     static void *GPIO_GPFSEL2= (void*)0xFE200008;
>         mmio_write32(GPIO_GPFSEL2, mmio_read32(GPIO_GPFSEL2) ^ (1 << 3)); 
>     I get from the UART console:
> 
>      FATAL: Invalied MMIO read, address:fe200008, size 4.

Otherwise, you will fault, as you can see here. "size 4" tells you that
the width was 4*8=32 bit (obviously, you used mmio_write32).

So now there are two possibilities how you can fix this issue:

1. Change the config flags of the memory region to:
  .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
           JAILHOUSE_MEM_IO | JAILHOUSE_MEM_IO_32

  Advantage: You *exactly* only map 0xb4 byte of the device
  Disadvantage: The hypervisor will trap on every access


2. Change .size from 0xb4 to 1*PAGE_SIZE. This will map 4KiB instead of
   0xb4 byte. If there are no other devices behind that physical memory
   region, then this should be the preferred choice, as no further
   hypervisor activity will be involved.

  Ralf

> 
>     FATAL: forbidden access (exception class 0x24)
>     I am not sure if the mapping was correct.>
>     > One more question, I think you must have mapped the timer and UART0
>     > peripherals, in order to be able to trigger it. I saw the memory
> 
>     >In order to trigger what? What is "it"? :)
>     I meant the timer by it :). How is the timer
>     > region structure  in *rpi4-inmate-demo.c *and could understand, how
>     > could you make it and implemented something similar for the GPIO. 
>     > But where the initialization of the timer and uart, I mean in which
>     > file, or how is that made>
>     >On arm, libinmate uses the platform timer. Take a look at
>     >inmates/lib/arm-common/timing.c.
>     Okay, thanks
>     >
>     > >3. directly write to the address
>     >
>     > >Other than that, have a look at demos/arm/gic-demo.c or
>     > >demos/x86/apic-demo.c. There we have the cmdline argument that
>     allows
>     > >for specifying a led-pin, which is nothing else but a GPIO.
>     > Yes, this part I understand, but my experience was with
>     > ARM-Cortex-M, so I thought I could just write to the register
>     > without mapping it. But thanks for the information and would really
>     > appreciate, if you could tell in which direction shall I dig.
> 
>     >On ARM, we use virtual memory management for inmates. So you
>     definitely
>     >need a mapping prior to accessing MMIO registers.
>     Yeah, I could understand.
> 
>     Best Regards,
>     Moustafa Noufale
> 
>      
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Jailhouse" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [email protected]
> <mailto:[email protected]>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jailhouse-dev/12f6f39b-14fa-47c4-9fe6-6ca0897e14c0n%40googlegroups.com
> <https://groups.google.com/d/msgid/jailhouse-dev/12f6f39b-14fa-47c4-9fe6-6ca0897e14c0n%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 
You received this message because you are subscribed to the Google Groups 
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jailhouse-dev/66d9ac5b-8e2c-621d-d948-ff921aa0aa5e%40oth-regensburg.de.

Reply via email to