Re: [9fans] ipaq dual pcmcia sleeve unsupported? (or so it seems)

Re: [9fans] ipaq dual pcmcia sleeve unsupported? (or so it seems)

[Sape Mullender]

> I'm trying to use a 2-slot pcmcia sleeve to access wavelan cards.
> (Am I the first to try a dual pcmcia sleeve with Plan 9?)
> (browsing a bit on handhelds.org I noticed that linux support
>  for dual-pcmcia sleeve was especially added)
> Tried orinoco and avaya silver cards.

I'm afraid we haven't seen a two-slot card here at the labs yet, so there's no
code for it yet.

	Sape

Re: [9fans] ipaq dual pcmcia sleeve unsupported? (or so it seems)

[Axel Belinfante]

I hacked in some code that I found in the bootldr sources,
essentially, to turn on the linkup l1110 chips that have been
added in the dual-slot sleeve (one l1110 is also present in the
new expansion plus sleeve, I believe)...

And It's Working Now!
(at least without trying to use suspend/resume, which probably
 still needs work, and the hacked code needs some cleanup, anyway).
currently listening on the bitsy to mp3 from the work fs
using minimad mounted (mfs) from the work fs over cablemodem
and home wavelan, -- Plan 9 _is_ cool! :-)

Funny thing is that the usual slot 0,1 positions seem reversed
(compared to what I have seen at laptops).

Axel.

I wrote:
> > I'm trying to use a 2-slot pcmcia sleeve to access wavelan cards.
> > (Am I the first to try a dual pcmcia sleeve with Plan 9?)
> > (browsing a bit on handhelds.org I noticed that linux support
> >  for dual-pcmcia sleeve was especially added)
> > Tried orinoco and avaya silver cards.
>
> I'm afraid we haven't seen a two-slot card here at the labs yet,
> so there's no code for it yet.
>
> 	Sape

Re: [9fans] ipaq dual pcmcia sleeve unsupported? (or so it seems)

[Axel Belinfante]

Just to be complete about my hacks(*):
suspend/resume indeed do not work as they should
(suspend does not suspend everything, resume does not resume  everything,
 (except when I resume very quickly after suspending?)
 resulting in an unworkable system -- so I resort to the reset button).

I also played with a single-slot pcmcia sleeve, and there I got
similar suspend/resume results once wavelan was up and running.

To satisfy my curiosity (and to distinguish (my?) bugs from features):
what does (should) bitsy powermanagement currently do?
(please note, this is not meant as complaint, but just for me to learn)
How 'hot-swappable' are we? will (can?) we be?
(always reboot? hot swap pcmcia cards? add/remove sleeves?)

Cheers,
Axel.


(*) to give credit where credit is due:
all the nice dual-slot sleeve code comes from bootldr;
all I did was try to fit it in with all the nice existing
plan 9 bitsy code...


> And It's Working Now!
> (at least without trying to use suspend/resume

Re: [9fans] ipaq dual pcmcia sleeve unsupported? (or so it seems)

[Fco.J.Ballesteros]

Ok. I'll build a fresh new kernel with the sources in the tar ball
and let you know of any problem.
In the mean time, you could try downloading the tar ball again, trying
it, and letting me know the behaviour of suspend/resume on your bitsy.

hth

Re: [9fans] ipaq dual pcmcia sleeve unsupported? (or so it seems)

[Stephen Parker]

On Thursday 17 October 2002 4:48 pm, Fco.J.Ballesteros wrote:

> : I've never had any success with suspend/resume on the bitsy, with or
> : without sleeve.
>
> Is yours an H3630?

It is.

> Mine suspends fine. Are you using the distributed sources or the tar ball
> for the bitsy?

I've tried both but neither for a few months.  I had a perfectly good bitsy 
build that did everything I wanted, except suspend/resume.  I even had some 
luck talking to the bluetooth jacket.

stephen

Re: [9fans] ipaq dual pcmcia sleeve unsupported? (or so it seems)

[Fco.J.Ballesteros]

: I've never had any success with suspend/resume on the bitsy, with or
: without sleeve.

Is yours an H3630?
Mine suspends fine. Are you using the distributed sources or the tar ball
for the bitsy?

Re: [9fans] ipaq dual pcmcia sleeve unsupported? (or so it seems)

[Fco.J.Ballesteros]

AFAIK, it suspends/resume properly w/o the backpack.
With the backpack, it's able to do hot-swap of the
pcmcia disk but not much else (I mean it has bugs but
works enough to be usable).

The main problem is that it seems to consume more battery
than windows in the same hardware, which makes me think
that I'm mistaken regarding "it suspends/resume properly w/o the backpack",
sic.

I think I can give you some details if you feel the need.

hth

PS: This was a couple of updates ago, I didn't update our version
of the bitsy source yet.

Re: [9fans] ipaq dual pcmcia sleeve unsupported? (or so it seems)

[Stephen Parker]

On Thursday 17 October 2002 3:16 pm, Sape Mullender wrote:

I've never had any success with suspend/resume on the bitsy, with or
without sleeve.

stephen


> > To satisfy my curiosity (and to distinguish (my?) bugs from features):
> > what does (should) bitsy powermanagement currently do?
>
> Suspend/resume appears to work on bitsies without sleeve.  I say appears
> because I'm not sure whether it works completely: i.e., everything that can
> be turned off during suspend may not be properly turned off and not
> everything may always come back properly.  I'm afraid I have no time for
> the bitsy at the moment — more pressing projects (involving PowerPCs) take
> my time now.
>
> 	Sape

Re: [9fans] ipaq dual pcmcia sleeve unsupported? (or so it seems)

[Sape Mullender]

> To satisfy my curiosity (and to distinguish (my?) bugs from features):
> what does (should) bitsy powermanagement currently do?

Suspend/resume appears to work on bitsies without sleeve.  I say appears
because I'm not sure whether it works completely: i.e., everything that can
be turned off during suspend may not be properly turned off and not everything
may always come back properly.  I'm afraid I have no time for the bitsy at the
moment — more pressing projects (involving PowerPCs) take my time now.

	Sape

Re: [9fans] ipaq dual pcmcia sleeve unsupported? (or so it seems)

[Fco.J.Ballesteros]

> I took nemo's tar ball, and built on that,
> but needed tiny changes to be able compile his code.

Yep. The bitsy tar ball in the web is out of date; it corresponds
to a few updates ago. I'll update it as soon as I can, but probably
not this week. Sorry.

Re: [9fans] ipaq dual pcmcia sleeve unsupported? (or so it seems)

[Axel Belinfante]

[-- Attachment #1: Type: text/plain, Size: 770 bytes --]

Below are the ``raw'' hacks (including all my debugging code).
To give a clearer picture of the changes, and of the actual
resulting code I attached a gzipped tar that contains a diff file ``diffs''
compared to nemo's tar ball, together with those files that I changed for
the dual pcmcia pack.

I'm pretty sure things need still attention, look e.g. for LINKUP_PRC_APOE

Also, the code just looks for the first linkup chip and then assumes
a dual slot pcmcia pack, so the second one should be there as well
(which will not be the case for the expension plus pack).
This could be dealt with using sleeve identification, I suppose.

But then again, this is the code exactely at the point where it
(finally) worked for the first time...

Cheers,
Axel.


[-- Attachment #2: Type: application/octet-stream, Size: 14617 bytes --]

Re: [9fans] ipaq dual pcmcia sleeve unsupported? (or so it seems)

[Axel Belinfante]

> Going to post your hacks?

Sure. Was wondering about the amount of cleanup (and further testing)
needed before posting. I also think that maybe I do a bit too much
(enable the l1110 at more places than needed). But it seems to work,
and of course I can post what I have now.

Question is, what is the best way?
I took nemo's tar ball, and built on that,
but needed tiny changes to be able compile his code.
Cleanest still is probably a diff w.r.t. nemo's code.

I'll have a look at such a diff.

Axel.

Re: [9fans] ipaq dual pcmcia sleeve unsupported? (or so it seems)

[presotto]

[-- Attachment #1: Type: text/plain, Size: 25 bytes --]

Going to post your hacks?

[-- Attachment #2: Type: message/rfc822, Size: 3701 bytes --]

From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ipaq dual pcmcia sleeve unsupported? (or so it seems)
Date: Wed, 16 Oct 2002 23:48:02 +0200
Message-ID: <200210162148.g9GLm3r06999@zamenhof.cs.utwente.nl>

I hacked in some code that I found in the bootldr sources,
essentially, to turn on the linkup l1110 chips that have been
added in the dual-slot sleeve (one l1110 is also present in the
new expansion plus sleeve, I believe)...

And It's Working Now!
(at least without trying to use suspend/resume, which probably
 still needs work, and the hacked code needs some cleanup, anyway).
currently listening on the bitsy to mp3 from the work fs
using minimad mounted (mfs) from the work fs over cablemodem
and home wavelan, -- Plan 9 _is_ cool! :-)

Funny thing is that the usual slot 0,1 positions seem reversed
(compared to what I have seen at laptops).

Axel.

I wrote:
> > I'm trying to use a 2-slot pcmcia sleeve to access wavelan cards.
> > (Am I the first to try a dual pcmcia sleeve with Plan 9?)
> > (browsing a bit on handhelds.org I noticed that linux support
> >  for dual-pcmcia sleeve was especially added)
> > Tried orinoco and avaya silver cards.
>
> I'm afraid we haven't seen a two-slot card here at the labs yet,
> so there's no code for it yet.
>
> 	Sape

[9fans] ipaq dual pcmcia sleeve unsupported? (or so it seems)

[Axel Belinfante]

I'm trying to use a 2-slot pcmcia sleeve to access wavelan cards.
(Am I the first to try a dual pcmcia sleeve with Plan 9?)
(browsing a bit on handhelds.org I noticed that linux support
 for dual-pcmcia sleeve was especially added)
Tried orinoco and avaya silver cards.

When I have the card in the slot closest to the ipaq
(isn't that usuallay slot 1, and the one further away slot 0?)
cat /dev/pcm0ctl returns: occupied
cat /dev/pcm0attr returns nothing
cat /dev/pcm1ctl triggers (consistently) a kernel panic (trace below).

Additionally, the sleeve seems to have a bad effect on resuming:
usually (always?) the screen is resumed, but touchscreen and buttons
(e.g.  the ``record'' button that hides/shows the keyboard window)
don't work.

I tried both the kernel I made from /sys/src/9/bitsy from sources,
and the one from nemo's bitsysd.tgz code (slightly modified:
commented out the calls to tod[gs]etoff in power.c, extended
wavenames in wavelan.c)

In case it matters, I'm using bootloader version 2.18.01
and it seems to have a tendency to add always a bootldr and
a root partition by itself, at least when I'm using it from the
``serial bootloader console'' (i.e. the boot> prompt).
The bootldr partition is the usual one, but the root partition
overlaps with a number of partitions.
However, the documentation says something about not reading
the params partition in case of reset+cursor-button, and
elswhere I read that the partition table is stored at the
start of the params partition, so maybe that explains this.
I also noticed that 2.18.01 is noted as ``the very stable version'',
maybe some things have improved in the (many) newer versions.

In particular, immediately after ``getting'' the ``boot>'' prompt
I only see the bootldr and root partitions with ``partition show''.
After suspend/resume I also see the other (plan9) partitions.

Any help is very much appreciated,
Axel.

kernel trace with original (sources) kernel:

[...]
increfp full power
decrefp 0
increfp power down
increfp 1
increfp full power
kernel fault:
type 0x00000018 psr 0x80000013 pc 0xc0039194
r0  0xc0679b48 r1  0x00100000 r2  0x98100000 r3  0xc00e5084
r4  0xc0679b40 r5  0x38100000 r6  0x00000000 r7  0x98100000
r8  0x00000000 r9  0xc00e8000 r10 0xa0000000 r11 0x000fffff
r12 0xc008e99c rpanic: fault: kernel accessing 0x98200000

panic: faktrace /kernel/path c000b028 c0679864 c06798aa
ult: kec0679810=c000b024 rnel acc0679814=c00678c8 cessingc067981c=c002df90  0x9820c0679840=c002dfec 0000


c0679858=c002e1bc c067985c=c000b024 c0679860=c002e1c0 c0679868=c0009e54
c06798b4=c00871a0 c06798b8=c0086778 c06798c4=c0083c50 c06798d4=c00871a0
c0679948=c000b290 c067994c=c000b268 c0679954=c006f748 c0679958=c005fe58
c067996c=c0009e1c c0679970=c006f774 c0679988=c000a1f4 c0679994=c0062eec
c0679998=c0063058 c06799a0=c0062f0c c06799a4=c0063078 c06799ac=c000b364
c06799d0=c0009fa4 c0679a0c=c000a2b0 c0679a24=c00082ac c0679a4c=c00082ac
c0679a8c=c002cbf8 c0679a9c=c0082520 c0679aa0=c0083674 c0679aa4=c00827f4
c0679ab0=c00827b8 c0679ab8=c00840a8 c0679ad8=c005941c c0679b18=c00394f4
c0679b28=c002da08 c0679b5c=c002cc88 c0679b74=c006aeb0 c0679ba4=c0082590
c0679bac=c0082888 c0679bb8=c0083674 c0679bbc=c0082838 c0679bc4=c00829d8
c0679bc8=c00827b8 c0679bd0=c00840a8 c0679bdc=c0083fbc c0679bf0=c0084438
c0679c10=c00574c8 c0679c1c=c0059ad0 c0679c24=c0059ab8 c0679c4c=c006ae8c
c0679c78=c0008244
it's a wonderful day to die

trace with nemo's (slightly modified) sources:
[...]
decrefp 0
increfp power down
increfp 1
increfp full power
kernel fault:
type 0x00000018 psr 0x80000013 pc 0xc0040df8
r0  0xc0681a30 r1  0x00100000 r2  0x98100000 r3  0xc00ecb20
r4  0xc0681a28 r5  0x38100000 r6  0x00000000 r7  0x98100000
r8  0x00000000 r9  0xc00f0000 r10 0xa0000000 r11 0x000fffff
r12 0xc0096714 rpanic: fault: kernel accessing 0x98200000

panic: fktrace /kernel/path c000b038 c068174c c0681792
ault: kc06816f8=c000b034 ernel ac06816fc=c006f65c ccessinc0681704=c0035b9c g 0x982c0681728=c0035bf8 00000


c0681740=c0035dc8 c0681744=c000b034 c0681748=c0035dcc c0681750=c0009e64
c068179c=c008ef14 c06817a0=c008e4ec c06817ac=c008b9c4 c06817bc=c008ef14
c0681830=c000b384 c0681834=c000b35c c068183c=c00774c4 c0681840=c0067be4
c0681854=c0009e2c c0681858=c007759c c0681870=c000a204 c068187c=c006ac98
c0681880=c006ae04 c0681888=c006acb8 c068188c=c006ae24 c0681894=c000b458
c06818b8=c0009fb4 c06818f4=c000a2c0 c068190c=c00082ac c0681934=c00082ac
c0681974=c00345a4 c0681984=c008a294 c0681988=c008b3e8 c068198c=c008a568
c0681998=c008a52c c06819a0=c008be1c c06819c0=c006116c c0681a00=c0041114
c0681a10=c0035610 c0681a44=c0034634 c0681a5c=c0072c44 c0681a8c=c008a304
c0681a90=c008a294 c0681a94=c008a5fc c0681a98=c008a67c c0681a9c=c008a294
c0681aa4=c008a568 c0681ab0=c008a52c c0681ab8=c008be1c c0681ac4=c008bd30
c0681ad8=c008c1ac c0681af8=c005f21c c0681b04=c0061850 c0681b0c=c0061838
c0681b34=c0072c20 c0681b60=c0008244
it's a wonderful day to die

Bootloader related dumps:
In particular, immediately after ``gettting'' the ``boot>'' prompt
I only see the bootldr and root partitions with ``partition show''.
After suspend/resum I also see the other (plan9) partitions:

root is from (paq)[paq]: .......................
[interupted by pressing reset button]
boot>
boot> partition show
argv[1]=show
npartitions=00000002
bootldr
  base: 00000000
  size: 00040000
   end: 00040000
 flags: 00000002
root
  base: 00040000
  size: 01FC0000
   end: 02000000
 flags: 00000018
boot> Snoozing...Disabling LCD conboot> Snoozing...Disabling LCD conboot>
boot> partition show
argv[1]=show
npartitions=00000008
bootldr
  base: 00000000
  size: 00040000
   end: 00040000
 flags: 00000002
bootldr
  base: 00000000
  size: 00040000
   end: 00040000
 flags: 00000002
root
  base: 00040000
  size: 01FC0000
   end: 02000000
 flags: 00000018
params
  base: 00040000
  size: 00040000
   end: 00080000
 flags: 00000000
kernel
  base: 00080000
  size: 000C0000
   end: 00140000
 flags: 00000000
user
  base: 00140000
  size: 000C0000
   end: 00200000
 flags: 00000000
ramdisk
  base: 00200000
  size: 00600000
   end: 00800000
 flags: 00000000
fs
  base: 00800000
  size: 00800000
   end: 01000000
 flags: 00000000
boot>

Typical boot sequence when booting from the ``boot>'' prompt
(several reboots after the excerpt above was taken, which
 probably explains the even larger number of bootldr partitions)
Note that there is some garbage (I replaced unprintable by ?)
in the line following 'setting boot parameters to', and in
'command line is'; this seems to be reproducable.

boot>
boot> boot flash
booting flash...
booting kernel from partition >kernel<
kernel partition base 50080000
kernel_magic=E3300000
kernel_region_words[9]=016F2818
Linux ELF flash_imgstart=50080000 size=000C0000 dest=C0000000 offset=00008000
MMU Control=C19F4171
MMU PIDVAM=00000000
copying Linux kernel ... done
C0008000: E3300000
C0008004: E3300000
C0008008: E3300000
C000800C: E3300000
C0008010: E59FC878
C0008014: E3A00001
C0008018: E3A11001
C000801C: E1510000
C0008020: 0A000002
C0008024: 016F2818
root_filesystem_name=ramdisk
Grabbed linuxargs, argc = 00000002
Using mach_type 00000016
pre unparse setting boot parameters to
 noinitrd root=/dev/mtdblock1 init=/linuxrc console=ttySA0
setting boot parameters to
 noinitrd root=/dev/mtdblock1 init=/linuxrc console=ttySA0 ?4???
Makeing core tag at C0000100
Makeing cmdline tag at C0000114
Makeing mem32 tag at C0000248
Makeing ptable tag at C0000258
dram_size=02000000
nr_pages=54410001
command line is: mtdpart=bootldr@0x00000000:0x00040000,bootldr@0x00000000:0x00040000,root@0x00040000:0x01FC0000,params@0x00040000:0x00040000,kernel@0x00080000:0x000C0000,user@0x00140000:0x000C0000,ramdisk@0x00200000:0x00600000,fs@0x00800000:0x00800000  noinitrd root=/dev/mtdblock1 init=/linuxrc console=ttySA0 ?4???g
Disabling LCD controller
linuxEntryPoint=C0008000
Booting Linux image
inflating kernel
...........................................206 MHZ ARM, ver 1/part b11/step 6
4771 free pages, 19084K bytes, 114520K swap
root is from (paq)[paq]: paq....: Fri Oct 11 15:31:01 GMT 2002
fingerprint: 5c1713e4271dc7219a8e832dbe009d8336c98ccf
version...time...
paq....: Fri Oct 11 15:31:01 GMT 2002
fingerprint: 5c1713e4271dc7219a8e832dbe009d8336c98ccf
version...time...
aux/flashfs: check clock: delta = 1060
increfp 0
increfp full power
[...]


As said above, any help appreciated, very much!
Axel.