[U-Boot-Users] IVPR on E500

[Nuno João (Ext_NBS)]

Hello Kylo,

Thank you for the answer.
After the relocation done by your patch, IVPR is relocated again,
to 0x0, when trap_init() (start.S) is called inside board_init_r().
trap_init() relocates the exception handlers to 0x0.
This means that, when you get to the linux kernel boot, IVPR
is at the same place as it was before your patch (this init_trap()
code is earlier than your patch)... or am I missing something?

Thank you and Best Regards

On 12/8/05, Kylo Ginsberg <kylo.ginsberg at gmail.com> wrote:
> That was my patch, but I need to work from memory as I'm at a
> different job w/o an E500 at hand.  As I recall, the problem was this:

> --there is a window during very early linux startup when it has
> removed the TLB entries setup by u-boot and is building its own
> --using a BDI2000 trying to set breakpoints in this part of the linux code
> --the E500 part wants to fetch the debug vector before passing control
> to the BDI
> --if this fetch goes to an unmapped region of address space, the E500
> is off in the weeds and stops responding to the BDI

> Relocating the IVPR to ram at the same time that the rest of the image
> is moved to ram addressed this problem.

> I don't recall the third piece of code that you mention, so I don't
> know how that interacts.  (And my attempt to cg-clone u-boot.git gave
> me a 404 error for one of the pack files part way through the
> download; I'll try again later.)

On 12/7/05, Nuno João (Ext_NBS) <nuno.joao-ext_nbs at siemens.com> wrote:
> I've noticed some E500 related files (start.S and lib-ppc/board.c,
> I don't know if others) have been changed with comment
> "E500 update: repoint IVPR to RAM when code is relocated".
> I don't understand the need for this change. Traps start in flash,
> with IVPR set to TEXT_BASE in start.S. Later, this recent patch
> relocates them to the same code but now in ram, after u-boot's
> relocation. Later in lib_ppc/board.c:board_init_r() they are
> then relocated to the beggining of ram (IVPR = 0).
> Why do we need this "IVPR dance"? What does the "repoint IVPR do
> RAM" patch fixes?