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

[Minkyu Kang]

Dear Tom,

2009/9/9 Tom <Tom.Rix at windriver.com>:
> Minkyu Kang wrote:
>> 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
>>>
>>
>> Although I did not understand all of the cache routine..
>> the s5pc100 soc doesn't need v7_flush_dcache_all function
>> and other cache routines.
>> But the s5pc110 soc needs this function,
>> and it works fine without modification. (please see my patch)
>>
>
> Please send me a link to your patch.
>
> Tom
>
>
>> I think.. v7_flush_decache_all function can share together.
>>
>> If this function is not moved to soc layer,
>> need to remove omap specific codes (checking device type)
>>
>
>> Thanks.
>> Minkyu Kang
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

http://lists.denx.de/pipermail/u-boot/2009-September/059889.html

top of this thread
thanks.

-- 
from. prom.
www.promsoft.net