[Linux-Xtensa] Re: [patch 0/8] xtensa: s6000 & s6105 - Git Repo Pulled; will try to merge early next week and get back to ya.

linux-xtensa at linux-xtensa.org linux-xtensa at linux-xtensa.org
Tue Mar 17 01:18:48 PDT 2009

Johannes Weiner wrote:
> On Fri, Mar 13, 2009 at 02:42:43AM -0700, Piet Delaney wrote:
>> Johannes Weiner wrote:
>>> On Wed, Mar 11, 2009 at 05:44:45PM -0700, Piet Delaney wrote:
>>>> Johannes Weiner wrote:
>>>>> Hi,
>>>>> here is the core series of our s6000 port.
>>>>> First comes the nommu patch.  Right now we use CONFIG_MMU for
>>>>> everything that separates the S6000 from existing ports, memorywise.
>>>>> This is a lot easier and can still be broken up by newer ports when
>>>>> they have requirements with finer granularity.  Furthermore, we have
>>>>> only this one nommu box here, so we couldn't test an MMU architecture
>>>>> and therefor not say for sure we didn't break anything ;)
>>>> Perhaps you have a pointer to a git repository with your changes
>>>> that I can clone from.
>>> http://git.opensource.emlix.com/cgi-bin/gitweb.cgi?p=kernel/xtensa/linux-2.6.git;a=summary
>> Great, I Pulled it earlier this evening. A bit slow over the Atlantic,
>> having a common cached version might be worthwhile.
> Ah, sorry.  http is also slower than the git protocol, I think.
>>> It's based on 2.6.29-rc7 and then some.  The base is not terribly good
>>> chosen but we didn't want to go back to .29 and since it's so late in
>>> the release cycle -rc7 should be quite stable as well.
>>>> I can make sure the LX60 and LX200 didn't break. We have a
>>>> number of bug fixes and new support for SMP and a new MMU
>>>> that we expect to ready for prime time soon. I'd prefer to
>>>> use git to test your changes and doing the merge.
>>> Yeah, it's much easier that way.  Thanks for the testing, we really
>>> appreciate it!
>> I got one of the S6000 Demo boards, do you have anything on
>> how to get linux running on the board. Chris Jones is talking
>> to Stretch about SDK's that I likely need. Any suggestions
>> or recommendations?
> We use e2factory (e2factory.org) to build an image, but you need
> something to get it on the box.  Do you already have a way?

I downloaded e2factory and tried to make the docs but have
a problem with 'markdown'. I found markdown and installed it
but it's not being found. Perhaps a lib path problem.
Any suggestion?

I discovered that lua-5.1.3.tar.gz also had to be downloaded.
It seems to be unpacked but make isn't doing much and I don't
see any compilers and other build tools.

It would be nice to have detailed building instructions
like we have for xtensa buildroot.

Could you explain more in detail what your doing?

In parallel we likely will build a description for this
stretch core and try the std xtensa tools.

>> I'll likely merge with your repo and test for regressions
>> early next week. We might need to discuss with Marc the
>> replacement with the generic timer code. I was Wondering
>> about the reason for this change and if we will lose High
>> Resolution Timer running at variable intervals to save power
>> is effected. I need to study this area more.
> I did the conversion to the clocksource interface out of interest, it
> is not part of our Stretch work.
> It shouldn't interfer with hres timers, in fact, I think it's a
> necessity for them.
> Quoting kernel/time/Kconfig:
> 		bool "High Resolution Timer Support"
> The next step is probably to implement the ccompare register as clock
> event device.

Sounds good.

>> Once I merge with your code and it works I'd like to
>> post it to our website and you let me know if you see
>> any regressions on your side with the S6000 or if you
>> find any of the changes inappropriate for going upstream.
> Okay, great.
>>>> How about I add accounts for you, Oskar, and Daniel and
>>>> we use the repo(s) as a staging site to test each other's changes
>>>> before passing them upstream to Christian and Linus.
>>> I'm all for synchronizing our work but either way to do that is fine.
>>> We can pull from each other or just share a central repository.
>>> Of course, the latter would prevent us from stomping on each other's
>>> feet.  We don't want to break stuff horribly and make your life hard.
>> After this first round of changes I think we will know how best to
>> optimize for the future.
> Yep.
>>> And code doesn't just appear in your repository, we would write an
>>> explicit pull request email for a set of fixes or new features and
>>> then you can look over the changes before you merge them into your
>>> tree, and give synchronous feedback, criticism and comments.  Just
>>> like upstream works.
>> Sounds fine.
>>> What do you think?
>> So far you changes looks like they will have only minor
>> interference with SMP and V3 MMU changes we have made. I
>> need to understand the GENERIC_TIME config change more.
>> If you could explain it a bit it would probably save
>> me a bit of time understanding the impact. Looks like current
>> functionality won't be effected. Worried about High Resolution
>> Timer support that Marc has plained for the future to save
>> power while idle.
> Every architecture used to implement get/settimeofday manually.  Now,
> this is all handled in generic code, you only need to provide this
> generic code with a description of how to get a measure of time in
> nanoseconds.  These descriptions are called clocksources.  I use the
> ccount register for that, the kernel can then deduce from it the
> monotonic and the wallclock time.
> Architectures not yet converted use the jiffies clocksource by
> default.  The jiffies variable will be updated once every clocktick.
> So right now, the granularity of the time on xtensa is the tick rate
> (several ccount increments until == ccompare) while with my changes,
> the granularity of time is that of ONE ccount register increment.
> The jiffies clocksource implementation is in kernel/time/jiffies.c.
> With the clockEVENT infrastructure, the timer interrupt does not do
> much on its own but calls into generic code.  Generic code can use the
> clockevent descriptor to program the next timer interrupt dynamically
> (if the clockevent device supports it, ccompare does) which can reduce
> wake-ups drastically.  Because our clocksource doesn't rely on regular
> ticks anymore, the ticks don't have to occur for measuring time.
> As described above, I think the conversion is actually essential for
> having hres timers.
>> Maxim and I were busy this afternoon sorting out a uclibc
>> Buildroot problem with 2.6.17 headers. Hope to get merged
>> with your changes early next week and get back to ya.

Maxim and I sorted out the 2.6.27 header problem and I'm cleaning up my
files to check in the stuff Marc and I did to stabilize the SMP (including
cache alias issues) and new V3 MMU code. Once checked in I'll try
merging with your git repository. I put a local cache on linux-xtensa.org
so everyone here has ready access to it.


I've got a Stretch IP Camera board and a Stretch Debug board.


More information about the linux-xtensa mailing list