Re: [U-Boot] [PATCH 1/4] doc: Add documentation for mpc85xx debugger support
Dear Kushwaha Prabhakar-B32579,
In message 071A08F2C6A57E4E94D980ECA553F874575244@039-SN1MPN1-005.039d.mgd.msft.net you wrote:
Regarding CONFIG_E500_V1_V2, Its description is also part of this patch or is it not cleared ?
First, documentation of CONFIG_ options belongs into the central README, so we have it all in a single place.
Second, "Enables code taking care of above mentioned rule" is not really helpful to understand what it's actually doing.
The name of the cvariable suggests that this defiens a E500 core based system, but it does not even contain a slight hint that it has something to do with debugging.
Also, what's the "V1_V2" ? Are there also other systems (say, e500 v3 cores), and are this not affected? We already have CONFIG_E500 and CONFIG_E500MC so CONFIG_E500_V1_V2 appears to belong to this group, but if I understand your intentions it does something completely unrelated.
All this is highly confusing.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Wednesday 07 March 2012 11:54 AM, Wolfgang Denk wrote:
In message071A08F2C6A57E4E94D980ECA553F874575244@039-SN1MPN1-005.039d.mgd.msft.net you wrote:
Regarding CONFIG_E500_V1_V2, Its description is also part of this patch or is it not cleared ?
First, documentation of CONFIG_ options belongs into the central README, so we have it all in a single place.
I will take care in next version.
Second, "Enables code taking care of above mentioned rule" is not really helpful to understand what it's actually doing.
I will add more description
The name of the cvariable suggests that this defiens a E500 core based system, but it does not even contain a slight hint that it has something to do with debugging.
Yes i agree. From #define no one can get hint of debugging. It was intended.
This #define is created to overcome restriction of e500 v1 and v2 family processor. We can have this #define permanently enabled. That's why i did not create any CONFIG_ having DBG name.
Unfortunately this is a restriction for debugging.
Also, what's the "V1_V2" ? Are there also other systems (say, e500 v3 cores), and are this not affected? We already have CONFIG_E500 and CONFIG_E500MC so CONFIG_E500_V1_V2 appears to belong to this group, but if I understand your intentions it does something completely unrelated.
V1_V2 is used because it applied to e500v1 and e500v2 not e500mc processor. So CONFIG_E500MC cant be used. Also I cant use CONFIG_E500 as it refer the entire e500 family which includes e500mc.
Thinking over lot of confusion over #define i should use CONFIG_E500_V1_V2_DBG. Please guide me in having correct #define.
Regards, Prabhakar
Dear Prabhakar Kushwaha,
In message 4F572159.9020303@freescale.com you wrote:
Also, what's the "V1_V2" ? Are there also other systems (say, e500 v3 cores), and are this not affected? We already have CONFIG_E500 and CONFIG_E500MC so CONFIG_E500_V1_V2 appears to belong to this group, but if I understand your intentions it does something completely unrelated.
V1_V2 is used because it applied to e500v1 and e500v2 not e500mc processor. So CONFIG_E500MC cant be used. Also I cant use CONFIG_E500 as it refer the entire e500 family which includes e500mc.
Hm... I am not sure if CONFIG_E500 was supposed to include CONFIG_E500MC; it's nowhere documented. Let's assume it is.
What happens if you enable this code on a E500MC system?
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Wednesday 07 March 2012 06:00 PM, Wolfgang Denk wrote:
Dear Prabhakar Kushwaha,
In message4F572159.9020303@freescale.com you wrote:
Also, what's the "V1_V2" ? Are there also other systems (say, e500 v3 cores), and are this not affected? We already have CONFIG_E500 and CONFIG_E500MC so CONFIG_E500_V1_V2 appears to belong to this group, but if I understand your intentions it does something completely unrelated.
V1_V2 is used because it applied to e500v1 and e500v2 not e500mc processor. So CONFIG_E500MC cant be used. Also I cant use CONFIG_E500 as it refer the entire e500 family which includes e500mc.
Hm... I am not sure if CONFIG_E500 was supposed to include CONFIG_E500MC; it's nowhere documented. Let's assume it is.
What happens if you enable this code on a E500MC system?
Debug restrictions are not valid for e500mc system.
At first sight it should not hurt e500mc execution (other than some seemingly unnecessary steps). However i will check this point.
Regards, Prabhakar
Hi Wolfgang,
On Tuesday 13 March 2012 12:44 PM, Prabhakar Kushwaha wrote:
Hi Wolfgang,
On Wednesday 07 March 2012 06:00 PM, Wolfgang Denk wrote:
Dear Prabhakar Kushwaha,
In message4F572159.9020303@freescale.com you wrote:
Also, what's the "V1_V2" ? Are there also other systems (say, e500 v3 cores), and are this not affected? We already have CONFIG_E500 and CONFIG_E500MC so CONFIG_E500_V1_V2 appears to belong to this group, but if I understand your intentions it does something completely unrelated.
V1_V2 is used because it applied to e500v1 and e500v2 not e500mc processor. So CONFIG_E500MC cant be used. Also I cant use CONFIG_E500 as it refer the entire e500 family which includes e500mc.
Hm... I am not sure if CONFIG_E500 was supposed to include CONFIG_E500MC; it's nowhere documented. Let's assume it is.
What happens if you enable this code on a E500MC system?
Debug restrictions are not valid for e500mc system.
At first sight it should not hurt e500mc execution (other than some seemingly unnecessary steps). However i will check this point.
We tried by enabling CONFIG_E500_V2_V2 for E500MC with u-boot patches. It boots fine and debugging can be done.
So, we can use CONFIG_E500 #define instead of CONFIG_E500_V2_V2 i.e. debugging will always be enabled. One have to define CONFIG_DEBUGGER_TEMP_TLB for debugging in AS1 ( Part of patch "powerpc/85xx:Update NOR code base to support debugger" )
CONFIG_DEBUGGER_TEMP_TLB can also be used for placing code which can only be required during debugging (specially code of temporary TLB creation)
Please suggest.
Regards, Prabhakar
On 03/14/2012 04:35 AM, Prabhakar Kushwaha wrote:
Hi Wolfgang,
On Tuesday 13 March 2012 12:44 PM, Prabhakar Kushwaha wrote:
Hi Wolfgang,
On Wednesday 07 March 2012 06:00 PM, Wolfgang Denk wrote:
Dear Prabhakar Kushwaha,
In message4F572159.9020303@freescale.com you wrote:
Also, what's the "V1_V2" ? Are there also other systems (say, e500 v3 cores), and are this not affected? We already have CONFIG_E500 and CONFIG_E500MC so CONFIG_E500_V1_V2 appears to belong to this group, but if I understand your intentions it does something completely unrelated.
V1_V2 is used because it applied to e500v1 and e500v2 not e500mc processor. So CONFIG_E500MC cant be used. Also I cant use CONFIG_E500 as it refer the entire e500 family which includes e500mc.
Hm... I am not sure if CONFIG_E500 was supposed to include CONFIG_E500MC; it's nowhere documented. Let's assume it is.
What happens if you enable this code on a E500MC system?
Debug restrictions are not valid for e500mc system.
At first sight it should not hurt e500mc execution (other than some seemingly unnecessary steps). However i will check this point.
We tried by enabling CONFIG_E500_V2_V2 for E500MC with u-boot patches. It boots fine and debugging can be done.
Be sure to mention in comments that the hack is only really needed for v1/v2.
So, we can use CONFIG_E500 #define instead of CONFIG_E500_V2_V2 i.e. debugging will always be enabled. One have to define CONFIG_DEBUGGER_TEMP_TLB for debugging in AS1 ( Part of patch "powerpc/85xx:Update NOR code base to support debugger" )
CONFIG_SYS_PPC_E500_DEBUG_TLB
CONFIG_DEBUGGER_TEMP_TLB can also be used for placing code which can only be required during debugging (specially code of temporary TLB creation)
Is there something specific you had in mind, other than the use that is already present in this patchset?
-Scott
Hi Scott,
On Thursday 15 March 2012 01:00 AM, Scott Wood wrote:
On 03/14/2012 04:35 AM, Prabhakar Kushwaha wrote:
Hi Wolfgang,
On Tuesday 13 March 2012 12:44 PM, Prabhakar Kushwaha wrote:
Hi Wolfgang,
On Wednesday 07 March 2012 06:00 PM, Wolfgang Denk wrote:
Dear Prabhakar Kushwaha,
In message4F572159.9020303@freescale.com you wrote:
Also, what's the "V1_V2" ? Are there also other systems (say, e500 v3 cores), and are this not affected? We already have CONFIG_E500 and CONFIG_E500MC so CONFIG_E500_V1_V2 appears to belong to this group, but if I understand your intentions it does something completely unrelated.
V1_V2 is used because it applied to e500v1 and e500v2 not e500mc processor. So CONFIG_E500MC cant be used. Also I cant use CONFIG_E500 as it refer the entire e500 family which includes e500mc.
Hm... I am not sure if CONFIG_E500 was supposed to include CONFIG_E500MC; it's nowhere documented. Let's assume it is.
What happens if you enable this code on a E500MC system?
Debug restrictions are not valid for e500mc system.
At first sight it should not hurt e500mc execution (other than some seemingly unnecessary steps). However i will check this point.
We tried by enabling CONFIG_E500_V2_V2 for E500MC with u-boot patches. It boots fine and debugging can be done.
Be sure to mention in comments that the hack is only really needed for v1/v2.
I will clearly mention in doc
So, we can use CONFIG_E500 #define instead of CONFIG_E500_V2_V2 i.e. debugging will always be enabled. One have to define CONFIG_DEBUGGER_TEMP_TLB for debugging in AS1 ( Part of patch "powerpc/85xx:Update NOR code base to support debugger" )
CONFIG_SYS_PPC_E500_DEBUG_TLB
OK
CONFIG_DEBUGGER_TEMP_TLB can also be used for placing code which can only be required during debugging (specially code of temporary TLB creation)
Is there something specific you had in mind, other than the use that is already present in this patchset?
There is no specific use case in my mind other than the patch-set.
Actually, Wolfgang is having concern about code size increase because of "temporary TLB creation" in start.S for debugging. That's why i am planning to use this #define for "temporary TLB creation"
--Prabhakar
participants (3)
-
Prabhakar Kushwaha -
Scott Wood -
Wolfgang Denk