OpenCores
Issue List
cannot boot from 0xf000_0100 properly #39
Closed swaka opened this issue over 15 years ago
swaka commented over 15 years ago

Currently or1ksim could not boot from 0xf000_0100 properly. I found that there were many hardcoded pc into 0x0 in source codes.

Regards, swaka

jeremybennett commented over 15 years ago

Hi Swaka,<br> <br> Could you give me an example where the PC is hard coded. The OpenRISC architecture will always boot through it's reset vector at location 0x100 (that is part of the architecture definition). However programs may be stored at other addresses, for example in ROM and copied to RAM to execute. Linux boots in this way for example.<br> <br> Jeremy

swaka commented over 15 years ago

I may mistake.

It can boot from 0xf0000100 using gdb. % or32-uclinux-sim -f tmp.cfg

(gdb) file tmp (gdb) load tmp (gdb) info spr 0 18 SYS.PPC = SPR0_18 = 0 (0x0) (gdb) spr 0 18 0xf0000100 SYS.PPC (SPR0_18) set to 4026532096 (0xf0000100), was: 0 (0x0) (gdb) c Continuing.

But in no gdb environment, it did not work. % or32-uclinux-sim -f tmp.cfg prog/tmp Verbose on, simdebug on, interactive prompt off Machine initialization... Clock cycle: 10ns No data cache. No instruction cache. BPB simulation off. BTIC simulation off. Building automata... done, num uncovered: 0/213. Parsing operands data... done. Resetting Tick Timer. Resetting Power Management. Resetting PIC. Starting at 0x00000000 loadcode: filename ../030tmp2/progsor32/uart_loop startaddr=00000000 virtphy transl=00000000 Not COFF file format ELF type: 0x0002 ELF machine: 0x005c ELF version: 0x00000001 ELF sec = 11 Section: .text, vaddr: 0xf0000000, paddr: 0xf0000000 offset: 0x00002000, size: 0 x0000168c Section: .rodata, vaddr: 0xf000168c, paddr: 0xf000168c offset: 0x0000368c, size: 0x0000000c <stall>

Here is my configuration.

section memory type = unknown name = "RAM" ce = 0 mc = 0 baseaddr = 0xf0000000 size = 0x00400000 delayr = 1 delayw = 2 end

section cpu ver = 0x1200 rev = 0x0001 superscalar = 0 hazards = 0 dependstats = 0 sbuf_len = 0 sr = 0x4001 end

I would like to boot from 0xf0000100 without gdb.

Regards, swaka

swaka commented over 15 years ago

Hi~

I found the root cause.~ 2 parts should be modified.

cpu/or32/execute.c~ pcnext = (cpu_state.sprsSPR_SR & SPR_SR_EPH ? 0xf0000000 : 0x00000000); // ADD~ if (config.sim.verbose)~ {~ PRINTF ("Modify Starting at 0x%" PRIxADDR "\n", pcnext);~ }~ ~ ...~ //snip except_pending = 0;~ oraddr_t swnext = (cpu_state.sprsSPR_SR & SPR_SR_EPH ? 0xf0000000 : 0x00000000); //ADD~ cpu_state.pc = swnext + EXCEPT_RESET; //MODIFY~

Could you check?~

jeremybennett commented over 15 years ago

Hi Swaka,

The website mangled your previous comment (you need to add <br> after each line - its a known bug). I think you tried to say:<br> <br> Hi<br> I found the root cause.<br> 2 parts should be modified. cpu/or32/execute.c<br> pcnext = (cpu_state.sprsSPR_SR & SPR_SR_EPH ? 0xf0000000 : 0x00000000); // ADD<br> if (config.sim.verbose)<br> {<br> PRINTF ("Modify Starting at 0x%" PRIxADDR "\n", pcnext);<br> }<br> <br> ...<br> //snip except_pending = 0;<br> oraddr_t swnext = (cpu_state.sprsSPR_SR & SPR_SR_EPH ? 0xf0000000 : 0x00000000); //ADD<br> cpu_state.pc = swnext + EXCEPT_RESET; //MODIFY<br> Could you check?<br> <br> I cannot find this code in the file cpu/or32/execute.c. Please could you check again and explain further. It is clearest if you provide your suggestions as either the complete file, or as a diff file.<br>

jeremybennett commented over 15 years ago

I meant to say add <br> to the end of each line in my previous comment.<br> <br> I suggest this discussion is best continued on the OpenRISC mailing list, so others can contribute (openrisc@opencores.org). That will also avoid formatting problems.

swaka commented over 15 years ago

Hi I provide diff file.

--- or1k/or1ksim.new/cpu/or32/execute.c 2009-01-16 12:04:23.000000000 +0900 <br> +++ or1k/or1ksim.org/cpu/or32/execute.c 2008-11-11 22:24:07.000000000 +0900 <br> @@ -863,12 +863,11 @@<br> <br> <br> / MM1409: All progs should start at reset vector entry! This sorted out by setting the cpu_state.pc field below. Not clear this is very good code! /<br>

-// pcnext = 0x0;<br> -pcnext = (cpu_state.sprsSPR_SR & SPR_SR_EPH ? 0xf0000000 : 0x00000000);<br>

  • pcnext = 0x0;<br> +<br> if (config.sim.verbose)<br> {<br> PRINTF ("Starting at 0x%" PRIxADDR "\n", pcnext);<br> }<br> <br> cpu_state.pc = pcnext;<br> @@ -881,8 +880,7 @@<br> #endif<br> <br> except_pending = 0;<br> -oraddr_t swnext = (cpu_state.sprsSPR_SR & SPR_SR_EPH ? 0xf0000000 : 0x00000000);<br>
  • cpu_state.pc = swnext + EXCEPT_RESET;<br>
  • cpu_state.pc = EXCEPT_RESET;<br> <br> } / cpu_reset() /<br> <br> <br>
jeremybennett commented over 15 years ago

This is clearly a bug. I'll aim to fix it in the next release. Thanks for finding the problem and suggesting the fix.<br> <br> Jeremy

jeremybennett commented about 15 years ago

Fixed in Or1ksim 0.3.0rc3. This appears to be just a localized problem with start up reset vector. Other exception vector handling already recognizes this flag.

jeremybennett was assigned about 15 years ago
jeremybennett closed this about 15 years ago

Assignee
jeremybennett
Labels
Request