Re: Re: [Kernel-bugs] h5400 patch - merge h5400_bt.c back to h5400.c

Hello,

On Fri, 22 Feb 2008 01:10:10 +0100
"Michal Panczyk" <mpanczyk_at_gmail.com> wrote:

> After some thinking how to express myself in clearer way .....
>
> > Ok, few words about how this works. There're no actually devices in
> > OE images (or to be more exact, there're some static once, but only
> > minimal set required for initial boot stage). The devices you see
> > are created dynamically by udev based on info exported by the
> > kernel. Have a look at arch/arm/mach-pxa/generic.c:655:
> >
> > /* Only add HWUART for PXA255/26x; PXA210/250/27x do not
> > have it. */ cpuid = read_cpuid(CPUID_ID);
> > if (((cpuid >> 4) & 0xfff) == 0x2d0 ||
> > ((cpuid >> 4) & 0xfff) == 0x290)
> > ret = platform_device_register(&hwuart_device);
> >
> > (So, extra detail: not even PXA27x has HWUART!)
> >
> > So, based on that, ttyS3 internal kernel device will be registered
> > only for PXA255/26x, on other CPUs udev will never see it and never
> > will create /dev/ttyS3 device node in filesystem. So, all stuff as I
> > described should work. If it won't, there's bug elsewhere, and we
> > will find it too ;-).
> >
>
> on h5400 (pxa250):
> root_at_h5000:~$ ls -l /dev/ttyS*
> crw------- 1 root root 4, 64 Jan 1 00:01 /dev/ttyS0
> crw-rw---- 1 root dialout 4, 65 Jan 1 00:00 /dev/ttyS1
> crw-rw---- 1 root dialout 4, 66 Jan 1 00:00 /dev/ttyS2
> crw-rw---- 1 root dialout 4, 67 Jan 1 00:00 /dev/ttyS3
>
> Does that mean that we have a bug somewhere else ?

Yes. See http://www.handhelds.org/hypermail/kernel-discuss/7/0738.html
where this patch was introduced. Note it quotes 0x69052903 as cpuid for
PXA26x. And yet on my h3900:

CPU: XScale-PXA250 [69052904] revision 4 (ARMv5TE), cr=0000397f

I bet that's what you have on your h5400 too. Searching inet for
69052903 gives:
http://osdir.com/ml/handhelds.ipaq.boot-loader/2003-10/msg00004.html -
quoted for h3900,
http://forum.brighthand.com/showthread.php?t=213382&page=3 - quoted for
e330. Finally, I asked BabelO on IRC for what he has on his
htcblueangel (pxa263) and he quoted:
CPU: XScale-PXA255 [69052d06] revision 6 (ARMv5TE), cr=0000397f

That's weird because it is the same value as for pristine PXA255, but
at least it's now clear that mentioned message has it wrong. With that
fixed, it becomes much more logical: first there was original pxa250,
rather broken, then pxa250 v2, then pxa210 (sic), then pxa255/pxa26x,
then pxa27x.

So, I'm going to kill test for 0x290 above, and that should settle it.

>
> > > Or should there be a command forcing the use of HWUART ?
> >
> > We cannot force its use - it doesn't exist in h5400, period! ;-)
> >
> >
> > So, my try on that is:
> >
> > --- blueprobe.init.1 2007-11-12 20:43:46.000000000 +0200
> > +++ blueprobe.init 2008-02-20 00:29:44.000000000 +0200
> > @@ -46,7 +46,11 @@
> > ;;
> > "HP iPAQ H5400")
> > BLUETOOTH=yes
> > - PORT=/dev/ttyS3
> > + if [ -a /dev/ttyS3 ]; then
> > + PORT=/dev/ttyS3
> > + else
> > + PORT=/dev/ttyS1
> > + fi
> > SPEED=921600
> > PROTO=any
> > PROBE=yes
> >
> > That's my little gift, you'd still need to provide complete patch
> > for OE ;-).
> Thanks Paul ... I really like gifts. But I guess this one is not going
> to work....
> I have ttyS3 and ttyS1. I start with ttyS1, because in different order
> bluetooth is not going to work at all.
> Modified blueprobe woild not work fine in this case...
>
> On h5400 :
> root_at_h5000:~$ /sbin/hciattach /dev/ttyS1 any 921600
> [ 372.780000] Bluetooth: HCI UART driver ver 2.2
> [ 372.780000] Bluetooth: HCI H4 protocol initialized
> [ 372.790000] Bluetooth: HCI BCSP protocol initialized
> root_at_h5000:~$ hciconfig
> hci0: Type: UART
> BD Address: 08:00:17:13:46:A3 ACL MTU: 339:4 SCO MTU: 60:9
> UP RUNNING PSCAN ISCAN
> RX bytes:694 acl:0 sco:0 events:20 errors:0
> TX bytes:353 acl:0 sco:0 commands:20 errors:0
>
> root_at_h5000:~$ killall hciattach
> root_at_h5000:~$ /sbin/hciattach /dev/ttyS3 any 921600
> root_at_h5000:~$ hciconfig
> hci0: Type: UART
> BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0
> DOWN INIT RUNNING
> RX bytes:0 acl:0 sco:0 events:0 errors:0
> TX bytes:4 acl:0 sco:0 commands:1 errors:0
>
> I have not played with it on h5500 - I will ask MIlan tomorrow.
>
>
> So should I start thinking of following Erik's suggestion ?
>
> --
>
> Michal

-- 
Best regards,
 Paul                          mailto:pmiscml_at_gmail.com