Sandeep, Can you push this change to uboot-ti ? Tom
- 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.
- generic cache routines
- 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.
- 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
- In parallel, we should discuss how to further improve the OMAP3 cache
stuff. What might be generic, what not, what isn't necessary etc.
- 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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot