On Mon, Nov 5, 2018 at 6:19 PM Thawra Kadeed <kad...@ida.ing.tu-bs.de> wrote:
>
>
> Thanks, it is better now.
>
> But I have now the following error:
>
> command line: build/ARM/gem5.opt --debug-flags=Exec
> configs/example/fs.py --bare-metal --kernel=OS2.out
>
> Global frequency set at 1000000000000 ticks per second
> warn: DRAM device capacity (8192 Mbytes) does not match the address
> range assigned (512 Mbytes)
> warn: Empty .text segment in
> '/home/kadeed/Gem5/DiskImage/ucosii/binaries/OS2.out'. ELF file
> corrupted?
> info: kernel located at:
> /home/kadeed/Gem5/DiskImage/ucosii/binaries/OS2.out
> system.vncserver: Listening for connections on port 5900
> system.terminal: Listening for connections on port 3456
> 0: system.remote_gdb: listening for remote gdb on port 7000
>
> fatal: Kernel is mapped to invalid location (not memory). kernelStart
> 0x(0) - kernelEnd 0x(0) 0:0
>
I had this problem on aarch64, you also need:
fs.py --param 'system.highest_el_is_64 = True' \
--param 'system.auto_reset_addr_64 = True'
as explained at:
https://stackoverflow.com/questions/43682311/uart-communication-in-gem5-with-arm-bare-metal/50983650#50983650
I'm not sure about all the memory setup options.
> This has to do with Gem5 memory configuration and the kernel address
> which is specified in the rtos.elf file.
>
> to address this, first I need to understand exactly how Gem5 configure
> the main memory,i.e, the memory size, the rom address space, the
> reserved address space and the available address space for the user.
>
> I expected that should be in the fs.py but I have not seen that. Maybe
> has to do with ARM-specific architecture file but also was not clear for
> me.
>
> So like you said, it is now like bare metal execution where you are our
> expert, so can you please provide me with some info about Gem5 memory
> configuration?
>
> Thanks in advance!
>
>
>
>
>
>
> On 2018-11-05 12:43, Ciro Santilli wrote:
> > On Mon, Nov 5, 2018 at 11:29 AM Thawra Kadeed <kad...@ida.ing.tu-bs.de>
> > wrote:
> >>
> >>
> >> Thanks a lot Ciro for your answer.
> >>
> >> I just point to the rtos.elf using --kernel, and recompiled the
> >> available bootloader in "system/arm/" using
> >> arm-none-eabi toolchain instead arm-linux-gnueabi so that I produce
> >> non-linux related bootloader.
> >>
> >> I still have an error related to "kernel panic" and debugging does not
> >> show me more than the following output:
> >>
> >> command line: build/ARM/gem5.opt --debug-flags=Exec
> >> configs/example/fs.py --kernel=OS2.out
> >>
> >> Global frequency set at 1000000000000 ticks per second
> >> warn: DRAM device capacity (8192 Mbytes) does not match the address
> >> range assigned (512 Mbytes)
> >> warn: Empty .text segment in
> >> '/home/kadeed/Gem5/DiskImage/ucosii/binaries/OS2.out'. ELF file
> >> corrupted?
> >> info: kernel located at:
> >> /home/kadeed/Gem5/DiskImage/ucosii/binaries/OS2.out
> >> panic: Failed to find kernel symbol 'panic'
> >> Memory Usage: 973740 KBytes
> >> Program aborted at tick 0
> >> --- BEGIN LIBC BACKTRACE ---
> >> build/ARM/gem5.opt(_Z15print_backtracev+0x15)[0x192e2f5]
> >> build/ARM/gem5.opt(_Z12abortHandleri+0x39)[0x193ca39]
> >> /lib64/libpthread.so.0(+0x11fb0)[0x7faa63a95fb0]
> >> /lib64/libc.so.6(gsignal+0x10b)[0x7faa62363eab]
> >> /lib64/libc.so.6(abort+0x123)[0x7faa6234e5b9]
> >> build/ARM/gem5.opt[0x9fb80f]
> >> build/ARM/gem5.opt(_ZN14LinuxArmSystemC2EP20LinuxArmSystemParams+0xcb6)[0xf819d6]
> >> build/ARM/gem5.opt(_ZN20LinuxArmSystemParams6createEv+0x21)[0xf826c1]
> >> build/ARM/gem5.opt[0xcbef1f]
> >> build/ARM/gem5.opt[0xb3bd81]
> >> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x8029)[0x7faa63e142e9]
> >> /lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x712)[0x7faa63e159b2]
> >> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x632c)[0x7faa63e125ec]
> >> /lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x712)[0x7faa63e159b2]
> >> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x632c)[0x7faa63e125ec]
> >> /lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x712)[0x7faa63e159b2]
> >> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x632c)[0x7faa63e125ec]
> >> /lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x712)[0x7faa63e159b2]
> >> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x632c)[0x7faa63e125ec]
> >> /lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x712)[0x7faa63e159b2]
> >> /lib64/libpython2.7.so.1.0(PyEval_EvalCode+0x1d)[0x7faa63e15c4d]
> >> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x708a)[0x7faa63e1334a]
> >> /lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x712)[0x7faa63e159b2]
> >> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x632c)[0x7faa63e125ec]
> >> /lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x712)[0x7faa63e159b2]
> >> /lib64/libpython2.7.so.1.0(PyEval_EvalCode+0x1d)[0x7faa63e15c4d]
> >> /lib64/libpython2.7.so.1.0(+0x178bcf)[0x7faa63e1bbcf]
> >> /lib64/libpython2.7.so.1.0(PyRun_StringFlags+0x68)[0x7faa63e1bdd8]
> >> build/ARM/gem5.opt(_Z6m5MainiPPc+0x53)[0x193b6f3]
> >> build/ARM/gem5.opt(main+0x3f)[0x9adbef]
> >> /lib64/libc.so.6(__libc_start_main+0xeb)[0x7faa6235011b]
> >> build/ARM/gem5.opt(_start+0x2a)[0x9eac9a]
> >> --- END LIBC BACKTRACE ---
> >> Aborted (core dumped)
> >>
> >>
> >> Do you have an idea about why it still complain about the kernel panic
> >> which (I think) has to do with linux?
> >>
> >
> > Ah, you are right, it is doing something Linux specific.
> >
> > This happens because on ARM at least, gem5 detects panic by finding
> > the address of the panic symbol, and checking if PC is there.
> >
> > This is an awesome feature, when you actually have a panic symbol :-P
> >
> > The fs.py --bare-metal option should turn this off as it makes gem5
> > use ArmSystem instead of LinuxArmSystem.
> >
> >>
> >> On 2018-11-04 19:31, Ciro Santilli wrote:
> >> > On Sun, Nov 4, 2018 at 4:02 PM Thawra Kadeed <kad...@ida.ing.tu-bs.de>
> >> > wrote:
> >> >>
> >> >> Hello everyone,
> >> >>
> >> >> I m trying to boot a real-time operating system (RTOS) e.g. MicroC/OS
> >> >> on
> >> >> ARM using Gem5 full system mode.
> >> >>
> >> >> I replaced the Linux kernel in FSConfig.py by the RTOS one.
> >> >
> >> > Did you have to modify that file? How exactly? Or do you mean just
> >> > pass --kernel path/to/rtos.elf (that's what I'd expect).
> >> >
> >> >> And I need to compile the ARM bootloader (available here: system/arm/)
> >> >> for RTOS rather than Linux which is explained here
> >> >> "http://www.gem5.org/ARM_Kernel";. The latter explanation uses gcc
> >> >> linux
> >> >> cross compiler to do so.
> >> >>
> >> >> However, does anyone know how can I direct/compile the ARM bootloader
> >> >> for RTOS?
> >> >>
> >> >
> >> > I have never booted anything besides Linux, but I really want to give
> >> > it a try some day.
> >> >
> >> > Have you ever used those gem5 bootloaders for Linux to start with? If
> >> > not, here is a minimal runnable setup that builds them and puts them
> >> > in M5_PATH so they are used:
> >> > https://github.com/cirosantilli/linux-kernel-module-cheat/tree/8fb9db39316d43a6dbd571e04dd46ae73915027f#gem5-buildroot-setup-getting-started
> >> >
> >> > Once you have that working, I would just try to point --kernel to the
> >> > rtos. And then if it does not work, start to step debug stuff and
> >> > examine memory / pc until you undertand why it's not booting, should
> >> > not be too hard.
> >> >
> >> >> Thanks in advance,
> >> >> Thawra
> >> >> _______________________________________________
> >> >> gem5-users mailing list
> >> >> gem5-users@gem5.org
> >> >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
