[U-Boot-Users] Value of CFG_PCI_MEMBASE

Hi,
In the 'include/configs/ocotea.h" file: 8<-----------------------------------------------------------------------------------------------------
#define CFG_PCI_MEMBASE 0x80000000 /* mapped pci memory */
8<-----------------------------------------------------------------------------------------------------
But the Memory map of the Ocotea board (PPC440GX® Evaluation Board User's Manual) has mentioned about the PCI memory as: Start Address (32 Bit) - 9000 0000 End Address (32 Bit) - 9FFF FFFF Start Address (36 Bit) - 3 0000 0000 End Address (36 Bit) - 3 0FFF FFFF Size - 256MB 256 MB
I am not clear about the logic behind the value assigned to CFG_PCI_MEMBASE i.e. 0x80000000
Can you help me to figure it out?
Regards, Sachin Rane

On Wednesday 11 June 2008, Sachin Rane wrote:
In the 'include/configs/ocotea.h" file: 8<-------------------------------------------------------------------------
#define CFG_PCI_MEMBASE 0x80000000 /* mapped pci memory */
This is the virtual address.
8<-------------------------------------------------------------------------
But the Memory map of the Ocotea board (PPC440GX® Evaluation Board User's Manual) has mentioned about the PCI memory as: Start Address (32 Bit) - 9000 0000 End Address (32 Bit) - 9FFF FFFF Start Address (36 Bit) - 3 0000 0000 End Address (36 Bit) - 3 0FFF FFFF Size - 256MB 256 MB
The users manual referrs to the physical (36bit) address.
I am not clear about the logic behind the value assigned to CFG_PCI_MEMBASE i.e. 0x80000000
The mapping between virtual and physical address is done via the MMU. I suggest you take a look at the init.S file in the board directory. This should make it clear.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================

Hi Stefen,
Thanks for the reply.
Infact I was looking for the info to create a proper 'tlbentry' in 'init.S' As per my understanding the 'tlbentry' is to map 32-bit address to 36-bit address.
The 'tlbenry' for the PCI Memory in 'init.S' is : tlbentry( CFG_PCI_MEMBASE, SZ_256M, 0x00000000, 3, AC_R|AC_W|SA_G|SA_I )
The 'CFG_PCI_MEMBASE' is set to 0x80000000 in 'ocotea.h'.
My question is how to select the value for 'CFG_PCI_MEMBASE'. Can I use any value (say 0x50000000 ) provided it is not overlapping with other devices?
If we are using Board Memory Map as a reference then the 32-bit address 'CFG_PCI_MEMBASE' used in 'telbentry' should have set to: 0x90000000
I am trying to find out the logic behind the selection of value for the variabale 'CFG_PCI_MEMBASE' in: tlbentry( CFG_PCI_MEMBASE, SZ_256M, 0x00000000, 3, AC_R|AC_W|SA_G|SA_I )
Waiting for your reply.
Regards, Sachin Rane
________________________________
From: u-boot-users-bounces@lists.sourceforge.net on behalf of Stefan Roese Sent: Thu 6/12/2008 5:51 AM To: u-boot-users@lists.sourceforge.net Cc: Sachin Rane Subject: Re: [U-Boot-Users] Value of CFG_PCI_MEMBASE
On Wednesday 11 June 2008, Sachin Rane wrote:
In the 'include/configs/ocotea.h" file: 8<-------------------------------------------------------------------------
#define CFG_PCI_MEMBASE 0x80000000 /* mapped pci memory */
This is the virtual address.
8<-------------------------------------------------------------------------
But the Memory map of the Ocotea board (PPC440GX® Evaluation Board User's Manual) has mentioned about the PCI memory as: Start Address (32 Bit) - 9000 0000 End Address (32 Bit) - 9FFF FFFF Start Address (36 Bit) - 3 0000 0000 End Address (36 Bit) - 3 0FFF FFFF Size - 256MB 256 MB
The users manual referrs to the physical (36bit) address.
I am not clear about the logic behind the value assigned to CFG_PCI_MEMBASE i.e. 0x80000000
The mapping between virtual and physical address is done via the MMU. I suggest you take a look at the init.S file in the board directory. This should make it clear.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

On Monday 16 June 2008, Sachin Rane wrote:
Infact I was looking for the info to create a proper 'tlbentry' in 'init.S' As per my understanding the 'tlbentry' is to map 32-bit address to 36-bit address.
The 'tlbenry' for the PCI Memory in 'init.S' is : tlbentry( CFG_PCI_MEMBASE, SZ_256M, 0x00000000, 3, AC_R|AC_W|SA_G|SA_I )
The 'CFG_PCI_MEMBASE' is set to 0x80000000 in 'ocotea.h'.
My question is how to select the value for 'CFG_PCI_MEMBASE'. Can I use any value (say 0x50000000 ) provided it is not overlapping with other devices?
Yes. I suggest to start with 0x80000000 since this leaves the first 2 GB for SDRAM.
If we are using Board Memory Map as a reference then the 32-bit address 'CFG_PCI_MEMBASE' used in 'telbentry' should have set to: 0x90000000
Why is this? Which "Board Memory Map" are you referring to?
I am trying to find out the logic behind the selection of value for the variabale 'CFG_PCI_MEMBASE' in: tlbentry( CFG_PCI_MEMBASE, SZ_256M, 0x00000000, 3, AC_R|AC_W|SA_G|SA_I )
Whats the problems with using 0x80000000 here?
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================

Hi Stefan,
I don't have much knowledge about how u-boot being implemented.
Why is this? Which "Board Memory Map" are you referring to?
I am referring to 'Peripheral Registers' table given in 'PPC440GX® Evaluation Board User’s Manual'. I found the 32 bit value passed to the 'telbentry' macro is matching with the values given in the '32 Bit Address' column of the table except for 'PCI Memory - cached'. And this mismatch confused me.
From your last reply I understood that it is the developer who got the freedom to decide the 32-bit value. Is that correct?
Regards, Sachin
Stefan Roese wrote:
On Monday 16 June 2008, Sachin Rane wrote:
Infact I was looking for the info to create a proper 'tlbentry' in 'init.S' As per my understanding the 'tlbentry' is to map 32-bit address to 36-bit address.
The 'tlbenry' for the PCI Memory in 'init.S' is : tlbentry( CFG_PCI_MEMBASE, SZ_256M, 0x00000000, 3, AC_R|AC_W|SA_G|SA_I )
The 'CFG_PCI_MEMBASE' is set to 0x80000000 in 'ocotea.h'.
My question is how to select the value for 'CFG_PCI_MEMBASE'. Can I use any value (say 0x50000000 ) provided it is not overlapping with other devices?
Yes. I suggest to start with 0x80000000 since this leaves the first 2 GB for SDRAM.
If we are using Board Memory Map as a reference then the 32-bit address 'CFG_PCI_MEMBASE' used in 'telbentry' should have set to: 0x90000000
Why is this? Which "Board Memory Map" are you referring to?
I am trying to find out the logic behind the selection of value for the variabale 'CFG_PCI_MEMBASE' in: tlbentry( CFG_PCI_MEMBASE, SZ_256M, 0x00000000, 3, AC_R|AC_W|SA_G|SA_I )
Whats the problems with using 0x80000000 here?
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================

Hi Sachin,
On Monday 16 June 2008, Sachin Rane, Alphion Communications wrote:
I don't have much knowledge about how u-boot being implemented.
Why is this? Which "Board Memory Map" are you referring to?
I am referring to 'Peripheral Registers' table given in 'PPC440GX® Evaluation Board User’s Manual'. I found the 32 bit value passed to the 'telbentry' macro is matching with the values given in the '32 Bit Address' column of the table except for 'PCI Memory - cached'. And this mismatch confused me.
From your last reply I understood that it is the developer who got the freedom to decide the 32-bit value. Is that correct?
Yes. You have some freedom in this assignment of the 32-bit virtual addresses. Overlapping is not allowed of course.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================

Hi, In the 'include/configs/ocotea.h" file: 8<----------------------------------------------------------------------------------------------------- #define CFG_PCI_MEMBASE 0x80000000 /* mapped pci memory */ 8<----------------------------------------------------------------------------------------------------- But the Memory map of the Ocotea board (PPC440GX® Evaluation Board User’s Manual) has mentioned about the PCI memory as: Start Address (32 Bit) - 9000 0000 End Address (32 Bit) - 9FFF FFFF Start Address (36 Bit) - 3 0000 0000 End Address (36 Bit) - 3 0FFF FFFF Size - 256MB 256 MB I am not clear about the logic behind the value assigned to CFG_PCI_MEMBASE i.e. 0x80000000 Can you help me to figure it out? Regards, Sachin Rane
participants (3)
-
Sachin Rane
-
Sachin Rane, Alphion Communications
-
Stefan Roese