[OpenRISC] [] booting Linux on openrisc in RTL simulator iTLB miss

[jurand]

Hi,

I am trying to run linux kernel on OpenRisc in RTL simulator. I prepared
vmlinux and successfully run it in or1ksim, using objcopy i create
vmlinux.bin and memory initialization file (using bin2vmem). What i see in
simulator is that processor starts reading from reset vector address 0x100,
after reading 0x118 addr jumps to 0x298000, after this procesor is reading
data from high addresses and after reading from 0x29813C address it jumps to
0xA00 which according to documentation is iTLB miss exception.

Does anyone know what is wrong?



--
View this message in context: http://openrisc.2316802.n4.nabble.com/booting-Linux-on-openrisc-in-RTL-simulator-iTLB-miss-tp4642095.html
Sent from the OpenRISC mailing list archive at Nabble.com.

[Stefan Kristiansson]

Post by jurand
Hi,
I am trying to run linux kernel on OpenRisc in RTL simulator. I prepared
vmlinux and successfully run it in or1ksim, using objcopy i create
vmlinux.bin and memory initialization file (using bin2vmem). What i see in
simulator is that processor starts reading from reset vector address 0x100,
after reading 0x118 addr jumps to 0x298000, after this procesor is reading
data from high addresses and after reading from 0x29813C address it jumps to
0xA00 which according to documentation is iTLB miss exception.

What simulation, on what processor implementation?

Post by jurand
Does anyone know what is wrong?

Nothing you have said has really indicated that something would be
wrong, what is supposed to happen at those addresses in your vmlinux?

Stefan

[Jonas Bonn]

Post by jurand
Hi,
I am trying to run linux kernel on OpenRisc in RTL simulator. I prepared
vmlinux and successfully run it in or1ksim, using objcopy i create
vmlinux.bin and memory initialization file (using bin2vmem). What i see in
simulator is that processor starts reading from reset vector address 0x100,
after reading 0x118 addr jumps to 0x298000, after this procesor is reading
data from high addresses and after reading from 0x29813C address it jumps to
0xA00 which according to documentation is iTLB miss exception.
Does anyone know what is wrong?

Looks like pretty reasonable behavour...

i) Processor starts at reset vector and does some setup before enabling
MMU.
ii) Once MMU is enabled it starts reading from "high addresses"
(virtual addresses) that the MMU translates to physical addresses
iii) The iTLB miss exception is, of course, expected because the first
access to any page results in a TLB miss

...so the question is: is that where it gets stuck? Are you using the
HW accelerated page table walking? Which implementation (or1200,
mor1kx,...)?

/Jonas

[jurand]

Thanks for replies,

1. Processor implementation is or1200. I simulates orpsoc in RTL simulator

2.
@Stefan

Post by Stefan Kristiansson
Nothing you have said has really indicated that something would be
wrong, what is supposed to happen at those addresses in your vmlinux?

I am new in OpenRisc and embedded linux, so i am not able to answer this
question. At 0xA00 address in memory initialization file are zeros. Maybe,
as Jonas wrote this is correct behaviour.

@Jonas

Post by Stefan Kristiansson
...so the question is: is that where it gets stuck? Are you using the
HW accelerated page table walking?

I am not sure what is HW accelerated page table walking, and i dont see
any entry in my .config file for kernel building pointing for something like
this.

3. Maybe this is correct behaviour, but i dont have anything on uart
console.
BTW. In menuconfig i removed Network support because i dont have ethernet in
system and after this procesor stuck not at A00 address but on periodic
reading from four addresses: 0x4730, 0x4734, 0xC000472C, 472C

/Thanks, jurand



--
View this message in context: http://openrisc.2316802.n4.nabble.com/OpenRISC-booting-Linux-on-openrisc-in-RTL-simulator-iTLB-miss-tp4642095p4642098.html
Sent from the OpenRISC mailing list archive at Nabble.com.

[jurand]

I will try to explain again my problem.
1. vmlinux.bin loaded into ram (bin2vmem)
2. Processor is reading from addresses 0x100-0x118, high addresses like
0x17E000, C00FE948, 0x42088, C01401A8, which according to Your replies is
probably correct.
2. I see nothing on uart console. Processor doesn't write to uart16550_0,
its address 0x9000000 does not appear on wishbone bus.

Maybe there is something wrong in dts, or bootargs? Do i have to edit
initramfs.devnodes and add nod to /dev/ttyS0?

I enclose
.config <http://openrisc.2316802.n4.nabble.com/file/n4642100/.config>
- from kernel building
simple.dts <http://openrisc.2316802.n4.nabble.com/file/n4642100/simple.dts>
- used device tree
sim.log <http://openrisc.2316802.n4.nabble.com/file/n4642100/sim.log>
- log from simulation using or32-elf-sim

/jurand





--
View this message in context: http://openrisc.2316802.n4.nabble.com/OpenRISC-booting-Linux-on-openrisc-in-RTL-simulator-iTLB-miss-tp4642095p4642100.html
Sent from the OpenRISC mailing list archive at Nabble.com.

[Stefan Kristiansson]

Post by jurand
I will try to explain again my problem.
1. vmlinux.bin loaded into ram (bin2vmem)

Ok, that sounds right.

Post by jurand
2. Processor is reading from addresses 0x100-0x118, high addresses like
0x17E000, C00FE948, 0x42088, C01401A8, which according to Your replies is
probably correct.

The addresses aren't necessarily going to say us much, since they are
specific to your kernel build (except for exception vectors and such
of course)

Post by jurand
2. I see nothing on uart console. Processor doesn't write to uart16550_0,
its address 0x9000000 does not appear on wishbone bus.

This isn't much to go on, information about what it *does* would be
more helpful.

Post by jurand
Maybe there is something wrong in dts, or bootargs? Do i have to edit
initramfs.devnodes and add nod to /dev/ttyS0?
I enclose
.config <http://openrisc.2316802.n4.nabble.com/file/n4642100/.config>
- from kernel building
simple.dts <http://openrisc.2316802.n4.nabble.com/file/n4642100/simple.dts>
- used device tree

This is maybe where the problem is, you have defined a memory of 128MB,
do you really have that much memory in your simulation?

Post by jurand
sim.log <http://openrisc.2316802.n4.nabble.com/file/n4642100/sim.log>
- log from simulation using or32-elf-sim

A note not related to your problem, have you considered moving away
from or1200 and use mor1kx instead?
I would recommend that at least, and also to use fusesoc/orpsoc-cores
instead of the deprecated old orpsoc.

https://github.com/olofk/fusesoc
https://github.com/openrisc/orpsoc-cores

There's simulation environments for both or1200 and mor1kx available there.

Stefan

[jurand]

Post by Stefan Kristiansson

Post by jurand
simple.dts

<http://openrisc.2316802.n4.nabble.com/file/n4642100/simple.dts>

Post by Stefan Kristiansson

Post by jurand
- used device tree

This is maybe where the problem is, you have defined a memory of 128MB,
do you really have that much memory in your simulation?

Yes i have.

Post by Stefan Kristiansson

Post by jurand
2. Processor is reading from addresses 0x100-0x118, high addresses like
0x17E000, C00FE948, 0x42088, C01401A8, which according to Your replies is
probably correct.

The addresses aren't necessarily going to say us much, since they are
specific to your kernel build (except for exception vectors and such
of course)

I ran simulation in open risc simulator with trace option, loged addresses
and data from RTL simulation, and compared this. Tracer from OR simulator
gives assembler instructions so maybe this will tell you something.

About 74 thousands read operations are the same in RTL sim and OR sim.
Differences starts after l.addi assembler instruction:
RTL sim | OR SIMULATAOR
----------------------+-----------------------------------------------------------------
@c015851c 18a0d00d | c015851c: 18a0d00d l.movhi r5,0xd00d r5 = d00d0000
flag: 0
@c0158520 84830000 | c0158520: 84830000 l.lwz r4,0x0(r3) r4 = d00dfeed
flag: 0
@c0158524 a8a5feed | c0158524: a8a5feed l.ori r5,r5,0xfeed r5 =
d00dfeed flag: 0
@c0158528 e4042800 | c0158528: e4042800 l.sfeq r4,r5
flag: 1
@c015852c 0c00003c | c015852c: 0c00003c l.bnf 0x3c
flag: 1
*@c0158530 9c800000 | c0158530: 9c800000 l.addi r4,r0,0x0 r4 =
00000000 flag: 1
@c015861c 1860c017 | c0158534: 85630008 l.lwz r11,0x8(r3) r11 = 00000038
flag: 1*

Does it tell you something?



--
View this message in context: http://openrisc.2316802.n4.nabble.com/OpenRISC-booting-Linux-on-openrisc-in-RTL-simulator-iTLB-miss-tp4642095p4642105.html
Sent from the OpenRISC mailing list archive at Nabble.com.

[Stefan Kristiansson]

Post by jurand
I ran simulation in open risc simulator with trace option, loged addresses
and data from RTL simulation, and compared this. Tracer from OR simulator
gives assembler instructions so maybe this will tell you something.
About 74 thousands read operations are the same in RTL sim and OR sim.
RTL sim | OR SIMULATAOR
----------------------+-----------------------------------------------------------------
@c015851c 18a0d00d | c015851c: 18a0d00d l.movhi r5,0xd00d r5 = d00d0000
flag: 0
@c0158520 84830000 | c0158520: 84830000 l.lwz r4,0x0(r3) r4 = d00dfeed
flag: 0
@c0158524 a8a5feed | c0158524: a8a5feed l.ori r5,r5,0xfeed r5 =
d00dfeed flag: 0
@c0158528 e4042800 | c0158528: e4042800 l.sfeq r4,r5
flag: 1
@c015852c 0c00003c | c015852c: 0c00003c l.bnf 0x3c
flag: 1
00000000 flag: 1
@c015861c 1860c017 | c0158534: 85630008 l.lwz r11,0x8(r3) r11 = 00000038
flag: 1*
Does it tell you something?

What would have been even more helpful, would have been if you'd
looked up the function of these instructions.
But, from the 0xd00dfeed magic fdt number, I'm going to assume that
it's in fdt_check_header.
And obviously in the RTL simulation, the pointer passed to that
function doesn't point to a valid fdt.
Which in turn results in that 'l.bnf 0x3c' is executed.

You still haven't answered what kind of simulation you are trying to
perform, is it an event-driven (icarus, modelsim etc) or
cycle-accurate (verilator) rtl simulation you are doing?
If it's an event-driven simulation, there are a couple of things you
need to take care of before you boot the kernel to ensure that no
signals contain 'X's.
For instance, set r3 to a known value.

Stefan

[Matthew Hicks]

Post by Stefan Kristiansson
You still haven't answered what kind of simulation you are trying to
perform, is it an event-driven (icarus, modelsim etc) or
cycle-accurate (verilator) rtl simulation you are doing?
If it's an event-driven simulation, there are a couple of things you
need to take care of before you boot the kernel to ensure that no
signals contain 'X's.
For instance, set r3 to a known value.

Note that it is software's (the processor specific stuff provided by the
or1k community) responsibility to ensure that registers and on-chip buffers
are initialized to 0 (see
http://lists.openrisc.net/pipermail/openrisc/2011-December/000553.html and
http://lists.openrisc.net/pipermail/openrisc/2011-December/000560.html).

[Wojciech Lewandowski]

Dear all,
I finally run Linux on OR 1200 in rtl simulator and custom own fpga board.
There are few problems:
1. As You pointed some registers were not initialized so there are some X
signals, and this was a main problem.
2. When I did correct initialization I noticed that I also made a mistake
when changing ram memory model
Thanks for your help

jurand

Post by Stefan Kristiansson
You still haven't answered what kind of simulation you are trying to

Post by Stefan Kristiansson
perform, is it an event-driven (icarus, modelsim etc) or
cycle-accurate (verilator) rtl simulation you are doing?
If it's an event-driven simulation, there are a couple of things you
need to take care of before you boot the kernel to ensure that no
signals contain 'X's.
For instance, set r3 to a known value.

Note that it is software's (the processor specific stuff provided by the
or1k community) responsibility to ensure that registers and on-chip buffers
are initialized to 0 (see
http://lists.openrisc.net/pipermail/openrisc/2011-December/000553.html
and http://lists.openrisc.net/pipermail/openrisc/2011-December/000560.html
).

[Matthew Hicks]

It is a shame that after all these years, this problem is not fixed and
people keep wasting time on it.


On Sat, Oct 25, 2014 at 8:32 AM, Wojciech Lewandowski <

Post by Wojciech Lewandowski
Dear all,
I finally run Linux on OR 1200 in rtl simulator and custom own fpga board.
1. As You pointed some registers were not initialized so there are some X
signals, and this was a main problem.
2. When I did correct initialization I noticed that I also made a mistake
when changing ram memory model
Thanks for your help
jurand

Post by Stefan Kristiansson
You still haven't answered what kind of simulation you are trying to

Post by Stefan Kristiansson
perform, is it an event-driven (icarus, modelsim etc) or
cycle-accurate (verilator) rtl simulation you are doing?
If it's an event-driven simulation, there are a couple of things you
need to take care of before you boot the kernel to ensure that no
signals contain 'X's.
For instance, set r3 to a known value.

Note that it is software's (the processor specific stuff provided by the
or1k community) responsibility to ensure that registers and on-chip buffers
are initialized to 0 (see
http://lists.openrisc.net/pipermail/openrisc/2011-December/000553.html and
http://lists.openrisc.net/pipermail/openrisc/2011-December/000560.html).