headers
Julius Baxter | 15 Dec 2011 18:49
Picon

Re: [ORLinux] [OpenRISC] Memory Init that allows Linux simulation

On Thu, Dec 15, 2011 at 5:10 PM, Matthew Hicks <firefalcon <at> gmail.com> wrote:
> On Thu, Dec 15, 2011 at 10:09 AM, Julius Baxter <juliusbaxter <at> gmail.com>
> wrote:
>>
>> On Thu, Dec 15, 2011 at 3:57 PM, Matthew Hicks <firefalcon <at> gmail.com>
>> wrote:
>> > The method I used is just as synthesizable as the readmem tasks, plus
>> > you
>> > don't need to keep an external file.  The method I used is also more
>> > modular
>> > and scalable than readmem.
>> >
>> > I agree that a better fix is to correct the OR32 boot code, but I also
>> > like
>> > initializing the memories to make RTL simulation closer to hardware
>> > execution.
>> >
>>
>> If you want to make the RTL simulation closer to what you experience
>> with hardware, I would fill the RAMs with random values, not zeroes.
>>
> I agree.
>
>>
>> Sometimes it's good to have X go everywhere, because it doesn't let
>> you get away with not initialising things properly. In this case I
>> think X is a good thing.
>>
> I agree here to, but when the software doesn't initialize things properly,
> it is a pain to debug.  The simulation doesn't just stop, it locks.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Olof Kindgren | 16 Dec 2011 09:19
Picon

Re: [ORLinux] [OpenRISC] Memory Init that allows Linux simulation

2011/12/15 Julius Baxter <juliusbaxter <at> gmail.com>:
> On Thu, Dec 15, 2011 at 5:10 PM, Matthew Hicks <firefalcon <at> gmail.com> wrote:
>> On Thu, Dec 15, 2011 at 10:09 AM, Julius Baxter <juliusbaxter <at> gmail.com>
>> wrote:
>>>
>>> On Thu, Dec 15, 2011 at 3:57 PM, Matthew Hicks <firefalcon <at> gmail.com>
>>> wrote:
>>> > The method I used is just as synthesizable as the readmem tasks, plus
>>> > you
>>> > don't need to keep an external file.  The method I used is also more
>>> > modular
>>> > and scalable than readmem.
>>> >
>>> > I agree that a better fix is to correct the OR32 boot code, but I also
>>> > like
>>> > initializing the memories to make RTL simulation closer to hardware
>>> > execution.
>>> >
>>>
>>> If you want to make the RTL simulation closer to what you experience
>>> with hardware, I would fill the RAMs with random values, not zeroes.
>>>
>> I agree.
>>
>>>
>>> Sometimes it's good to have X go everywhere, because it doesn't let
>>> you get away with not initialising things properly. In this case I
>>> think X is a good thing.
>>>
>> I agree here to, but when the software doesn't initialize things properly,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Kristiansson | 16 Dec 2011 13:51
Picon
Picon
Favicon

Re: [ORLinux] [OpenRISC] [Openrisc] Memory Init that allows Linux simulation

On 12/16/2011 11:06 AM, Richard Herveille wrote:
The problem, perhaps, is that the register clear is assuming that r0 really is 0...??? Perhaps the first thing we should be doing is loading r0 with a 0: l.movhi r0,hi(0) l.ori r0,r0,0
I don't think that piece of code loads R0 with '0' ... Assume R0 is NOT zero then: movhi r0,hi(0) --> set MSBs to 0 ori r0,r0,0 --> logic OR of R0 with R0 and '0' ... This does NOT clear the LSBs!!
That's why I use:
__reset: /* there is no guarantee r0 is hardwired to zero, clear it here */ l.andi r0, r0, 0 in u-boot So consensus is, everybody should just use u-boot to load Linux and everything will work as intended ;) Joking aside, that movhi will zero the LSB of r0, so really, that ori isn't necessary Stefan
_______________________________________________
Linux mailing list
Linux <at> lists.openrisc.net
http://lists.openrisc.net/listinfo/linux
Permalink | Reply | 0 comments |

Gmane