[U-Boot-Users] MPC8349EMDS port
Wolfgang,
I was looking at merging the EMDS and ADS ports for MPC834x and was wondering about a few things:
* EMDS has TEXT_BASE @ 0xFE000000, and ADS at 0xFE700000 where do you end up programming u-boot at? (for example what is the flash command you use to reprogram a u-boot image on the board).
* I had to rework the BATs to be able to cover everything properly which also meant moving a few things around. CFG_BCSR 0xF8000000 -> 0xE2400000 CFG_INIT_RAM_ADDR 0xE8000000 -> 0xFD000000
This is so we can fit everything into the 8 BATS and maintain proper WIMG settings.
If you can explain the TEXT_BASE difference and how that works out and are ok with the changing of CFG_BCSR and CFG_INIT_RAM_ADDR then I'll push some patches to merge ADS & MDS, remove ADS, and we get PCI support on EMDS out of it.
let me know.
- kumar
Any update on this?
- k
On Mar 30, 2006, at 11:20 AM, Kumar Gala wrote:
Wolfgang,
I was looking at merging the EMDS and ADS ports for MPC834x and was wondering about a few things:
- EMDS has TEXT_BASE @ 0xFE000000, and ADS at 0xFE700000 where do
you end up programming u-boot at? (for example what is the flash command you use to reprogram a u-boot image on the board).
- I had to rework the BATs to be able to cover everything properly
which also meant moving a few things around. CFG_BCSR 0xF8000000 -> 0xE2400000 CFG_INIT_RAM_ADDR 0xE8000000 -> 0xFD000000
This is so we can fit everything into the 8 BATS and maintain proper WIMG settings.
If you can explain the TEXT_BASE difference and how that works out and are ok with the changing of CFG_BCSR and CFG_INIT_RAM_ADDR then I'll push some patches to merge ADS & MDS, remove ADS, and we get PCI support on EMDS out of it.
let me know.
- kumar
This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel? cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Dear Kumar,
in message F74FD79C-8F46-4465-93FB-54ADA4D017BC@kernel.crashing.org you wrote:
Any update on this?
Sorry for the delay...
I was looking at merging the EMDS and ADS ports for MPC834x and was wondering about a few things:
- EMDS has TEXT_BASE @ 0xFE000000, and ADS at 0xFE700000 where do
you end up programming u-boot at? (for example what is the flash command you use to reprogram a u-boot image on the board).
We use exactly this address 0xFE000000, here is a command:
protect off FE000000 +${filesize}; era FE000000 +${filesize}; cp.b 100000 FE000000 ${filesize}
- I had to rework the BATs to be able to cover everything properly
which also meant moving a few things around. CFG_BCSR 0xF8000000 -> 0xE2400000 CFG_INIT_RAM_ADDR 0xE8000000 -> 0xFD000000
This is so we can fit everything into the 8 BATS and maintain proper WIMG settings.
If you can explain the TEXT_BASE difference and how that works out and are ok with the changing of CFG_BCSR and CFG_INIT_RAM_ADDR then I'll push some patches to merge ADS & MDS, remove ADS, and we get PCI support on EMDS out of it.
These selection of addresses was made by a customer in his initial patch. I think the customer was trying to follow the memory map which is defined in the board User's Manual. And we just didn't change that. But I think that moving things around as you suggest should be fine as well.
Best regards,
Wolfgang Denk
On Apr 7, 2006, at 5:35 AM, Wolfgang Denk wrote:
Dear Kumar,
in message F74FD79C-8F46-4465-93FB-54ADA4D017BC@kernel.crashing.org you wrote:
Any update on this?
Sorry for the delay...
No problem. I figured removing a second board port for the same HW would be a good thing :)
I was looking at merging the EMDS and ADS ports for MPC834x and was wondering about a few things:
- EMDS has TEXT_BASE @ 0xFE000000, and ADS at 0xFE700000 where do
you end up programming u-boot at? (for example what is the flash command you use to reprogram a u-boot image on the board).
We use exactly this address 0xFE000000, here is a command:
protect off FE000000 +${filesize}; era FE000000 +${filesize}; cp.b 100000 FE000000 ${filesize}
Where do you have the HW Config words coming from (BCSR, FLASH, ..)? When I use TEXT_BASE @ 0xFE000000 my system doesn't boot, I'll try out the command you suggest and see what happens.
- I had to rework the BATs to be able to cover everything properly
which also meant moving a few things around. CFG_BCSR 0xF8000000 -> 0xE2400000 CFG_INIT_RAM_ADDR 0xE8000000 -> 0xFD000000
This is so we can fit everything into the 8 BATS and maintain proper WIMG settings.
If you can explain the TEXT_BASE difference and how that works out and are ok with the changing of CFG_BCSR and CFG_INIT_RAM_ADDR then I'll push some patches to merge ADS & MDS, remove ADS, and we get PCI support on EMDS out of it.
These selection of addresses was made by a customer in his initial patch. I think the customer was trying to follow the memory map which is defined in the board User's Manual. And we just didn't change that. But I think that moving things around as you suggest should be fine as well.
I'll make this change then.
- kumar
I was looking at merging the EMDS and ADS ports for MPC834x and was wondering about a few things:
- EMDS has TEXT_BASE @ 0xFE000000, and ADS at 0xFE700000 where do
you end up programming u-boot at? (for example what is the flash command you use to reprogram a u-boot image on the board).
We use exactly this address 0xFE000000, here is a command:
protect off FE000000 +${filesize}; era FE000000 +${filesize}; cp.b 100000 FE000000 ${filesize}
Where do you have the HW Config words coming from (BCSR, FLASH, ..)? When I use TEXT_BASE @ 0xFE000000 my system doesn't boot, I'll try out the command you suggest and see what happens.
I tried your command and putting the image at 0xFE000000, I'm not sure I see how this works because 0xFE000000 will alias to 0xFF800000. However, the reset vector at 0xFFF00100 will alias down to 0xFE700100. So how do you end up with valid code at the reset vector if your TEST_BASE is 0xFE000000?
- kumar
On Wed, Apr 12, 2006 at 11:58:53 -0500, Kumar Gala wrote:
I tried your command and putting the image at 0xFE000000, I'm not sure I see how this works because 0xFE000000 will alias to 0xFF800000. However, the reset vector at 0xFFF00100 will alias down to 0xFE700100. So how do you end up with valid code at the reset vector if your TEST_BASE is 0xFE000000?
How is this masking/aliasing done/configured? We are trying to boot a 8347 board without BCSR and started putting the flash @0xff000000 to have the bootloader start at 0xfff00000 where it stores the RCW.
When stepping through the bootloader code (and putting TEXT_BASE @0xff000000 instead of 0xfff00000, we see that it is going rather far, but it is not booting, nor has it any serial output; which makes us suspect that something is wrong with our configuration registers.
Being able to alias 0xfff00000 to 0xfe000000 would keep our port very close to your port (and as such working); but I am missing the initial boot step:
If I have a look at the RCWH of the EMDS port, it boots from 0x00000100 and not from 0xfff00100; which is mapped to RAM.
Being able to alias 0xfff00000 to 0xfe000000 would keep our port very close to your port (and as such working); but I am missing the initial boot step:
If I have a look at the RCWH of the EMDS port, it boots from 0x00000100 and not from 0xfff00100; which is mapped to RAM.
My fault (as expected); we did too much configuration in our bdi config: by the time it booted, the ORn and BRn registers were set with the final values, remapping flash and memory and not the default power on values.
Still work in progress, but the EDMS port works almost out of the box; though the cs for DDR needed to be configurable in the config file instead of 2/3; support for some spansion flash and BCSR in board initialisation is only compiled when it is used/defined in the config file.
Great work for the EDMS/ADS port.
Next hurdle: TSEC0: PHY id ffffffff is not supported! :)
What is the proper approach for a board variation: keep a single port that is configured with different config/*.h files; possibly adding/compiling more commands in the board directory based on the define (e.g. flash support); or simply branching the port with quite some code duplication that diverge? The first option might clutter the *.c code with ifdefs while the second one keeps the code clearly/cleanly seperate.
participants (3)
-
Kumar Gala -
Marc Leeman -
Wolfgang Denk