Genode on i.MX6 (eMMC Flash)
Stefan Kalkowski
stefan.kalkowski at ...1...
Tue May 2 09:04:00 CEST 2017
Hi Kranthi,
On 05/01/2017 01:33 PM, Kranthi Tej wrote:
> Hello Martin & Stefan,
>
> We've been working on this issue. The pagefault occurs at ip =
> 0x200374f4. I've referred to the objdump output corresponding to this
> ip. The following is the corresponding line:
>
> _ZN6Genode17Native_capabilityaSERKS0_():
> /home/kranthitej/Desktop/BTP/BTP_Latest/genode-master/repos/base/include/base/native_capability.h:93
> 200374f4:e7975003 ldrr5, [r7, r3]
>
> When we looked into the LDR documentation in the ARM Infocenter, we've
> discovered that the possible way of getting an error with the LDR
> command is when the literal pool is not within the range of the LDR
> instruction. The solution to this problem is given to be adding "LTORG"
> directive in the assembly code before the problematic instruction.
>
> However, in our case, the assembly file is being generated by higher
> level code. We are not able to comprehend as to how we can add a literal
> pool in the image being generated. Can you give us any pointers on what
> modifications could be made and where?
I'm sure it has nothing to do with the load instruction and its usage,
but for instance with missing physical backing store, e.g., by wrong RAM
specifications, that is going to be loaded.
I have taken our i.MX6Q SABRE SD out of the cabinet and tested it by
building `run/log` and `run/affinity` for the Wandboard with the minor
patch below [1].
Both run-scripts worked without further modifications beside the lesser
RAM specification on top of Genode's master and staging branches.
I do not know what code-base you are using, but please try the patch
below on top of Genode's current master branch to build the "log" image,
and verify whether this works for you.
Best regards
Stefan
[1] Patch:
diff --git a/repos/base/include/spec/imx6/drivers/board_base.h
b/repos/base/include/spec/imx6/drivers/board_base.h
index 2d161f4..3600d6d 100644
--- a/repos/base/include/spec/imx6/drivers/board_base.h
+++ b/repos/base/include/spec/imx6/drivers/board_base.h
@@ -30,7 +30,7 @@ struct Genode::Board_base
enum {
/* normal RAM */
RAM0_BASE = 0x10000000,
- RAM0_SIZE = 0x80000000,
+ RAM0_SIZE = 0x40000000,
/* device IO memory */
MMIO_BASE = 0x00000000,
>
> Thanks in advance,
> Kranthi
>
> On Thu, Apr 20, 2017 at 4:45 PM, Kranthi Tej <ee13b037 at ...484...
> <mailto:ee13b037 at ...484...>> wrote:
>
> Hello Martin,
>
> Thank you for the response.
>
>
> Most likely it's not a problem with the write function but with the
> hardware implications of this specific write. This is the point
> where
> memory-management unit and caches are switched on for the first time
> implicitely moving execution from the physical to a virtual address
> space. As the Kernel has no pager, this means that the page
> table behind
> the virtual address space must already contain all stuff that is
> essential to the Kernel (and the Core main/pager functionality).
>
>
> You were right about the write function. It was not the problem. I
> had accidentally placed a log message before the init_log() service
> was started in the repos/base-hw/src/bootstrap/init.cc file. That is
> why I couldn't reach the "kernel initialized" part in Genode 17.02.
>
>
> I would lookup the pagefault IP denoted in the pagefault message
> first
> using 'genode-arm-objdump -DCl <BUILD_DIR>/var/run/<RUN_NAME>.core'.
>
>
> I've taken the objdump of the file as you have suggested. The
> pagefault occurs at ip=0x200374f4. I've checked the corresponding
> line in the objdump output. It seems to correspond to a part of the
> prepare_init_main_thread function in [1]. This is the line:
>
> _ZN6Genode17Native_capabilityaSERKS0_():
> /home/kranthitej/Desktop/BTP/BTP_Latest/genode-master/repos/base/include/base/native_capability.h:93
> 200374f4:e7975003 ldrr5, [r7, r3]
>
> I've also uploaded the objdump output at:
> https://drive.google.com/open?id=0B0jItjAniGQxR2FmWURsT1BZS0U
> <https://drive.google.com/open?id=0B0jItjAniGQxR2FmWURsT1BZS0U> (for
> reference)
>
>
> This should give you a hint what is missing in your page table.
> The MMIO
> regions to be included in the early page table are defined in [1].
>
>
> I've referred to the file you've suggested. I've stumbled upon
> variables which seem to have been defined in [2]. These are the
> values I'm currently using:
>
> /* normal RAM */
> RAM0_BASE = 0x10000000,
> RAM0_SIZE = 0x20000000,
>
> UART_1_IRQ = 58,
> UART_1_MMIO_BASE = 0x02020000,
> UART_1_MMIO_SIZE = 0x00004000,
>
> /* CPU */
> CORTEX_A9_PRIVATE_MEM_BASE = 0x00a00000,
> CORTEX_A9_PRIVATE_MEM_SIZE = 0x00002000,
> CORTEX_A9_PRIVATE_TIMER_CLK = 395037500,
> CORTEX_A9_PRIVATE_TIMER_DIV = 170,
>
> /* L2 cache controller */
> PL310_MMIO_BASE = 0x00a02000,
> PL310_MMIO_SIZE = 0x00001000,
>
>
> It might help if you post the whole serial output of your test.
>
>
> The following is the serial output of my test. I've used "log" image
> instead of using "demo":
>
> MX6Q SABRESD U-Boot > ext2load mmc 3:1 0x30000000 uImage
> Loading file "uImage" from mmc device 3:1 (xxd1)
> 593794 bytes read
>
> MX6Q SABRESD U-Boot > bootm 0x30000000
> ## Booting kernel from Legacy Image at 30000000 ...
> Image Name:
> Image Type: ARM Linux Kernel Image (gzip compressed)
> Data Size: 593730 Bytes = 579.8 kB
> Load Address: 10001000
> Entry Point: 10001000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
>
> Starting kernel ...
>
> :virt_alloc: Allocator 0x200c40b4 dump:
> Block: [0x1000,0x10001000] size=0x10000000 avail=0x10000000
> max_avail=0x10000000
> Block: [0x1057d000,0x20001000] size=0xfa84000 avail=0xfa84000
> max_avail=0xbfe8b000
> Block: [0x20174000,0x20175000] size=0x1000 avail=0x0 max_avail=0x0
> Block: [0x20175000,0xe0000000] size=0xbfe8b000 avail=0xbfe8b000
> max_avail=0xbfe8b000
> Block: [0xf0004000,0xf0005000] size=0x1000 avail=0x0
> max_avail=0xbfe8b000
> Block: [0xf0007000,0xf0008000] size=0x1000 avail=0x0 max_avail=0x0
> Block: [0xf0009000,0xf000a000] size=0x1000 avail=0x0
> max_avail=0xffe5000
> Block: [0xf000a000,0xfffef000] size=0xffe5000 avail=0xffe5000
> max_avail=0xffe5000
> => mem_size=4019159040 (3832 MB) / mem_avail=4019142656 (3832 MB)
>
> :phys_alloc: Allocator 0x200c3048 dump:
> Block: [0x105bf000,0x105c0000] size=0x1000 avail=0x0 max_avail=0x0
> Block: [0x105c0000,0x105c1000] size=0x1000 avail=0x0
> max_avail=0x1fa3d000
> Block: [0x105c1000,0x105c2000] size=0x1000 avail=0x0 max_avail=0x0
> Block: [0x105c2000,0x105c3000] size=0x1000 avail=0x0
> max_avail=0x1fa3d000
> Block: [0x105c3000,0x30000000] size=0x1fa3d000 avail=0x1fa3d000
> max_avail=0x1fa3d000
> => mem_size=530845696 (506 MB) / mem_avail=530829312 (506 MB)
>
> :io_mem_alloc: Allocator 0x200c512c dump:
> Block: [0x0,0x105bf000] size=0x105bf000 avail=0x105bf000
> max_avail=0xcfffffff
> Block: [0x30000000,0xffffffff] size=0xcfffffff avail=0xcfffffff
> max_avail=0xcfffffff
> => mem_size=3764121599 (3589 MB) / mem_avail=3764121599 (3589 MB)
>
> :io_port_alloc: Allocator 0x200c6198 dump:
> => mem_size=0 (0 MB) / mem_avail=0 (0 MB)
>
> :irq_alloc: Allocator 0x200c7204 dump:
> Block: [0x0,0x1] size=0x1 avail=0x1 max_avail=0x1
> Block: [0x2,0x1d] size=0x1b avail=0x1b max_avail=0x3e2
> Block: [0x1e,0x400] size=0x3e2 avail=0x3e2 max_avail=0x3e2
> => mem_size=1022 (0 MB) / mem_avail=1022 (0 MB)
>
> :rom_fs: ROM modules:
> ROM: [10176000,10176158) config
> ROM: [10152000,10172178) init
> ROM: [100d5000,101519a4) ld.lib.so <http://ld.lib.so>
> ROM: [10173000,10175598) test-log
>
>
> kernel initialized
> Error: page fault in core thread (core): ip=0x200374f4 fault=0x4ce79f8
>
> I've observed that all my address ranges (except phys_alloc) in the
> serial output have a negative offset of 0x30000 to the output
> mentioned in
> this: https://sourceforge.net/p/genode/mailman/message/35743536/
> <https://sourceforge.net/p/genode/mailman/message/35743536/> (which
> seems to be working).
>
> However, the phys_alloc address range has a negative offset of
> 0x60000. Can you give me your insights on this? Could it be a source
> of the problem? If yes, how can I go about resolving it?
>
>
> Cheers,
> Martin
>
>
> Thanks in advance,
> Kranthi
>
> [1] repos/base-hw/src/lib/base/thread_bootstrap.cc
> [2] repos/base/include/spec/imx6/drivers/board_base.h
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> genode-main mailing list
> genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
>
--
Stefan Kalkowski
Genode Labs
https://github.com/skalk ยท http://genode.org/
More information about the users
mailing list