[U-Boot-Users] [PATCH 00/07 v2]: Add mpc7448hpc2 (Taiga) board support
This series of patches add mpc7448hpc2 board support. Mpc7448hpc2 (taiga) board is a high-performance PowerPC server reference design.
This is the second version for this board support according to the feedback from mailing list. Roy
Signed-off-by: Roy Zang tie-fei.zang@freescale.com
--- doc/README.mpc7448hpc2 | 181 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 181 insertions(+), 0 deletions(-)
diff --git a/doc/README.mpc7448hpc2 b/doc/README.mpc7448hpc2 new file mode 100644 index 0000000..00fda4e --- /dev/null +++ b/doc/README.mpc7448hpc2 @@ -0,0 +1,181 @@ +Freescale MPC7448hpc2 (Taiga) board +-------------------------- +MPC7448hpc2 (Taiga) board is a high-performance PowerPC server reference +design, which is optimized for high speed throughput between the processor and +the memory, disk drive and Ethernet port subsystems. + +MPC7448hpc2(Taiga) is designed to the micro-ATX chassis, allowing it to be +used in 1U or 2U rack-mount chassis', as well as in standard ATX/Micro-ATX +chassis. + + +Memory Map +---------- + +The memory map is setup for Linux to operate properly. + +The mapping is: + + Range Start Range End Definition Size + + 0x0000_0000 0x7fff_ffff DDR 2G + 0xe000_0000 0xe7ff_ffff PCI Memory 128M + 0xfa00_0000 0xfaff_ffff PCI IO 16M + 0xfb00_0000 0xfbff_ffff PCI Config 16M + 0xfc00_0000 0xfc0f_ffff NVRAM/CADMUS 1M + 0xfe00_0000 0xfeff_ffff PromJet 16M + 0xff00_0000 0xff80_0000 FLASH (boot flash) 8M + 0xff80_0000 0xffff_ffff FLASH (second half flash) 8M + + +Using Flash +----------- + +The MPC7448hpc2 board has two "banks" of flash, each 8MB in size +(2^23 = 0x00800000). + +Note: the "bank" here refers to half of the flash. In fact, there is only one +bank of flash, which is divided into low and high half. Each is controlled by +the most significant bit of the address bus. The so called "bank" is only for +convenience. + +There is a switch which allows the "bank" to be selected. The switch +settings for updating flash are given below. + +The u-boot commands for copying the boot-bank into the secondary bank are +as follows: + + erase ff800000 ff880000 + cp.b ff000000 ff800000 80000 + +U-boot commands for downloading an image via tftp and flashing +it into the secondary bank: + + tftp 10000 <u-boot.bin.image> + erase ff000000 ff080000 + cp.b 10000 ff000000 80000 + + +After copying the image into the second bank of flash, be sure to toggle +SW3[4] on board before resetting the board in order to set the +secondary bank as the boot-bank. + + +Board Switches +---------------------- + + +Most switches on the board should not be changed. The most frequent +user-settable switches on the board are used to configure +the flash banks and determining the PCI frequency. + +SW1[1-5]: Processor core voltage + + 12345 Core Voltage + ----- + SW1=01111 1.000V. + SW1=01101 1.100V. + SW1=01011 1.200V. + SW1=01001 1.300V only for MPC7447A. + + +SW2[1-6]: CPU core frequency + + CPU Core Frequency (MHz) + Bus Frequency + 123456 100 133 167 200 Ratio + + ------ + SW2=101100 500 667 833 1000 5x + SW2=100100 550 733 917 1100 5.5x + SW2=110100 600 800 1000 1200 6x + SW2=010100 650 866 1083 1300 6.5x + SW2=001000 700 930 1167 1400 7x + SW2=000100 750 1000 1250 1500 7.5x + SW2=110000 800 1066 1333 1600 8x + SW2=011000 850 1333 1417 1700 8.5x only for MPC7447A + SW2=011110 900 1200 1500 1800 9x + +This table shows only a subset of available frequency options; see the CPU +hardware specifications for more information. + + +SW2[7-8]: Bus Protocol and CPU Reset Option + + 7 + - + SW2=0 System bus uses MPX bus protocol + SW2=1 System bus uses 60x bus protocol + + 8 + - + SW2=0 TSI108 can cause CPU reset + SW2=1 TSI108 can not cause CPU reset + + +SW3[1-8] system options + + 123 + --- + SW3=xxx Connected to GPIO[0:2] on TSI108 + + 4 + - + SW3=0 CPU boots from low half of flash + SW3=1 CPU boots from high half of flash + + 5 + - + SW3=0 SATA and slot2 connected to PCI bus + SW3=1 Only slot1 connected to PCI bus + + 6 + - + SW3=0 USB connected to PCI bus + SW3=1 USB disconnected from PCI bus + + 7 + - + SW3=0 Flash is write protected + SW3=1 Flash is NOT write protected + + 8 + - + SW3=0 CPU will boot from flash + SW3=1 CPU will boot from PromJet + +SW4[1-3]: System bus frequency + + Bus Frequency (MHz) + --- + SW4=010 183 + SW4=011 100 + SW4=100 133 + SW4=101 166 only for MPC7447A + SW4=110 200 only for MPC7448 + others reserved + + +SW4[4-6]: DDR2 SDRAM frequency + + Bus Frequency (MHz) + --- + SW4=000 external clock + SW4=011 system clock + SW4=100 133 + SW4=101 166 + SW4=110 200 + others reserved + + +SW4[7-8]: PCI/PCI-X frequency control + 7 + - + SW4=0 PCI/PCI-X bus operates normally + SW4=1 PCI bus forced to PCI-33 mode + + 8 + - + SW4=0 PCI-X mode at 133 MHz allowed + SW4=1 PCI-X mode limited to 100 MHz +
On Fri, 2006-08-11 at 18:44, Zang Roy-r61911 wrote:
This series of patches add mpc7448hpc2 board support. Mpc7448hpc2 (taiga) board is a high-performance PowerPC server reference design.
This is the second version for this board support according to the feedback from mailing list. Roy
Hi,all I do not get any feedback about this serial of patches. How about them? Should I resubmit the patches based on the updated u-boot git tree. Thanks. Roy
Dear Roy,
in message 1162192299.15118.3.camel@localhost.localdomain you wrote:
I do not get any feedback about this serial of patches. How about them?
They are sitting in my queue, waiting to be processed. We are catching up, but it's a slow process and a long backlog.
Should I resubmit the patches based on the updated u-boot git tree.
If it's not too much effort, a resubmit against recent code is indeed appreciated.It would be even better if you could provide access to a git repo from where we could pull from.
Best regards,
Wolfgang Denk
Dear Wolfgang
On Mon, 2006-10-30 at 17:01, Wolfgang Denk wrote:
Dear Roy,
in message 1162192299.15118.3.camel@localhost.localdomain you wrote:
I do not get any feedback about this serial of patches. How about them?They are sitting in my queue, waiting to be processed. We are catching up, but it's a slow process and a long backlog.
It is really a long time. More than two months elapsed after the submitting. Your u-boot git tree has been changed so much.
Should I resubmit the patches based on the updated u-boot gittree.
If it's not too much effort, a resubmit against recent code is indeed appreciated.It would be even better if you could provide access to a git repo from where we could pull from.
I will update my patch based on the recent code and provide my git repo to you, hopefully this week. Thanks a lot. Roy
On Mon, 2006-10-30 at 17:01, Wolfgang Denk wrote:
If it's not too much effort, a resubmit against recent code is indeed appreciated.It would be even better if you could provide access to a git repo from where we could pull from.
Dear, Wolfang
The mpc7448hpc2 board git repo is available. You can browse it at:
http://opensource.freescale.com/git?p=u-boot-7448hpc2.git;a=summary
You can clone it by git clone http://opensource.freescale.com/pub/scm/u-boot-7448hpc2.git Could you find time to have a review and merge it to your tree. Thanks. Roy
Dear Wolfgang On Fri, 2006-11-03 at 12:54, Zang Roy-r61911 wrote:
On Mon, 2006-10-30 at 17:01, Wolfgang Denk wrote:
If it's not too much effort, a resubmit against recent code is
indeed
appreciated.It would be even better if you could provide access to
a
git repo from where we could pull from.
The mpc7448hpc2 board git repo is available. You can browse it at:http://opensource.freescale.com/git?p=u-boot-7448hpc2.git;a=summary
You can clone it bygit clone http://opensource.freescale.com/pub/scm/u-boot-7448hpc2.git
Could you find time to have a review and merge it to yourtree.
I collect the feedback from the u-boot mailing list and update the git repo. Any feedback is welcomed. Roy
On Fri, 2006-11-03 at 12:54, Zang Roy-r61911 wrote:
On Mon, 2006-10-30 at 17:01, Wolfgang Denk wrote:
If it's not too much effort, a resubmit against recent code is
indeed
appreciated.It would be even better if you could provide access to
a
git repo from where we could pull from.
Dear, Wolfang
The mpc7448hpc2 board git repo is available. You can browse it at:http://opensource.freescale.com/git?p=u-boot-7448hpc2.git;a=summary
You can clone it bygit clone http://opensource.freescale.com/pub/scm/u-boot-7448hpc2.git
Could you find time to have a review and merge it to yourtree. Thanks. Roy
Hi, all How about the status of the mpc7448hpc2 u-boot code? Should I wait another three months? Thanks. Roy
Does the mpc7448hpc2 u-boot support the latest kernel? I'd like to try it on my mpc7448+tsi108 board. David
Zang Roy-r61911 tie-fei.zang@freescale.com wrote:
On Fri, 2006-11-03 at 12:54, Zang Roy-r61911 wrote:
On Mon, 2006-10-30 at 17:01, Wolfgang Denk wrote:
If it's not too much effort, a resubmit against recent code is
indeed
appreciated.It would be even better if you could provide access to
a
git repo from where we could pull from.
Dear, Wolfang
The mpc7448hpc2 board git repo is available. You can browse it at:
http://opensource.freescale.com/git?p=u-boot-7448hpc2.git;a=summary
You can clone it by git clone http://opensource.freescale.com/pub/scm/u-boot-7448hpc2.git
Could you find time to have a review and merge it to your tree. Thanks. Roy
Hi, all How about the status of the mpc7448hpc2 u-boot code? Should I wait another three months? Thanks. Roy
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&da... _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
--------------------------------- Sponsored Link
Get a free Motorola Razr! Today Only! Choose Cingular, Sprint, Verizon, Alltel, or T-Mobile.
On Mon, 2006-11-13 at 14:12, Jaksa David wrote:
Does the mpc7448hpc2 u-boot support the latest kernel? I'd like to try it on my mpc7448+tsi108 board. David
Dear David The u-boot supports the latest kernel on mpc7448hpc2 board. it has been tested. The flat device tree can be found at kernel/arch/powerpc/boot/dts directory. You should build the dts file first. Enjoy it. Roy
Dear Wolfgang
How about the progress of mpc7448hpc2 board in u-boot? Thanks a lot!
Roy
On Mon, 2006-11-13 at 14:12, Jaksa David wrote:
Does the mpc7448hpc2 u-boot support the latest kernel? I'd like to try it on my mpc7448+tsi108 board. David
Zang Roy-r61911 tie-fei.zang@freescale.com wrote: On Fri, 2006-11-03 at 12:54, Zang Roy-r61911 wrote: > On Mon, 2006-10-30 at 17:01, Wolfgang Denk wrote: > > > If it's not too much effort, a resubmit against recent code is > indeed > > appreciated.It would be even better if you could provide access to > a > > git repo from where we could pull from. > > > Dear, Wolfang > > The mpc7448hpc2 board git repo is available. > You can browse it at: > > http://opensource.freescale.com/git?p=u-boot-7448hpc2.git;a=summary > > You can clone it by > git clone http://opensource.freescale.com/pub/scm/u-boot-7448hpc2.git > > Could you find time to have a review and merge it to your > tree. > Thanks. > Roy
Hello,
in message 1164593553.28194.2.camel@localhost.localdomain you wrote:
How about the progress of mpc7448hpc2 board in u-boot?
I had a look at your code.
I see a few problems:
1) it does not merge cleanly with the current top of tree in the git repo; there are conflicts with common/cfi_flash.c
2) there are lots of coding style violations: C++ comments in drivers/tsi108_i2c.cand include/configs/mpc7448hpc2.h; trailing white space in board/mpc7448hpc2/asm_init.S, board/mpc7448hpc2/mpc7448hpc2.c, board/mpc7448hpc2/tsi108_init.c, cpu/74xx_7xx/cpu.c, cpu/74xx_7xx/speed.c, doc/README.mpc7448hpc2, drivers/tsi108_i2c.c, include/configs/mpc7448hpc2.h, include/tsi108.h; indentation not by TABs at least in board/mpc7448hpc2/asm_init.S, include/configs/mpc7448hpc2.h; trailing empty lines in doc/README.mpc7448hpc2.
Note that these are just examples; the same problems may be present in other files as well. Please check ALL your code.
Also, you don't place spaces as reqyired by the Coding Style (for example, we normally have spaces before the '(' of a function call).
Also, the Coding Style discourages using '{ ... }' for simple one-line conditionals.
3) Your Makefiles don't support building in a separate directory
4) Indentation looks not nice. For example, in board/mpc7448hpc2/asm_init.S we have:
+ mfspr r3,1014 /* read MSSCR0 */ + rlwinm. r3,r3,27,31,31 /* get processor ID number */ + mtspr SPRN_PIR,r3 /* Save CPU ID */ + sync + bne init_done + b do_tsi108_init
This is not indented by TAB's, and why don;t you align the arguments of the "bne" and "b" instructions like the rest?
Or take this:
+#define READ_SPD(byte_num) \ + addis r3, 0, byte_num@l;\ + or r3, r3, r10;\ + ori r3, r3, 0x0A;\ + stw r3, SD_I2C_CTRL1(r4);\ + li r3, I2C_CNTRL2_START;\ + stw r3, SD_I2C_CTRL2(r4);\ + eieio;\ + sync;\ + li r3, 0x100;\
Or this:
+ READ_SPD(12) /* get Refresh Rate */ + beq check_next_slot + li r5, ERR_RFRSH_RATE + cmpi 0,0,r3,SPD_MIN_RFRSH + ble spd_fail + cmpi 0,0,r3,SPD_MAX_RFRSH + bgt spd_fail + addi r3,r3,-SPD_MIN_RFRSH + rlwinm r3,r3,2,0,31 + lis r5,refresh_rates@h + ori r5,r5,refresh_rates@l + lwzx r5,r5,r3 /* get refresh rate in nSec */ + divwu r5,r5,r9 /* calculate # of SDC clocks */ + stw r5,SD_REFRESH(r4) /* Set refresh rate */
Sorry, but I consider this unreadable.
5) board/mpc7448hpc2/mpc7448hpc2.c contains yet another memory test. Do we really need another copy of this code?
6) Some files - like mpc7448hpc2/tsi108_init.c - contain deep magic with little or no comments (see for example function board_early_init_f()). I guess you want to add some more comments here and there...
7) The output of your code seems to be pretty different from what we have on other boards; see again board_early_init_f():
+ printf("BUS! %d MHz\n", get_board_bus_clk() / 1000000); + printf("MEM! %d MHz\n", gd->mem_clk / 1000000);
Can you please try keeping the look and feel we have on most other boards?
8) Your code adds some data structures globally (like hid1_7447A_multipliers_x_10[] in cpu/74xx_7xx/speed.c) which are probably not needed for all processors. Maybe you can use some #ifdef's here to prevent adding lots of dead code / data to most board configurations?
9) The login here looks weird to me - is this correct? cpu/74xx_7xx/speed.c: ... +#ifdef CFG_CONFIG_BUS_CLK + gd->bus_clk = get_board_bus_clk(); +#else + gd->bus_clk = CFG_BUS_CLK; +#endif
10) Please keep your line length within the allowed limits.
11) Please don't define CONFIG_ETHADDR / CONFIG_ETH1ADDR in your board config file. It is really evil when all boards have the same MAC addresses. Also, are the addresses you used officially assigned ones?
Same is for CONFIG_IPADDR, CONFIG_SERVERIP, CONFIG_NETMASK, CONFIG_GATEWAYIP - it may save some time to have these set during development, but for a public source version I don't ever want to see these.
12) In lib_ppc/extable.c you add code with a "#ifdef CFG_EXCEPTION_AFTER_RELOCATE; there is absolutely no explanation nor comment anywhere why you think this is necessary.
Please clean up and resubmit.
Best regards,
Wolfgang Denk
On Mon, 2006-11-27 at 23:49, Wolfgang Denk wrote:
Please clean up and resubmit.
Best regards,
Wolfgang Denk
Thanks for your detailed comments. I will clean up the code and resubmit.
Roy
Dear Wolfgang
On Mon, 2006-11-27 at 23:49, Wolfgang Denk wrote:
Hello,
in message 1164593553.28194.2.camel@localhost.localdomain you wrote:
How about the progress of mpc7448hpc2 board in u-boot?I had a look at your code.
I see a few problems:
- it does not merge cleanly with the current top of tree in the git repo; there are conflicts with common/cfi_flash.c
Fixed.
- there are lots of coding style violations:
I checked all my commit files and fixed all the coding style violations as far as my understand :-). Sorry for some garbage codes :-).
- board/mpc7448hpc2/mpc7448hpc2.c contains yet another memory test. Do we really need another copy of this code?
Do you mean testdram () function? I can see this function in many other boards. memtest command can do dram test. While I still think ,this function can benefit end users when testing or debugging.
- Some files - like mpc7448hpc2/tsi108_init.c - contain deep magic with little or no comments (see for example function board_early_init_f()). I guess you want to add some more comments here and there...
I will add necessary comments.
- Can you please try keeping the look and feel we have on most other boards?
Fixed.
- Your code adds some data structures globally (like hid1_7447A_multipliers_x_10[] in cpu/74xx_7xx/speed.c) which are probably not needed for all processors. Maybe you can use some #ifdef's here to prevent adding lots of dead code / data to most board configurations?
I will consider to add a ifdef here.
- The login here looks weird to me - is this correct? cpu/74xx_7xx/speed.c: ... +#ifdef CFG_CONFIG_BUS_CLK + gd->bus_clk = get_board_bus_clk(); +#else + gd->bus_clk = CFG_BUS_CLK; +#endif
#ifdef CFG_CONFIG_BUS_CLK
the bus clock can be configured by external switch, just as the mpc7448hpc2 board
#else the bus clock is a fixed one.
I will add comments here.
- Please keep your line length within the allowed limits.
Fixed as far as I can see :-).
- Please don't define CONFIG_ETHADDR / CONFIG_ETH1ADDR in your board config file. It is really evil when all boards have the same MAC addresses. Also, are the addresses you used officially assigned ones?
00:06:D2 is officially assigned to Tundra :-).
Same is for CONFIG_IPADDR, CONFIG_SERVERIP, CONFIG_NETMASK, CONFIG_GATEWAYIP - it may save some time to have these set during development, but for a public source version I don't ever want to see these.
Can you make sure all of these define are not necessary? I can see them in many other board.
- In lib_ppc/extable.c you add code with a "#ifdef CFG_EXCEPTION_AFTER_RELOCATE; there is absolutely no explanation nor comment anywhere why you think this is necessary.
I need to deal with exception after the code relocation. I need add the gd->reloc_off to search the exception table. If I do not find better method for this, I will add a detailed comment here.
Please clean up and resubmit.
I have cleaned most of the code, after a testing. I will resubmit them hopefully the early next week. Thanks for your effort to review my code :-).
Roy
In message 1164940274.5921.26.camel@localhost.localdomain you wrote:
- it does not merge cleanly with the current top of tree in the git repo; there are conflicts with common/cfi_flash.c
Fixed.
Thanks.
- there are lots of coding style violations:
I checked all my commit files and fixed all the coding style violations as far as my understand :-). Sorry for some garbage codes :-).
Thanks.
- board/mpc7448hpc2/mpc7448hpc2.c contains yet another memory test. Do we really need another copy of this code?
Do you mean testdram () function? I can see this function in many other boards. memtest command can do dram test. While I still think ,this function can benefit end users when testing or debugging.
As far as I can tell your code is mostly a verbatim copy of post/memory.c - if you need a good memory test then please configure POST on your system and use the POST code instead of copying it.
- The login here looks weird to me - is this correct? cpu/74xx_7xx/speed.c: ... +#ifdef CFG_CONFIG_BUS_CLK + gd->bus_clk = get_board_bus_clk(); +#else + gd->bus_clk = CFG_BUS_CLK; +#endif
#ifdef CFG_CONFIG_BUS_CLK
the bus clock can be configured by external switch, just as the mpc7448hpc2 board
#else the bus clock is a fixed one.
But why do we need both CFG_CONFIG_BUS_CLK and CFG_BUS_CLK ?
- Please don't define CONFIG_ETHADDR / CONFIG_ETH1ADDR in your board config file. It is really evil when all boards have the same MAC addresses. Also, are the addresses you used officially assigned ones?
00:06:D2 is officially assigned to Tundra :-).
Anyway: please don;t define MAC addresses in the board config file. It will only cause harm.
Same is for CONFIG_IPADDR, CONFIG_SERVERIP, CONFIG_NETMASK, CONFIG_GATEWAYIP - it may save some time to have these set during development, but for a public source version I don't ever want to see these.Can you make sure all of these define are not necessary? I can see them in many other board.
There may be a *few* boards that do this, but in general it's a very bad idea: it works fine for the guy who is eorking on the U-Boot port, because he usually uses just a single board. But as soon as you have a second board in the net it becomes a major PITA. Please don't do it.
If needed, you can set up a valid per-board network setup as part of the software initialization - a simple expect script can do magic.
- In lib_ppc/extable.c you add code with a "#ifdef CFG_EXCEPTION_AFTER_RELOCATE; there is absolutely no explanation nor comment anywhere why you think this is necessary.
I need to deal with exception after the code relocation. I need add the
Why do you need to do this?
gd->reloc_off to search the exception table. If I do not find better method for this, I will add a detailed comment here.
I think this part of the code is pretty generic. I would like to understand why on your board such a change is necessary which is not needed on any other system.
Thanks for your effort to review my code :-).
You are welcome.
Best regards,
Wolfgang Denk
Dear Wolfgang
On Fri, 2006-12-01 at 16:59, Wolfgang Denk wrote:
In message 1164940274.5921.26.camel@localhost.localdomain you wrote:
- board/mpc7448hpc2/mpc7448hpc2.c contains yet another memory
test.
As far as I can tell your code is mostly a verbatim copy of post/memory.c - if you need a good memory test then please configure POST on your system and use the POST code instead of copying it.
The copy is not necessary. I will remove them. Thanks.
- The login here looks weird to me - is this correct? cpu/74xx_7xx/speed.c: ...
But why do we need both CFG_CONFIG_BUS_CLK and CFG_BUS_CLK ?
No! I will remove one!
- Please don't define CONFIG_ETHADDR / CONFIG_ETH1ADDR in your
board
config file. It is really evil when all boards have the sameMAC
addresses. Also, are the addresses you used officiallyassigned
ones?00:06:D2 is officially assigned to Tundra :-).
Anyway: please don;t define MAC addresses in the board config file. It will only cause harm.
Same is for CONFIG_IPADDR, CONFIG_SERVERIP, CONFIG_NETMASK, CONFIG_GATEWAYIP - it may save some time to have these setduring
development, but for a public source version I don't ever wantto
see these.Can you make sure all of these define are not necessary? I can see
them
in many other board.
There may be a *few* boards that do this, but in general it's a very bad idea: it works fine for the guy who is eorking on the U-Boot port, because he usually uses just a single board. But as soon as you have a second board in the net it becomes a major PITA. Please don't do it.
If needed, you can set up a valid per-board network setup as part of the software initialization - a simple expect script can do magic.
I will remove them.
- In lib_ppc/extable.c you add code with a "#ifdef CFG_EXCEPTION_AFTER_RELOCATE; there is absolutely no
explanation
nor comment anywhere why you think this is necessary.I need to deal with exception after the code relocation. I need add
the
Why do you need to do this?
Because my exception occurs in RAM, after the u-boot relocation.
gd->reloc_off to search the exception table. If I do not find better method for this, I will add a detailed
comment
here.
I think this part of the code is pretty generic. I would like to understand why on your board such a change is necessary which is not needed on any other system.
I have explain the detail reason in my previous mail and provide a draft patch for list review. I hope I can present the issue here and have a discussion. Thanks. Roy
Dear Wolfgang
On Mon, 2006-11-27 at 23:49, Wolfgang Denk wrote:
- In lib_ppc/extable.c you add code with a "#ifdef CFG_EXCEPTION_AFTER_RELOCATE; there is absolutely no explanation nor comment anywhere why you think this is necessary.
I do not think the search_one_table()function can deal with all the exception conditions.The original code can only processes the search for the exception occurring in FLASH/ROM, because the exception and fixup table usually locate in FLASH. If the exception address is also in FLASH, it will be OK.
If the exception occurs in RAM, after the u-boot relocation, a relocation offset should be added.
I am sadly to see that there is no other ppc board encountering the exception in RAM phase. While for mpc7448hpc2 board, tsi108 pci config read will generate such kind of exception.
After consideration , I do not think provide CFG_EXCEPTION_AFTER_RELOCATE is a good option :-). I change it to the following code. How do you think? If it is OK, I will provide it with all the mpc7448hpc2 board support code. Thanks. Roy
diff --git a/lib_ppc/extable.c b/lib_ppc/extable.c index d92f142..8a4d141 100644 --- a/lib_ppc/extable.c +++ b/lib_ppc/extable.c @@ -50,15 +50,29 @@ search_one_table(const struct exception_ const struct exception_table_entry *last, unsigned long value) { + DECLARE_GLOBAL_DATA_PTR; + while (first <= last) { const struct exception_table_entry *mid; long diff;
mid = (last - first) / 2 + first; - diff = mid->insn - value; - if (diff == 0) - return mid->fixup; - else if (diff < 0) + if (mid > CFG_MONITOR_BASE) { + /* exception occurs in FLASH, before u-boot relocation. + * No relocation offset is needed. + */ + diff = mid->insn - value; + if (diff == 0) + return mid->fixup; + } else { + /* exception occurs in RAM, after u-boot relocation. + * A relocation offset should be added. + */ + diff = (mid->insn + gd->reloc_off) - value; + if (diff == 0) + return (mid->fixup + gd->reloc_off); + } + if (diff < 0) first = mid+1; else last = mid-1;
In message 1164960567.6742.25.camel@localhost.localdomain you wrote:
index d92f142..8a4d141 100644 --- a/lib_ppc/extable.c +++ b/lib_ppc/extable.c @@ -50,15 +50,29 @@ search_one_table(const struct exception_ const struct exception_table_entry *last, unsigned long value) {
DECLARE_GLOBAL_DATA_PTR;
while (first <= last) { const struct exception_table_entry *mid; long diff;
mid = (last - first) / 2 + first;
diff = mid->insn - value;if (diff == 0)return mid->fixup;else if (diff < 0)
if (mid > CFG_MONITOR_BASE) {/* exception occurs in FLASH, before u-boot relocation.* No relocation offset is needed.*/diff = mid->insn - value;if (diff == 0)return mid->fixup;} else {/* exception occurs in RAM, after u-boot relocation.* A relocation offset should be added.*/diff = (mid->insn + gd->reloc_off) - value;if (diff == 0)return (mid->fixup + gd->reloc_off);}if (diff < 0) first = mid+1;
The problem I see with this code is that it is based on the assumption that CFG_MONITOR_BASE is greater than any RAM address. While this is always true so far, I would rather not rely on this.
And I still don't understand why this change is necessary, and/or if this is the right fix. If a fix is needed, then probably the values of "value" is wrong in the first place, so the fix should be in the calling routine.
Also please note that the DECLARE_GLOBAL_DATA_PTR declaration must be placed outside the function, i. e. on file scope.
Best regards,
Wolfgang Denk
Dear Wolfgang
On Fri, 2006-12-01 at 22:31, Wolfgang Denk wrote:
In message 1164960567.6742.25.camel@localhost.localdomain you wrote:
index d92f142..8a4d141 100644 --- a/lib_ppc/extable.c +++ b/lib_ppc/extable.c @@ -50,15 +50,29 @@ search_one_table(const struct exception_ const struct exception_table_entry *last, unsigned long value) {
DECLARE_GLOBAL_DATA_PTR;while (first <= last) { const struct exception_table_entry *mid; long diff; mid = (last - first) / 2 + first;
diff = mid->insn - value;if (diff == 0)return mid->fixup;else if (diff < 0)
if (mid > CFG_MONITOR_BASE) {/* exception occurs in FLASH, before u-bootrelocation.
* No relocation offset is needed.*/diff = mid->insn - value;if (diff == 0)return mid->fixup;} else {/* exception occurs in RAM, after u-boot relocation.* A relocation offset should be added.*/diff = (mid->insn + gd->reloc_off) - value;if (diff == 0)return (mid->fixup + gd->reloc_off);}if (diff < 0) first = mid+1; else last = mid-1;The problem I see with this code is that it is based on the assumption that CFG_MONITOR_BASE is greater than any RAM address. While this is always true so far, I would rather not rely on this.
I would not rely on this either, if there is a better way :-). Anyway, it's better than a define. In future, there might be a board whose exception code will occur in both RAM and Flash. A fixed macro define can not deal with this condition, although, I do not see this kind of ppc board in u-boot tree until now.
And I still don't understand why this change is necessary, and/or if this is the right fix. If a fix is needed, then probably the values of "value" is wrong in the first place, so the fix should be in the calling routine.
"The "value" is the address of exception occurring. For mpc7448hpc2 board, a tsi108/9 bridge is used. There is a hardware chip errata, when the tsi108 pci controller has a config read operation. This operation will induce a processor exception. The following code does a pci config dword read.
+unsigned int __get_pci_config_dword (u32 addr) +{ + unsigned int retval; + + __asm__ __volatile__ (" lwbrx %0,0,%1\n" + "1: eieio\n" + "2:\n" + ".section .fixup,"ax"\n" + "3: li %0,-1\n" + " b 2b\n" + ".section __ex_table,"a"\n" + " .align 2\n" + " .long 1b,3b\n" + ".text":"=r"(retval):"r"(addr)); + + return (retval); +}
A exception will occur at address "1" ("value"), when the code executes in RAM (after relocation). While the address 1b and 3b are assigned when u-boot compiling. 1b and 3b are located in Flash. If the exception occurs in Flash, everything will be OK. While, for pci config read occurs in RAM, if I do not consider the reloc_off, I can not find the __ex_table.
Do you think it is reasonable for the code to jump back to flash to execute? This might ensure the exception occurring address locates in FlASH.
I can see the mechanism to deal with exception in u-boot is just similar to kernel, while kernel does not has such relocation. The same code is OK in kernel. For u-boot, we should consider this issue, although there is no other ppc board encounter this.
thanks! Roy
Dear Wolfgang
On Mon, 2006-11-27 at 23:49, Wolfgang Denk wrote:
Hello,
in message 1164593553.28194.2.camel@localhost.localdomain you wrote:
How about the progress of mpc7448hpc2 board in u-boot?I had a look at your code.
I see a few problems:
I fixed the problems you point out and update my 7448hpc2 git tree at
http://opensource.freescale.com/git?p=u-boot-7448hpc2.git;a=summary
Please clean up and resubmit.
Could you find time to have a look and give you valuable feedback. Thanks. Roy
Zang Roy-r61911 tie-fei.zang@freescale.com wrote: Dear Wolfgang
On Mon, 2006-11-27 at 23:49, Wolfgang Denk wrote:
Hello,
in message 1164593553.28194.2.camel@localhost.localdomain you wrote:
How about the progress of mpc7448hpc2 board in u-boot?
I had a look at your code.
I see a few problems:
I fixed the problems you point out and update my 7448hpc2 git tree at
http://opensource.freescale.com/git?p=u-boot-7448hpc2.git;a=summary
I merge it into my tree and test it on my board. It works OK! Jaksa
--------------------------------- Any questions? Get answers on any topic at Yahoo! Answers. Try it now.
Dear Wolfgang On Tue, 2006-12-05 at 10:31, Zang Roy-r61911 wrote:
Dear Wolfgang
Please clean up and resubmit.
Could you find time to have a look and give you valuable feedback.
How about it? Thanks. Roy
Dear Wolfgang
On Fri, 2006-12-08 at 23:51, Zang Roy-r61911 wrote:
Dear Wolfgang On Tue, 2006-12-05 at 10:31, Zang Roy-r61911 wrote:
Dear Wolfgang
Please clean up and resubmit.
Could you find time to have a look and give you valuable feedback.
How about it? Thanks. Roy
How about the progress of the mpc7448hpc2 board? Thanks. Roy
--- Zang Roy-r61911 tie-fei.zang@freescale.com wrote:
Dear Wolfgang
On Fri, 2006-12-08 at 23:51, Zang Roy-r61911 wrote:
Dear Wolfgang On Tue, 2006-12-05 at 10:31, Zang Roy-r61911
wrote:
Dear Wolfgang
Please clean up and resubmit.
Could you find time to have a look and give you
valuable feedback.
How about it? Thanks. Roy
How about the progress of the mpc7448hpc2 board? Thanks. Roy
I am also curious about this. The code works OK on my 7448 board.
Jaksa
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
In message 1166776563.21334.1.camel@localhost.localdomain you wrote:
How about it?
We are buried under work. Let's see if there are some long nights over Xmas, but I cannot make any promises yet. Believe me,. I'm suffering from this as well :-(
Best regards,
Wolfgang Denk
On Fri, 2006-12-22 at 18:02, Wolfgang Denk wrote:
In message 1166776563.21334.1.camel@localhost.localdomain you wrote:
How about it?We are buried under work. Let's see if there are some long nights over Xmas, but I cannot make any promises yet. Believe me,. I'm suffering from this as well :-(
Dear Wolfgang, I know you are very busy. I can wait, while I will reminder you :-). I believe the code will benefit the board user. Hope you can find such long nights during Xmas. Happy Christmas! Roy
On Fri, 2006-12-22 at 18:02, Wolfgang Denk wrote:
In message 1166776563.21334.1.camel@localhost.localdomain you wrote:
How about it?We are buried under work. Let's see if there are some long nights over Xmas, but I cannot make any promises yet. Believe me,. I'm suffering from this as well :-(
Dear Wolfgang How about the status of the mpc7448hpc2 board support code? It is stay so long a time in your queue. Could you find time to pull it to your git tree? Thanks a lot! Roy
On Fri, 2006-12-22 at 18:02, Wolfgang Denk wrote:
In message 1166776563.21334.1.camel@localhost.localdomain you wrote:
How about it?We are buried under work. Let's see if there are some long nights over Xmas, but I cannot make any promises yet. Believe me,. I'm suffering from this as well :-(
Dear Wolfgang Is there any progress about the code? Do you have any future comment? Thanks. Roy
In message 1168829037.1678.1.camel@localhost.localdomain you wrote:
Is there any progress about the code? Do you have any future comment? Thanks.
Sorry, there hasn't been any progress on my side for the last two weeks. But some changes to the development process are on the verge. I hope we will find a way to significantly improve this soon. Very soon. Stay tuned.
For now, I can just apologize.
Best regards,
Wolfgang Denk
On Tue, 2007-01-16 at 05:21, Wolfgang Denk wrote:
In message 1168829037.1678.1.camel@localhost.localdomain you wrote:
Is there any progress about the code? Do you have any futurecomment?
Thanks.Sorry, there hasn't been any progress on my side for the last two weeks. But some changes to the development process are on the verge. I hope we will find a way to significantly improve this soon. Very soon. Stay tuned.
Dear Wolfgang Hope it soon. I merge your git tree to mine and find that my changes to cfi_flash.c have been merged by SC3 to your tree. I believe some day all my changes will be in your tree by my tree or others :-). Roy
On Tue, 2007-01-16 at 05:21, Wolfgang Denk wrote:
In message 1168829037.1678.1.camel@localhost.localdomain you wrote:
Is there any progress about the code? Do you have any futurecomment?
Thanks.Sorry, there hasn't been any progress on my side for the last two weeks. But some changes to the development process are on the verge. I hope we will find a way to significantly improve this soon. Very soon. Stay tuned.
For now, I can just apologize.
Dear Wolfgang How about it ? Thanks! Roy
On Tue, 2007-01-16 at 05:21, Wolfgang Denk wrote:
In message 1168829037.1678.1.camel@localhost.localdomain you wrote:
Is there any progress about the code? Do you have any futurecomment?
Thanks.Sorry, there hasn't been any progress on my side for the last two weeks. But some changes to the development process are on the verge. I hope we will find a way to significantly improve this soon. Very soon. Stay tuned.
For now, I can just apologize.
Dear Wolfgang How about the progress? Thanks a lot! Roy
Hi,
the patch series "Add mpc7448hpc2 (Taiga) board support" has been merged into the u-boot-74xx-7xx custodian tree. Please see http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot-74xx-7xx.git;a=summary
Maintainers of 7xx and 74xx boards, please help testing the changes.
If no negative feedback is received within the next 3 weeks, I will merge this code into the public repo.
Best regards,
Wolfgang Denk
Hi,
the patch series "Add mpc7448hpc2 (Taiga) board support" has been merged into the u-boot-74xx-7xx custodian tree. Please see http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot-74xx-7xx.git;a=summary
Maintainers of 7xx and 74xx boards, please help testing the changes.
Thanks a lot. It seems that the correct link is http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-74xx-7xx.git;a=sum mary You missed a u-boot :-). Roy
In message 7EA18FDD2DC2154AA3BD6D2F22A62A0E5F69B2@zch01exm23.fsl.freescale.net you wrote:
http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot-74xx-7xx.git;a=summary
Maintainers of 7xx and 74xx boards, please help testing the changes.
Thanks a lot. It seems that the correct link is http://www.denx.de/cgi-bin/gitweb.cgi?p%C3%BFboot/u-boot-74xx-7xx.git;a=summ... You missed a u-boot :-).
The link was correct when I posted it; in the mean time we decided to use a different representation in the gitweb interface, as the long list of custodian trees made it difficult to find the master tree.
I hope the current setup is acceptable to everybody.
Best regards,
Wolfgang Denk
On Thu, 2007-03-08 at 18:45, Wolfgang Denk wrote:
Hi,
the patch series "Add mpc7448hpc2 (Taiga) board support" has been merged into the u-boot-74xx-7xx custodian tree. Please see http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot-74xx-7xx.git;a=summary
Maintainers of 7xx and 74xx boards, please help testing the changes.
If no negative feedback is received within the next 3 weeks, I will merge this code into the public repo.
Dear Wolfgang Is there any negative feedback? Could you help to merge this code into the public repo.? Thanks a lot! Roy
On Thu, 2007-03-08 at 18:45, Wolfgang Denk wrote:
Hi,
the patch series "Add mpc7448hpc2 (Taiga) board support" has been merged into the u-boot-74xx-7xx custodian tree. Please see http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot-74xx-7xx.git;a=summary
Maintainers of 7xx and 74xx boards, please help testing the changes.
If no negative feedback is received within the next 3 weeks, I will merge this code into the public repo.
Best regards,
Wolfgang Denk
Dear Wolfgang How about it? Thanks a lot! Roy
In message 1176333950.30414.0.camel@localhost.localdomain you wrote:
the patch series "Add mpc7448hpc2 (Taiga) board support" has been merged into the u-boot-74xx-7xx custodian tree. Please see http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot-74xx-7xx.git;a=summary
Maintainers of 7xx and 74xx boards, please help testing the changes.
If no negative feedback is received within the next 3 weeks, I will merge this code into the public repo.
The good news is: there was no negative feedback.
The bad news is: there was zero feedback. Probably nobody even bothered to check.
How about it?
Merged. Thanks for your patience.
Best regards,
Wolfgang Denk
On Wed, 2007-04-18 at 23:33, Wolfgang Denk wrote:
In message 1176333950.30414.0.camel@localhost.localdomain you wrote:
the patch series "Add mpc7448hpc2 (Taiga) board support" has
been
merged into the u-boot-74xx-7xx custodian tree. Please
see
http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot-74xx-7xx.git;a=summary
Maintainers of 7xx and 74xx boards, please help testing the
changes.
If no negative feedback is received within the next 3 weeks, I
will
merge this code into the public repo.
The good news is: there was no negative feedback.
The bad news is: there was zero feedback. Probably nobody even bothered to check.
I checked it :-). Anyway, it is a good news. I will keep working on the 74xx processor family.
How about it?Merged. Thanks for your patience.
Thanks for your effort to review the code.
Best Regards Roy
This serial of patches have been submitted on 11, Aug., 2006. I wait for more than two months. there is no feedback, positive or negative.
I updated the patches based on the current u-boot git tree. I hope I will not wait for so long time again. Any feedback is welcomed. I'd like to refine the code according to your warm comments.
This series of patches add mpc7448hpc2 board support. Mpc7448hpc2 (taiga) board is a high-performance PowerPC server reference design,which is optimized for high speed throughput between the processor and the memory, disk drive and Ethernet port subsystems.
The board is designed to the micro-ATX chassis, allowing it to be used in 1U or 2U rack-mount chassis
----------------------------------------------------------------------
Add README file for mpc7448hpc2 board.
Signed-off-by: Roy Zang tie-fei.zang@freescale.com --- doc/README.mpc7448hpc2 | 193 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 193 insertions(+), 0 deletions(-)
diff --git a/doc/README.mpc7448hpc2 b/doc/README.mpc7448hpc2 new file mode 100644 index 0000000..5142a0f --- /dev/null +++ b/doc/README.mpc7448hpc2 @@ -0,0 +1,193 @@ +Freescale MPC7448hpc2 (Taiga) board +=================================== + +Created 08/11/2006 Roy Zang +-------------------------- +MPC7448hpc2 (Taiga) board is a high-performance PowerPC server reference +design, which is optimized for high speed throughput between the processor and +the memory, disk drive and Ethernet port subsystems. + +MPC7448hpc2(Taiga) is designed to the micro-ATX chassis, allowing it to be +used in 1U or 2U rack-mount chassisol and CPU Reset Option + + 7 + - + SW2=0 System bus uses MPX bus protocol + SW2=1 System bus uses 60x bus protocol + + 8 + - + SW2=0 TSI108 can cause CPU reset + SW2=1 TSI108 can not cause CPU reset + + +SW3[1-8] system options + + 123 + --- + SW3=xxx Connected to GPIO[0:2] on TSI108 + + 4 + - + SW3=0 CPU boots from low half of flash + SW3=1 CPU boots from high half of flash + + 5 + - + SW3=0 SATA and slot2 connected to PCI bus + SW3=1 Only slot1 connected to PCI bus + + 6 + - + SW3=0 USB connected to PCI bus + SW3=1 USB disconnected from PCI bus + + 7 + - + SW3=0 Flash is write protected + SW3=1 Flash is NOT write protected + + 8 + - + SW3=0 CPU will boot from flash + SW3=1 CPU will boot from PromJet + +SW4[1-3]: System bus frequency + + Bus Frequency (MHz) + --- + SW4=010 183 + SW4=011 100 + SW4=100 133 + SW4=101 166 only for MPC7447A + SW4=110 200 only for MPC7448 + others reserved + + +SW4[4-6]: DDR2 SDRAM frequency + + Bus Frequency (MHz) + --- + SW4=000 external clock + SW4=011 system clock + SW4=100 133 + SW4=101 166 + SW4=110 200 + others reserved + + +SW4[7-8]: PCI/PCI-X frequency control + 7 + - + SW4=0 PCI/PCI-X bus operates normally + SW4=1 PCI bus forced to PCI-33 mode + + 8 + - + SW4=0 PCI-X mode at 133 MHz allowed + SW4=1 PCI-X mode limited to 100 MHz +
participants (3)
-
Jaksa David -
Wolfgang Denk -
Zang Roy-r61911