OSD gets GPL USB stack and SDIO from Cadenux

[Fernando Cassia]

Well, some things take ages, but I finally found the CD where I had the emais from Cadenux. I had even forgotten the name of the company!

An article has been submitted to THE INQUIRER and I'm sure Paul Hales will publish it once he sees it there.

In a nutshell: I bugged Gregory Nutt, and Todd Fischer so bad that Todd, -whom authored the Cadenux USB stack for DM320 and the SDIO drivers, hence he had full ownership of the code- agreed to release it as GPL. He only asked that as a courtesy (I actually had the idea) Cadenux is mentioned somewhere in the about: screen or firmware credits.

What does this mean? That perhaps we'll get SDIO-Bluetooth cards working on the OSD, and hence Bluetooth keyboards supported. (he says the SDIO code is tested and has no bugs, he has one commercial customer still using that code).

FC

PS: He did this late November/Early December 2008 !! SORRY!. I didn't plan to lose my main notebook hard drive, nor to get sick. So those CDs were my last hope.
PS#2: I only managed to salvage the SDIO part, Todd tolde me he'd send the full USB stack but I'm not sure if he ever did. In any case, I have to re-establish contact and bug him.

[Gerry Boland]

Hey Fernando

excellent work, I'm delighted to see this. Once we get the code *poke* :), we will have to see for what kernel version it is written for (I suspect 2.6.4), and then work on porting it to a newer kernel.

This isn't a substitute for documentation for the DM320, but it should help us fix our biggest problem with the OSD1, the crappy USB.

Thank you for this Fernando!

-Gerry

2009/6/2 Fernando Cassia <fca...@gmail.com>

[Ugo Riboni]

> Hey Fernando
> excellent work, I'm delighted to see this. Once we get the code *poke* :),
> we will have to see for what kernel version it is written for (I suspect
> 2.6.4), and then work on porting it to a newer kernel.
> This isn't a substitute for documentation for the DM320, but it should help
> us fix our biggest problem with the OSD1, the crappy USB.
> Thank you for this Fernando!

Yeah, that's good news.
Please dig into these CDs and/or poke as needed, it would be nice
indeed to have that code and see if anyone can use it with the OSD. I
suppose putting out SDIO can be a start, while you get USB as well, no
?

Once the code is integrated into the OSD codebase, it's absolutely no
problem to add Cadenux to the contributors list in the OSD about box,
by the way.

But isn't the Inquirer article a bit premature, given you don't
actually have that code handy and no one has even verified it's
actually useful ?

Thanks,
--
nero

[Joe Born]

But isn't the Inquirer article a bit premature, given you don't
actually have that code handy and no one has even verified it's
actually useful ?

I don't know, these announcements tend to help add to the momentum, get people excited and sometimes help to get things done.

In any case, nice job Fernando, thanks much!

[Fernando Cassia]

On Tue, Jun 2, 2009 at 10:08 AM, Ugo Riboni <neroc...@gmail.com> wrote:

> Hey Fernando
> excellent work, I'm delighted to see this. Once we get the code *poke* :),
> we will have to see for what kernel version it is written for (I suspect
> 2.6.4),

From the release notes...

This is a GPL version of the Cadenux DM320 MMC/SD/SDIO driver.  

1) It is "self contained" meaning it was written before the Linux header files for MMC/SD existed.  There is lots of almost duplication with mmc in the Linux kernel.  To really be done right, the driver should be changed to use the "Linux standard" definitions and routines.  Fortunately, as you will see, the driver has a clean separation between general mmc/sd/sdio concepts and DM320 hardware specifics.

5) This driver should build without much change using 2.6.15 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 

6) There are no known defects in this driver.

 

> This isn't a substitute for documentation for the DM320, but it should help
> us fix our biggest problem with the OSD1, the crappy USB.
> Thank you for this Fernando!

Yeah, that's good news.
Please dig into these CDs and/or poke as needed, it would be nice
indeed to have that code and see if anyone can use it with the OSD. I
suppose putting out SDIO can be a start, while you get USB as well, no
?

Once the code is integrated into the OSD codebase, it's absolutely no
problem to add Cadenux to the contributors list in the OSD about box,
by the way.

I thought so. :)

 

But isn't the Inquirer article a bit premature, given you don't
actually have that code handy and no one has even verified it's
actually useful ?

Well, I was asked by the INQ editor to do one exrta article, and that's what I had in hand, given that I found the CD with the email/files last night.

FC

[Fernando Cassia]

On Tue, Jun 2, 2009 at 5:04 PM, Fernando Cassia <fca...@gmail.com> wrote:

 

But isn't the Inquirer article a bit premature, given you don't
actually have that code handy and no one has even verified it's
actually useful ?

http://sites.google.com/site/dm320usbgpl/binaries

The USB host drivers code should arrive to my Gmail inbox soon, according to the developer.

On the "being actually useful", I don't get what you mean... the guys at Cadenux had a working stack and SOLD this code to customers, he says one customer is still using the SDIO part on the DM320 with Linux 2.6.

It *should* work. And in any case, replacing the USB driver with the Cadenux one + adding the SDIO code will surely give us more functionality than the Ingenient code that only supports USB mass storage.

OK, I did the public relations and email bugigng part, now it's up to any volunteer C/C++ programmers to make a step forward.... either that or I'll make a step backwards. <VBG>

Just my $0.02.

FC

PS: now I better get one SD-Bluetooth card before those disappear....

[bmc]

Fernando,

Nicely done. These will be a great asset for the OSD community!

[bmc]

FC,

I took a look at the MMC/SD files from Cadenux.

They're built against a different set of asm/ and asm/arch/ header
files than the rest of the OSD kernel uses, making a merge/port of
this code rather difficult.

Doing some quick hacks and pulling headers from the Cadenux USB
package to push compilation through turns up other problems, showing
that Cadenux basically had a different BSP package this was built
against: different asm/*.h, asm/arch/*.h, and additional files,
functions and constants that aren't defined anywhere in the two
cadenux file packages you got:

Some of the missing stuff:
file: asm/arch/kal.h
dma_get_phys_addr()
CONFIG_BSP_ARCH_SDRAM_BASE
dm320_kal_add_userspace_device()
different gio_* function implementations

While it's possible to make guesses about to hack into the above
missing pieces, merging/porting this stuff really isn't viable without
all the supporting files from the Cadenux BSP this was built against.
Even then it would be tricky and time consuming...