Re: 2.4 critical compiling error in softirq.c with gcc 4.3

Cheers,

On Mon, 3 Mar 2008, Paul Sokolovsky wrote:

> Hello,
>
> On Mon, 3 Mar 2008 22:33:01 +0100 (CET)
> Ivan Vucica <ivucica_at_gmail.com> wrote:
>
>> Pretty true. MMC for starters. Observe, asic1_mmc.c is a copypaste
>> from 2.4 (at least it was last time I checked, few weeks ago). If
>> something changed, I'll be extremely glad to use 2.6 instead.
>
> That only means that it needs to be fixed for 2.6.
>

...if there's someone to fix it, that is :)

>> And asic1_mmc.c is not alone.
>>
>> I had some free_time/day few months ago, but as time passes, I have
>> less and less of that.
>
> That means that h3800 port will die.

Frankly, I think a sad fact is that it already died, and that best thing I
can do is take the last working Familiar image and flash my device
(again).

I mean, not being ported to 2.6, and now that 2.4 is broken too... It's
pretty frustrating that I managed to compile it fine few months ago, on
pretty much same compilers (I'm certain I used EmDebian variant). They are
perhaps updated, but shouldn't all software that worked on a 4.1-1 keep
working on 4.1-2 or so?

>> So, although I have tried in many ways to:
>> a) find a mentor to help me hack the kernel
>
> If you'll have patches, we'll be able to suggest you on them. But the
> kernel itself is the best own mentor, albeit silent. But if you will
> watch carefully its signs, in a mere month you'll be able to do what
> you need.

My main obstacle is a total lack of documentation of any sort for the 3800
port. And a lack of hardware background. What I'm being taught at the
university helps not. Sadly, nobody gave us a solder, components and told
us "Make this work, here's the docs".

And even less was I taught by anyone on how to talk to ASIC using GPIO
through existing architecture in a half-broken port of Linux kernel.
(Which is what I tried to figure out, to very little success.)

Would, for example you, care to try to look at h3600/3800 port (most are
same) and see how they started doing things in 2.6, and compare to 2.4? If
you tell me _SOMETHING_ about it, I'd be more than willing to start
scraping up drivers, even with limited time I have.

>> b) try to _contact_ several members of h3800 porting team to assist me
>> by providing docs and/or mentorship
>
> There's no such porting team currently. You will head it if you start.

I, of course, meant the old Compaq Cambridge Labs porting team. :)

And judging from the activity on h3800 port, I'd probably stay the leader
of a one-man team -- which is sad, considering all the fuss early Compaq
devs were giving around h3600 and h3800.

>> Under b) I mean Jamey Hicks and Andrew Christian. I even went through
>> other people to do so (George France). George said he'll give my mail
>> to Andrew, but it's been a more than three months since he said that.
>> Since my last poke, it's been about a month.
>
> Those people are project alumni. Without new people coming, the work
> they started grows unmaintained, withers, and becomes fossils. That's
> very sad, and we (and I personally) did lot to save *everything*
> possible. Well, now it's better to face the sad fact.

Another sad thing is that it's rather hard for people to adapt to the
kernel development mindset. I'm personally an OpenGL/C++ type; where I
can get results in short time, without much messing on low-level, and
without fear that by raising this to 5V I won't accidentally fry something
because hardware designers didn't predict that. I'm the kind of guy who
gets away with memory leaks, and fixes them later in development ("results
first, fixes later").

I'm not proud of all that, and I liked to think of myself as an "all-jobs
person"; lately it's becoming evident more and more that some thing are
simply not for me.

I fear that I'm not alone. And even worse; my university department (we
call that "Fakultet") is dedicated to computer sciences. But it's filled
with people with little or no prior programming experiences. And farther
one looks into the senior years, more Microsoft-fanboys, C-Sharpers and
Javaers can one find. That means even less experience with low level
coding than what I have.

Combine that with the fact that most spread PPCs around me today are not
iPAQs (especially not h3800s), and are HTCs, and you get the reason why
this port has died. Even those who could perhaps do kernel development
don't have the hardware, time or incentive to do so. Remember -- even the
alumni as you call them were actually on Compaq's payroll when they
got the thing rolling. They were paid for it, and they had
device manufacturer's support. They could fiddle with the device all day
and get paid for it; if they bricked the device, they'd probably get
another one and fry that one too, until they debugged bootloader
completely.

Am I willing to do the port? Yes, I am.
_Can_ I do the port? Perhaps, but it's leaning towards a No.

That is, unless there'll be someone who'll dig a bit around the kernel,
explain some things to the newcomer that I am, and help him port. I'd do
most of the work, of course, since I have the hardware, but I simply can't
do everything. I'm willing to do it, but I can't do it.

So -- can you point me to someone who can explain to me how, for example,
MMC on iPAQ works? And how the communication with device in Linux kernel
works? And how the MMC subsystem in Linux works?

Or can someone who tracks this list point me to someone?

If the answer is yes, well, I may even be able to scrape up something. I
don't expect results within 5 minutes, but I'd really like _something_ to
work at least after 3-4 hours of fiddling with it all. And I spent about
10 hours already compiling and recompiling, changing this and that,
copypasting this and that, adding this and that include.

I learned practically nothing, perhaps only a bit about directory
structure in 2.6, and that most of the IMPORTANT code for talking to the
ASIC(s?) is commented out. And some more guesswork, but NOTHING THAT WOULD
GET ME ONE STEP CLOSER to getting a working MMC on 3800.

And yes, did I mention that some other things also seem commented out,
such as touchscreen?

Perhaps I'd have more luck grabbing the hw specs, vanilla upstream 2.6 and
trying to patch that, than working on the existing nonworking 3800/2.6.

>>
>> Hm, I'm feeling rather stupid right now. But I'll ask it anyway:
>> What did you mean? Doesn't exist? Eh?
>
> I mean something like: 2.4 is a dinosaur and it exists in the same
> sense as dinosaurs exist. Obviously, this is my personal, highly
> orthodox opinion. If 2.4 works for you, nice. If it doesn't, and you
> want to "fix it", per the same highly personal and orthodox opinion,
> that's waste of time, which could be invested into 2.6 instead.
> Obviously, only you decide on what to do.

That's indeed so.

I tried 2.4 because historically I managed to compile it. Few months
later, with pretty much same compilers, that no longer seems to be the
case. I'll additionally try EmDebian GCC 3.3, but I'm no longer hoping for
success.

Would you care to try to _just compile_ the 2.4 kernel? If it works for
you, it might be a good idea to say somewhere "It works with this-and-this
toolchain". Because, some devices work on 2.4 that don't work on 2.6,
obviously.

And once again the appeal -- if someone reading this is willing to invest
some time into teaching one grateful newbie things about iPAQs and kernel
programming: come on, dive into the code, invest 1 hour digging out the
information I'd like to know, and send them to me. (And waste 15 minutes
every few days to respond to my mails.) That'll probably get h3800 port up
and running again, but on 2.6!

Thanks.

P.S. Enjoyed reading this?

-----------
Ivan Vucica
Received on Mon Mar 03 2008 - 17:51:29 EST