Initial Support for the Samsung Omnia (SGH-i900)

Initial Support for the Samsung Omnia (SGH-i900)

[Alex Ferguson]

I've been working on some initial support for the Samsung Omnia (SGH-i900)
in the form of a machine configuration file and kernel. I also posted this
as a bug here:

http://bugs.openembedded.org/show_bug.cgi?id=5335

Stefan Schmidt pointed out some issues with the kernel recipe, and I'd like
some help with one of them.

Currently, the kernel comes from the Andromnia project, and uses their git
repository to fetch the sources. They are the only ones who are actively
working on a kernel, and working together should help speed up the process
of porting the Linux kernel on the SGH-i900, no matter the userspace
implementation.

The kernel requires the gspi8686 firmware images from Marvell for the WiFi
adapter to work. Currently, the firmware files are copied into the kernel
source tree under the directory "firmware" for static inclusion. That's
because of certain constraints with Android.

Question: I'd like to keep the same behavior, but I'm not certain of the
exact way. I could DEPEND on the marvell-gspi-fw package and then have the
kernel recipe copy the firmware files from STAGING_LIBDIR. But that seems
like an error prone behavior. Is there any other way, short of providing my
own files in SRC_URI or not including the firmware in the kernel at all?

Re: Initial Support for the Samsung Omnia (SGH-i900)

[Stefan Schmidt]

Hello.

On Sun, 2009-11-15 at 15:34, Alex Ferguson wrote:
> 
> Currently, the kernel comes from the Andromnia project, and uses their git
> repository to fetch the sources. They are the only ones who are actively
> working on a kernel, and working together should help speed up the process
> of porting the Linux kernel on the SGH-i900, no matter the userspace
> implementation.

That sounds good.

> The kernel requires the gspi8686 firmware images from Marvell for the WiFi
> adapter to work. Currently, the firmware files are copied into the kernel
> source tree under the directory "firmware" for static inclusion. That's
> because of certain constraints with Android.

Can you elaborate on this constraints? I would expect that even android loads
the firmware from /lib/firmware

BTW, you are bulding the kernel with OE, but using an android image?
Sounds strange to me.

> Question: I'd like to keep the same behavior, but I'm not certain of the
> exact way. I could DEPEND on the marvell-gspi-fw package and then have the
> kernel recipe copy the firmware files from STAGING_LIBDIR. But that seems
> like an error prone behavior.

It is, don't do it.

> Is there any other way, short of providing my
> own files in SRC_URI or not including the firmware in the kernel at all?

There should be a way to reference the same files in the SRC_URI as the marvell
firmware recipe does. That would at least avoid having the same firmware files
in the tree twice.

However I would like to understand the need for having it in the kernel tree
first.

regards
Stefan Schmidt

Re: Initial Support for the Samsung Omnia (SGH-i900)

[Alex Ferguson]

Greetings,

Actually, the need for integrated firmware was misunderstood on my part.
It's technically possible for the firmware to be loaded externally under
Android or Angstrom. As for mentioning Android, I would've liked to be
compatible with both projects (Andromnia and Angstrom), but I have since
revised that plan since it is technically unfeasible.

However, I am having some problems with the Marvell firmware. The driver
expects firmware images with names like "gspi8686.bin" and
"gspi8686_hlp.bin". The marvell-gspi-fw package contains firmware files with
non-compatible names. Even with compatible names, the driver fails to find
the firmware under /lib/firmware, though this probably hasn't anything to do
with OE.

There exists a git repository on git.kernel.org with the required firmware
files, though I believe it's better I fix the marvell-gspi-fw package for
future use, as I found no packages depending on it and thus risking
breakage.

Also, I fixed some issues that were previously present with the kernel
recipe I uploaded. Once I fix these firmware issues I'll post a git patch of
the revised kernel and machine configurations.

Thanks a lot,

Alex Ferguson.

Re: Initial Support for the Samsung Omnia (SGH-i900)

[Koen Kooi]

On 16-11-09 14:11, Alex Ferguson wrote:

> However, I am having some problems with the Marvell firmware. The driver
> expects firmware images with names like "gspi8686.bin" and
> "gspi8686_hlp.bin". The marvell-gspi-fw package contains firmware files with
> non-compatible names. Even with compatible names, the driver fails to find
> the firmware under /lib/firmware, though this probably hasn't anything to do
> with OE.
>
> There exists a git repository on git.kernel.org with the required firmware
> files, though I believe it's better I fix the marvell-gspi-fw package for
> future use, as I found no packages depending on it and thus risking
> breakage.

Actually, there are[*], so can't the issues be solved with symlinks?

regards,

Koen

[*] Externally

Re: Initial Support for the Samsung Omnia (SGH-i900)

[Marcin Juszkiewicz]

Dnia poniedziałek, 16 listopada 2009 o 14:11:29 Alex Ferguson napisał(a):
> However, I am having some problems with the Marvell firmware. The driver
> expects firmware images with names like "gspi8686.bin" and
> "gspi8686_hlp.bin". The marvell-gspi-fw package contains firmware files
>  with non-compatible names. Even with compatible names, the driver fails to
>  find the firmware under /lib/firmware, though this probably hasn't
>  anything to do with OE.
> 
> There exists a git repository on git.kernel.org with the required firmware
> files, though I believe it's better I fix the marvell-gspi-fw package for
> future use, as I found no packages depending on it and thus risking
> breakage.

BUG from BugLabs uses Marvell SPI and SDIO firmwares for 8686 wifi chipset. 
Present version of hardware (r1.3) comes with SDIO connected wifi and uses  
firmwares/marvell-sdio-fw_9.70.3-p37.bb recipe for it. 

Older firmwares/marvell-gspi-fw_9.70.3-p37.bb recipe is used for BugWifi 
module support which adds SPI connected Wifi/BT for older hardware revisions.

And this device is supported in OpenEmbedded - we use stable/2009 for it plus 
own overlay.

Regards, 
-- 
JID:      hrw@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

Re: Initial Support for the Samsung Omnia (SGH-i900)

[Alex Ferguson]

I fixed the firmware issues and have made the firmware available externally.
I'll test and upload the machine config along with the kernel, and a couple
of support files for tslib and pointercal.

Koen: Would a do_install_append_sgh-i900() function do?

Re: Initial Support for the Samsung Omnia (SGH-i900)

[Koen Kooi]

On 18-11-09 17:12, Alex Ferguson wrote:
> I fixed the firmware issues and have made the firmware available externally.
> I'll test and upload the machine config along with the kernel, and a couple
> of support files for tslib and pointercal.
>
> Koen: Would a do_install_append_sgh-i900() function do?

Why? Do the symlinks hurt other devices? Machine overrides in do_install 
should pretty much never happen.

regards,

Koen

Re: Initial Support for the Samsung Omnia (SGH-i900)

[Alex Ferguson]

I updated bug #5335 (http://bugs.openembedded.org/show_bug.cgi?id=5335) with
a new patch. Most userspace issues fixed, though a small issue with
xf86-input-tslib remains. Fixes are coming shortly.

Re: Initial Support for the Samsung Omnia (SGH-i900)

[Koen Kooi]

On 15-11-09 14:34, Alex Ferguson wrote:
> I've been working on some initial support for the Samsung Omnia (SGH-i900)
> in the form of a machine configuration file and kernel. I also posted this
> as a bug here:
>
> http://bugs.openembedded.org/show_bug.cgi?id=5335

Oops, I missed a serious bug in your patches:

+++ b/recipes/tslib/tslib/sgh-i900/tslib.sh
@@ -0,0 +1,5 @@
+#!/bin/sh
+
+TSLIB_TSDEVICE=/dev/input/event1
+
+export TSLIB_TSDEVICE

That is so wrong it isn't funny anymore. The eventX numbers are pretty 
much randomly assigned, so you can't depend on them. In OE we have a 
udev script that finds all touchscreens and creates 
/dev/input/touchscreenX symlinks. The default tslib.sh uses those.

Could you please explain why the default tslib.sh isn't working for you?

regards,

Koen

Re: Initial Support for the Samsung Omnia (SGH-i900)

[Alex Ferguson]

On Fri, Nov 20, 2009 at 11:23 AM, Koen Kooi <k.kooi@student.utwente.nl>wrote:

>
> Could you please explain why the default tslib.sh isn't working for you?


Because it doesn't? /dev/input/touchscreenX doesn't exist. The devices
/dev/input/event0 and /dev/input/event1 are consistently assigned to
keyboard and touchscreen, respectively, and I'm having no problem with that.

Support for the SGH-i900 in the kernel isn't perfect yet. There is still a
lot of work to be done, and a lot of drivers are missing or incomplete. It
boots, touchscreen works, wifi works, but that's about it.

Once the drivers are improved and the need for a custom tslib.sh file
evaporates, I'll be sure to open a bug report.

Thanks.

Re: Initial Support for the Samsung Omnia (SGH-i900)

[Koen Kooi]

On 20-11-09 10:51, Alex Ferguson wrote:
> On Fri, Nov 20, 2009 at 11:23 AM, Koen Kooi<k.kooi@student.utwente.nl>wrote:
>
>>
>> Could you please explain why the default tslib.sh isn't working for you?
>
>
> Because it doesn't? /dev/input/touchscreenX doesn't exist.

Then you need to investigate why it doesn't get created.

> The devices
> /dev/input/event0 and /dev/input/event1 are consistently assigned to
> keyboard and touchscreen, respectively, and I'm having no problem with that.

Consistently with your current defconfig, kernelversion and bootargs, 
there is no guarantee that those will stay the same.


> Once the drivers are improved and the need for a custom tslib.sh file
> evaporates, I'll be sure to open a bug report.

We stopped hardcoding event numbers in OE years ago, even the opie 
people saw the light, so I wonder what's the matter with the omnia to go 
backwards a few years :(

regards,

Koen

Re: Initial Support for the Samsung Omnia (SGH-i900)

[Alex Ferguson]

On Fri, Nov 20, 2009 at 1:10 PM, Koen Kooi <k.kooi@student.utwente.nl>wrote:

>
> We stopped hardcoding event numbers in OE years ago, even the opie people
> saw the light, so I wonder what's the matter with the omnia to go backwards
> a few years :(


I see where you're getting at, and I'll add that to my FIXME list. As I
said, it's not a bug yet, but as you said, it might become one later.
There's still a lot of things to be done.

Thanks for the feedback. :)

Re: Initial Support for the Samsung Omnia (SGH-i900)

[Koen Kooi]

On 20-11-09 13:12, Alex Ferguson wrote:
> On Fri, Nov 20, 2009 at 1:10 PM, Koen Kooi<k.kooi@student.utwente.nl>wrote:
>
>>
>> We stopped hardcoding event numbers in OE years ago, even the opie people
>> saw the light, so I wonder what's the matter with the omnia to go backwards
>> a few years :(
>
>
> I see where you're getting at, and I'll add that to my FIXME list. As I
> said, it's not a bug yet, but as you said, it might become one later.
> There's still a lot of things to be done.
>
> Thanks for the feedback. :)

I spent waaaaay too many days trying to figure out why touchscreens 
'suddenly' stopped working. Richard Purdie is the real hero for coming 
up with the udev rule.

regards,

Koen