[U-Boot] [PATCH] arm_cortexa8: support cache flush to other soc

[Tom <Tom.Rix@windriver.com>]

Sandeep,
Can you push this change to uboot-ti ?
Tom

>> 1) From the previous discussion I think we should apply
>>
>> http://lists.denx.de/pipermail/u-boot/2009-August/058492.html
>>


Tom wrote:
> Dirk Behme wrote:
>> Tom wrote:
>>> Minkyu Kang wrote:
>>>> Dear Dirk,
>>>>
>>>>
>>> <snip>
>>>
>>> I have lost track of this thread.
>> Yes, and I'm currently trying to get the track back ;)
>>
>>> When last I worked this, it seemed like the cache routines were going to
>>> be split.
>>>
>>> 1. generic cache routines
>>> 2. legacy soc cache routines.
>>>
>>> Are the generic cache routines in place and can you use them?
>>> Else can you handle your soc specific cache routines as part of a
>>> legacy cache routine ?
>>>
>>> The omap cache routines are dependent on omap rom code and fitting
>>> new routines in using the omap specifics may not be the best way to
>>> go.
>> I'm sure this is not the perfect way, but it seems to me that splitting 
>> all this stuff into several small steps would be the easier for all. E.g.
>>
>> 1) From the previous discussion I think we should apply
>>
>> http://lists.denx.de/pipermail/u-boot/2009-August/058492.html
>>
>> Independent of any discussion if this code is needed at all, if it is 
>> generic or not etc. the main advantage I understood is that it frees the 
>> way for Samsung.
>>
>> 2a) Then, what I understood from Minkyu, we need an additional patch 
>> (discussion?) how to switch CONFIG_L2_OFF from compile time to run time 
>> selection (for Samsung's multi board support)
>>
>> 2b) Then, what I understood from Minkyu, we should discuss about removal 
>> of get_device_type() function
>>
>> 3) In parallel, we should discuss how to further improve the OMAP3 cache 
>> stuff. What might be generic, what not, what isn't necessary etc.
>>
>> 4) Regarding (cache) code duplication, I vote for doing this duplication 
>> first. That is, have working Samsung and OMAP3 code applied in parallel. 
>> While Jean-Christophe might cry "code duplication", I learned from OMAP3 
>> boards that is was easier to unify common code _after_ code duplication 
>> was done and therefore can be easily identified. Discussing about 
>> possible code duplication without being able to see (and test) the code 
>> is sometimes a little tricky ;)
>>
>> As mentioned, doing this in several, small steps I feel more comfortable 
>> with. If we would have done step (1) already, it's my feeling that we 
>> would have reached step 2 or 3 already. But now, we are still discussing 
>> about the 'one big perfect patch'.
>>
>> Best regards
>>
>> Dirk
>>
>>
> 
> I am making this workflow up as I go.. but it seems like the
> way to resolve this is to work through the new sub-arm repo's
> 
> #1 should go to u-boot-ti first and then I will will merge it to u-boot-arm
> Then u-boot-samsung can sync to it and we will all be at a good
> starting point for #2.
> Can #1 go now to u-boot-ti ?
> If there is a merge problem, kick it back to the developer ;)
> 
> This patch moves the cache support out of A8 and into omap3 which is
> the correct place for it.
> 
> I assume the samsung changes are going to go first to u-boot-samsung
> Correct ?
> 
> For 2a) runtime cache enabling / disabling
> New feature I don't think omap needs so it should be at some board or
> soc level that does not impact omap.
> 
> For 2b) get_device_type.  This is an omap-ism that goes away with #1
> 
> The means though that samsung needs its own cache routines.
> If they are going to do 2a) they will need them anyway.
> 
> For 3) I don't think omap needs improving at this point.
> 
> For 4) Lets see how much the samsung cache routines look like the
> omap once they are done.  If it is a lot of cut-n-paste this is
> not worth arguing about a common routine will be easier to manage.
> If the cache code looks really different then it can live at the
> board or soc layer.  As long as no one claims the cpu layer at the
> very least everyone's board will work.
> 
> 
> Tom
> 
> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot