[U-Boot-Users] IVT on 405GP
Greetings:
If someone out there has a 405GP running with u-boot, I'd really appreciated a snapshot of the interrupt vector table. It appears that though the vector and and the int return vector are getting copied, however if prior to running u-boot I zero out all memory in the IVT, I see that not Prologue code etc is getting coping into those ares.
If I look at "trap_init" it appears as though it does not copy code, and only sets vectors.
If I look at "relocate_code" it appears as though it only starts to copy code from the top of the boot rom to the end. I do not see where the interrupt vectors are stored in the bootrom - although they must - so I must be missing a simple calculation someplace -
Any assistance is greatly appreciated.
Jerry Walden
If someone out there has a 405GP running with u-boot, I'd really appreciated a snapshot of the interrupt vector table. It appears that though the vector and and the int return vector are getting copied, however if prior to running u-boot I zero out all memory in the IVT, I see that not Prologue code etc is getting coping into those ares.
If I look at "trap_init" it appears as though it does not copy code, and only sets vectors.
If I look at "relocate_code" it appears as though it only starts to copy code from the top of the boot rom to the end. I do not see where the interrupt vectors are stored in the bootrom - although they must - so I must be missing a simple calculation someplace -
Any assistance is greatly appreciated.
Hi Jerry.
I encountered a similar problem with the 405EP eval. board. There is an active thread about it called "Interrupt management under PPC4xx platform" I started on April, 14th (in particular have a look at this message: http://sourceforge.net/mailarchive/message.php?msg_id=4349650). Did not you receive the messages I wrote to it (I put this address jwalden -at- digitalatlantic.com in copy)?
Hope this helps.
llandre
Hi Jerry!
Please find attached a binary file with a memory dump (address 0x0000--0x3fff) of our CPCI-405 board (PPC405GP based). I initialized the memory with 0xaa and then started U-Boot. You can see, which memory locations are written (with exception vector code) from U-Boot.
Hope this helps...
Best regards, Stefan.
If someone out there has a 405GP running with u-boot, I'd really appreciated a snapshot of the interrupt vector table. It appears that though the vector and and the int return vector are getting copied, however if prior to running u-boot I zero out all memory in the IVT, I see that not Prologue code etc is getting coping into those ares.
If I look at "trap_init" it appears as though it does not copy code, and only sets vectors.
If I look at "relocate_code" it appears as though it only starts to copy code from the top of the boot rom to the end. I do not see where the interrupt vectors are stored in the bootrom - although they must - so I must be missing a simple calculation someplace -
Any assistance is greatly appreciated.
Jerry Walden
This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Thanks Stefan:
Just reading some uboot install stuff and it appear to say what I am doing is ok but it does not seem to do everything. It say that it copies itself to upper memory then it should copy 8k of vector stuff to zero. So it looks like somehow I am missing the vector copy code, or it is not working.
Again it appears as though "trap init" initializes some vectors in the IVT, however it does not copy the code prologue and exception code. Can you see in the code where the contents of the first 8k of memory is copied?
Thanks Jerry Walden
-----Original Message----- From: u-boot-users-admin@lists.sourceforge.net [mailto:u-boot-users-admin@lists.sourceforge.net]On Behalf Of Stefan Roese Sent: Wednesday, April 16, 2003 8:06 AM To: Jerry Walden; u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] IVT on 405GP
Hi Jerry!
Please find attached a binary file with a memory dump (address 0x0000--0x3fff) of our CPCI-405 board (PPC405GP based). I initialized the memory with 0xaa and then started U-Boot. You can see, which memory locations are written (with exception vector code) from U-Boot.
Hope this helps...
Best regards, Stefan.
If someone out there has a 405GP running with u-boot, I'd really appreciated a snapshot of the interrupt vector table. It appears that though the vector and and the int return vector are getting copied, however if prior to running u-boot I zero out all memory in the IVT, I see that not Prologue code etc is getting coping into those ares.
If I look at "trap_init" it appears as though it does not copy code, and only sets vectors.
If I look at "relocate_code" it appears as though it only starts to copy code from the top of the boot rom to the end. I do not see where the interrupt vectors are stored in the bootrom - although they must - so I must be missing a simple calculation someplace -
Any assistance is greatly appreciated.
Jerry Walden
This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Jerry,
in message EGEGIJHKDKJGAJMGIDPNMEPACKAA.jwalden@digitalatlantic.com you wrote:
Just reading some uboot install stuff and it appear to say what I am doing is ok but it does not seem to do everything. It say that it copies itself to upper memory then it should copy 8k of vector stuff to zero. So it looks like somehow I am missing the vector copy code, or it is not working.
Again it appears as though "trap init" initializes some vectors in the IVT, however it does not copy the code prologue and exception code. Can you see in the code where the contents of the first 8k of memory is copied?
I really don't understand what this discussion is all about.
Please look at the code yourself. It is not that complicated to understand. See "cpu/ppc4xx/start.S":
... 1366 /* 1367 * Copy exception vector code to low memory 1368 * 1369 * r3: dest_addr 1370 * r7: source address, r8: end address, r9: target address 1371 */ 1372 .globl trap_init 1373 trap_init: 1374 lwz r7, GOT(_start) 1375 lwz r8, GOT(_end_of_vectors) 1376 1377 rlwinm r9, r7, 0, 18, 31 /* _start & 0x3FFF */ 1378 1379 cmplw 0, r7, r8 1380 bgelr /* return if r7>=r8 - just in case */ 1381 1382 mflr r4 /* save link register */ 1383 1: 1384 lwz r0, 0(r7) 1385 stw r0, 0(r9) 1386 addi r7, r7, 4 1387 addi r9, r9, 4 1388 cmplw 0, r7, r8 1389 bne 1b ...
Guess what this 1: ... "bne 1b" loop is doing?
The code is really simple, and I don't know why you are missing it when reading the sources or when running under a debugger. And the function name "trap_init()" is IMHO well chosen and descriptive enough, too. And there is even a comment which explains what it does.
The only thing I can see that could go wrong here is that the computation of the end address (r9 = _start & 0x3FFF) might fail if you pass bogus values for _start to that code. Please note that the code assumes that it has been started from the reset entry point, i. e. _start is at a well known address, and "_start & 0x3FFF" is equivalent to 0x100 ;-) But then, this should be trivial to check, and I assume you already checked it under a debugger, didn't you?
Wolfgang Denk
I really don't understand what this discussion is all about.
Please look at the code yourself. It is not that complicated to understand. See "cpu/ppc4xx/start.S":
Sorry if I am upsetting the members of the list, I was just trying to develop some understanding of what the code in trap_init does. I KNOW that there must be code to copy the IVT, and I studied the section that you pointed out in trap_init, I simply am weak at PPC assembly and mistundestood some of the instructions - I suppose I should have posted it to the PPC-assembly users list if there is one.
Guess what this 1: ... "bne 1b" loop is doing?
I figured that out all by myself...
The code is really simple, and I don't know why you are missing it when reading the sources or when running under a debugger. And the function name "trap_init()" is IMHO well chosen and descriptive enough, too. And there is even a comment which explains what it does.
The code is simple to you - not to me - however now that I have gone through this learning process - it looks simple to me.
The only thing I can see that could go wrong here is that the computation of the end address (r9 = _start & 0x3FFF) might fail if you pass bogus values for _start to that code. Please note that the code assumes that it has been started from the reset entry point, i. e. _start is at a well known address, and "_start & 0x3FFF" is equivalent to 0x100 ;-) But then, this should be trivial to check, and I assume you already checked it under a debugger, didn't you?
Yes - of course I checked it under the debugger
Thanks for the response. I think my problem may be the base uboot address. The address is 0x3fcf000. The mask is 3fff. If my uboot started on a nice 16 bit address then the result would be 0(3fc0000 & 3fff) but I was getting 0xf000(3fcf000 & 3fff). So I think that the fix is to move uboot down to 0x3fc0000 or 0x3fc8000.
Jerry Walden
-----Original Message----- From: wd@denx.de [mailto:wd@denx.de] Sent: Wednesday, April 16, 2003 3:17 PM To: jwalden@digitalatlantic.com Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] IVT on 405GP
Jerry,
in message EGEGIJHKDKJGAJMGIDPNMEPACKAA.jwalden@digitalatlantic.com you wrote:
Just reading some uboot install stuff and it appear to say what I am doing is ok but it does not seem to do everything. It say that it copies itself to upper memory then it should copy 8k of vector stuff to zero. So it looks like somehow I am missing the vector copy code, or it is not working.
Again it appears as though "trap init" initializes some vectors in the
IVT,
however it does not copy the code prologue and exception code. Can you see in the code where the contents of the first 8k of memory is copied?
I really don't understand what this discussion is all about.
Please look at the code yourself. It is not that complicated to understand. See "cpu/ppc4xx/start.S":
... 1366 /* 1367 * Copy exception vector code to low memory 1368 * 1369 * r3: dest_addr 1370 * r7: source address, r8: end address, r9: target address 1371 */ 1372 .globl trap_init 1373 trap_init: 1374 lwz r7, GOT(_start) 1375 lwz r8, GOT(_end_of_vectors) 1376 1377 rlwinm r9, r7, 0, 18, 31 /* _start & 0x3FFF */ 1378 1379 cmplw 0, r7, r8 1380 bgelr /* return if r7>=r8 - just in case */ 1381 1382 mflr r4 /* save link register */ 1383 1: 1384 lwz r0, 0(r7) 1385 stw r0, 0(r9) 1386 addi r7, r7, 4 1387 addi r9, r9, 4 1388 cmplw 0, r7, r8 1389 bne 1b ...
Guess what this 1: ... "bne 1b" loop is doing?
The code is really simple, and I don't know why you are missing it when reading the sources or when running under a debugger. And the function name "trap_init()" is IMHO well chosen and descriptive enough, too. And there is even a comment which explains what it does.
The only thing I can see that could go wrong here is that the computation of the end address (r9 = _start & 0x3FFF) might fail if you pass bogus values for _start to that code. Please note that the code assumes that it has been started from the reset entry point, i. e. _start is at a well known address, and "_start & 0x3FFF" is equivalent to 0x100 ;-) But then, this should be trivial to check, and I assume you already checked it under a debugger, didn't you?
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de If it has syntax, it isn't user friendly.
In message EGEGIJHKDKJGAJMGIDPNOEPICKAA.jwalden@digitalatlantic.com you wrote:
Thanks for the response. I think my problem may be the base uboot address. The address is 0x3fcf000. The mask is 3fff. If my uboot started on a nice 16 bit address then the result would be 0(3fc0000 & 3fff) but I was getting 0xf000(3fcf000 & 3fff). So I think that the fix is to move uboot down to 0x3fc0000 or 0x3fc8000.
I have warned often enough NOT to try to start U-Boot from RAM unless you know _EXACTLY_ what you are doing.
You tried, and you failed. You kind of got what you deserved ;-)
Put U-Boot in flash, and start it from the reset entry point like it was designed for, and everything will be fine.
Actually I have to admit that I don't remember why the target address was computed using "& 3fff" instead of a hard-wired 0x100. I don't even remember where I got this code fragment from.
A similar assumption is buried in the code relocation stuff - see llandre's problem when setting CFG_MONITOR_BASE to a value that was not a multiple of 16 k.
We probably should get rid of this ASAP.
Wolfgang Denk
No -- that is not what I did - I did not start u-boot from RAM what I meant to say is that in the debugger the base address
r3 = 0x03fcf000 = not used r7 = 0x03fcf100 = _start r8 = 0x03fd1090 = _end_of_vectors r9 = 0x3100 = - this is incorrect
what I should have said is I need to place a number in CONFIG_MONITOR_LEN that makes the calculation for the address of _start in relocate_code to be something like 0x3fc0000 - right now I have it set to (196 * 1024) which is used to calculate _start - that is what I need to change.
Jerry Walden
-----Original Message----- From: wd@denx.de [mailto:wd@denx.de] Sent: Wednesday, April 16, 2003 4:47 PM To: jwalden@digitalatlantic.com Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] IVT on 405GP
In message EGEGIJHKDKJGAJMGIDPNOEPICKAA.jwalden@digitalatlantic.com you wrote:
Thanks for the response. I think my problem may be the base uboot address. The address is 0x3fcf000. The mask is 3fff. If my uboot started on a nice 16
bit
address then the result would be 0(3fc0000 & 3fff) but I was getting 0xf000(3fcf000 & 3fff). So I think that the fix is to move uboot down to 0x3fc0000 or 0x3fc8000.
I have warned often enough NOT to try to start U-Boot from RAM unless you know _EXACTLY_ what you are doing.
You tried, and you failed. You kind of got what you deserved ;-)
Put U-Boot in flash, and start it from the reset entry point like it was designed for, and everything will be fine.
Actually I have to admit that I don't remember why the target address was computed using "& 3fff" instead of a hard-wired 0x100. I don't even remember where I got this code fragment from.
A similar assumption is buried in the code relocation stuff - see llandre's problem when setting CFG_MONITOR_BASE to a value that was not a multiple of 16 k.
We probably should get rid of this ASAP.
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de How does a project get to be a year late? ... One day at a time.
In message EGEGIJHKDKJGAJMGIDPNOEPJCKAA.jwalden@digitalatlantic.com you wrote:
what I should have said is I need to place a number in CONFIG_MONITOR_LEN that makes the calculation for the address of _start in relocate_code to be something like 0x3fc0000 - right now I have it set to (196 * 1024) which is used to calculate _start - that is what I need to change.
I see.
We will modify the CONFIG_MONITOR_LEN related code soon. It was wrong to use this #define for too many too different things. [Unfortunately we will not get completely rid of it - CONFIG_MONITOR_LEN will only be used to determine if the flash is embedded in the U-Boot image or not, nothing else. We could remove it there, too, but this would blow up code size beyond acceptable limits.]
Best regards,
Wolfgang Denk
participants (5)
-
Jerry Walden -
Jerry Walden -
llandre -
Stefan Roese -
Wolfgang Denk