Harald Welte's blog


Harald's Web




Other Bloggers
David Burgess
Dieter Spaar
Michael Lauer
Stefan Schmidt
Rusty Russell
David Miller
Martin Pool
Jeremy Kerr
Tim Pritlove (German)
fukami (German)
fefe (German)
Bradley M. Kuhn
Lawrence Lessig
Kalyan Varma


Ohloh profile for laforge
Linked in

Creative Commons License
Articles on this blog/journal are licensed under a Creative Commons Attribution-NoDerivs 2.5 License.



Fri, 13 Aug 2010
Wondermedia WM8505 Linux + u-boot source code

In recent months, a number of alleged GPL-violation reports regarding products (tablet computers, mini netbooks and the like) using the Wondermedia WM850x line of ARM SoCs. People have been contacting me, as I was working as VIA Open Source Liaison, and there is the general belief that VIA and Wondermedia Technology (WMT) are one company.

I had investigated this issue even before there were any reports, and I'd like to publicly state that:

  • Wondermedia is a separate company from VIA, with independent management, making their own business decisions. The 850x SoC development was started inside VIA, but is no longer part of VIA for a long time.
  • Any references to VIA in the source code or old data sheets date from that time before the SoC business became part of Wondermedia
  • I have had assurances from Wondermedia, even before there were any allegations, that similar to VIA they explicitly notify their customers about the GPL and always provide their SDK / BSP as full corresponding source code.
  • Effectively, this means that GPLv2 Section "3a" is used. WMT has provided the Linux and u-boot source code to its customers, and thus has no obligation under GPLv2 Section "3b" to provide it to anybody else (any 3rd party)
  • So, if you buy a product including a WMT SoC and u-boot/Linux, like always, GPL compliance of what has been shipped to you has to be assured by the manufacturer of the product, not the semiconductor maker

Notwithstanding all of the above, Wondermedia was willing to provide the Linux kernel and u-boot source code of their SDK to me, so I can share it with the community. As indicated, they're not legally required to do this and I'm happy they do it anyway to show their good intentions.

You can download the released source code from the gpl-devices.org ftp-server, more specifically here are the latest Linux kernel (modified 2.6.29 android derivative) and u-boot source code archives.

This software is provided without any kind of support. If you see some GPL related legal problems (i.e. you believe it is incomplete), don't hesitate to contact me. To the best of my knowledge WMT (basically a small hardware start-up with small software development team) has no resources to actively push any of this mainline.

[ /linux/via | permanent link ]

Tue, 16 Jun 2009
OLPC XO1.5 samples has arrived for VIA driver related work

I've just received one of the few precious XO 1.5 samples, since I'm supposed to be working with Chris Ball and others at OLPC to help them with getting the VIA hardware fully supported, e.g. integrating/testing support for the specific panel, etc.

It seems to be booting fine the current xo-1.5 branch of the OLPC git tree, and the basic operation of all major peripherals is fine. Stuff like power management and support for DCON are still requiring some work, of course.

Today I'm still busy with generic non-OLPC VIA driver related work, but tomorrow I can hopefully look into OLPC related issues.

[ /linux/via | permanent link ]

Sun, 14 Jun 2009
Working on a new VIA graphic chip debug tool

As there are a number of confirmed bug reports with the viafb kernel driver, and I've been working on openchrome VX855 support, as well as OLPC XO1.5 support for viafb as well as openchrome, I've decided to write some better tool for debugging graphics problems.

The userspace tool will dump all the registers (currently only CRT / LVDS / DVI / Sequencer / Power management) and parse them into human-readable form. This way we can set a certain mode or display configuration, and verify what the respective driver[s] have actually done in the hardware.

The idea is to ssh into the respective system and run that tool, even if the actual monitor is no longer showing any userful output.

viafb still needs quite a bit of re-work, I'm not really happy with e.g. how it directly uses the I2C controllers rather than registering proper i2c client drivers. What's also sad is that it doesn't use the common kernel interface for modelines (modedb). Also, there are _way_ too many module parameters. I guess close to nobody but the original authors understand how to set all this correctly.

Since I actually have a CLE266 and CX700 system at home, I'll be able to test any new code or changes on those two as well as VX800 and VX855, which should cover all the major generations of VIA integrated graphics hardware out there.

You can see the early beginnings of that tool at svn.gnumonks.org/trunk/via-chrome-tool. Theres lots of uncommitted code not yet in that repository, will push it tomorrow after I'm back to Germany.

[ /linux/via | permanent link ]

Thu, 11 Jun 2009
Updated via-sdmmc driver submitted to mainline

Today, I've submitted the latest version of the via-sdmmc driver to lkml and Pierre Ossman, the kernel sdmmc maintainer.

Since the last submissin in early april has not received many additional fedback, I hope we can make the 2.6.31 merge window. This has been once again taking way too long. VIA has to improve its turnaround time significantly in the future.

[ /linux/via | permanent link ]

Tue, 09 Jun 2009
Linux kernel cpu_debug support for VIA CPU's

I've recently been hacking on adding cpu_debug support for VIA CPU's to the Linux kernel. The code has today been published in the via-cpudebug branch of my linux-2.6-via git tree, the relevant commit is available here as commitdiff.

cpu_debug allows you to read all existing MSR (machine specific registers) from userspace using a debugfs interface.

Let's hope this code will - among other things - help us to debug any power / thermal management related issuses. I'm now going to be working on a small perl script that can interpret the power/thermal management related MSR values into something human-readable.

[ /linux/via | permanent link ]

Linux kernel hwmon driver for on-die temperature sensor of VIA CPU

Today I've hacked up (and posted) a hwmon driver that prints the current temperature of the digital on-die temperature sensor integrated in VIA's C7 and Nano CPU's.

You can get the code from the via-cputemp branch of my linux-2.6-via git tree. The code is also available as git commitdiff.

Let's hope this is another building stone in debugging any problems related to power management on VIA's CPUs.

[ /linux/via | permanent link ]

Wed, 20 May 2009
Some more VX855 work related to OLPC

Today I wrote a VX855 southbridge GPIO GPIOLIB driver, which is required by the OLPC DCON display controller.

I've also spammed a queue of 15 patches to linux-fbdev-devel, hoping that the majority of the viafb improvements/extensions can go mainline quite quickly.

What the XO1.5 DCON also needs, is a redesign of how viafb drives its multiple internal I2C busses, but this is not ready for submission yet.

Let's hope that this helps OLPC to get Linux up and running very quickly...

[ /linux/via | permanent link ]

Tue, 19 May 2009
VX800/VX855 accelerated kernel framebuffer

I've been working long hours to hunt the remaining bugs in the code, but it's finally working: this branch of my git tree now contains everything needed for having 2D accelerated kernel framebuffer, i.e. fast scrolling console text without much CPU usage :)

On the way to get there, there was a lot of viafb general cleanup - but I'm afraid it is just the tip of the iceberg. There are so many duplicated structure members in the code that it is hard to know which one is supposed to have the current bit of data. But right now I already have 14 pending patches that need to go mainline, I'd rather not start piling up more right now. Maybe after things have settled.

The other odd bit is that on all VX800/VX855 system that I've had access to in the last days, I cannot get the I2C / DDC to work. Not with the kernel code, not with VIA's Xorg driver, and neither with Openchrome. On the other hand, using custom hand-crafted userspace code, I can set (and read) the SDA and SCL lines on the VGA connector and take the correct voltage readings with a multimeter. So my thought was: Maybe it's working slowly, but at faster speeds there's some capacitance/termination problem? Well, even if I slow down the clock rate to 1kHz, I still don't get it working.

[ /linux/via | permanent link ]

Sat, 16 May 2009
VIA Integrated Graphics / VGA De-ja-vue!

Since I'm playing with the kernel framebuffer and openchrome graphics drivers for the VIA integrated graphics chipsets right now, I have a somewhat of a de-ja-vue.

In order to access the GPIO ports that are used for I2C/DDC, you need to use 8-bit I/O read/write to an indexed VGA register. You write the register number to 0x3c4 and you can read/write the actual data from/to 0x3c5.

This remembers me of the 1991 to 1993 time frame, when I was a teenager peeking and poking the registers of my then brand-new VGA card from turbo pascal programs on DOS.

I cannot believe that this kind of legacy is still around, in hardware that is produced 2009 :)

[ /linux/via | permanent link ]

Mon, 11 May 2009
Some VIA VX855 integrated graphics related work

Today I've managed to work on bits and pieces on the minimal support for VX855 graphics such as ensuring the viafb driver works on x86_64 builds as well as a preliminary patch to get VX855 supported by viafb.

I've also played a bit with openchrome and got it to the point where it can display X11 at various resolutions on a CRT (analog VGA out) including hardware accelerated cursor support. The patch is not yet posted, but I hope I'll soon find time to complete this.

[ /linux/via | permanent link ]

Sun, 10 May 2009
Some more testing with the PadLock hardware on VIA Nano CPU

During the last days, I have finished my tests with regard to the hardware crypto part (PadLock) of the VIA Nano CPU. Now my kernel supports hardware rng, aes and sha engines in both x86_64 and x86_32 modes, at least as far as tcrypt and dm-crypt go.

The performance is quite impressive. It seems that AES256 ECB encryption and decryption gets something like 1.3 gigabytes per second with the tcrypt tests. And this is an evaluation board with probably some slow memory and a chipset that is not in its final silicon yet.

I'm not sure what the typical software implementation gets on modern CPU's without hardware crypto, but I'll do some testing by myself soon.

I'm also planning to write some paper about the performance numbers I get, extended with some figures for actual IPsec and dm-crypt workloads.

[ /linux/via | permanent link ]

Fri, 01 May 2009
Will have the honor to assist with OLPC XO1.5 bring-up

As you can see at the XO1.5 bring-up page, I've been invited to helping the various OLPC, Quanta and VIA folks with the bring-up of the XO1.5 board from OLPC.

I'm looking forward to doing some more x86 work. It is a welcome change after my predominantly ARM based work during the last years (Openmoko, OpenPCD, OpenBeacon, OpenEZX, gnufiish, ...).

[ /linux/via | permanent link ]

Fri, 24 Apr 2009
OLPC 1.5 to be using VIA C7-M CPU and chipset / VIA reference documentation

To many of you this might not be new. About a week ago, OLPC announced that they have selected a VIA CPU and integrated graphics chipset for their OLPC 1.5 hardware version.

I was expecting this to happen, not because I am working part-time for VIA or because I had any kind of insider information. As usual, I speak for myself and not for VIA. But for anyone who understands the x86 marketplace it would have been pretty clear. AMD's Geode is aged and slow, and there are not really any successors. Intel's product portfolio has recently become great for small mobile devices, but I would imagine the pricing is probably a bit too high for an extremely-low-cost product like the OLPC. Going for an embedded MIPS or ARM processor would rule out running a [un]popular OS from Redmond, and whether we like it or not OLPC is apparently looking at supporting such a OS, too.

Intel would obviously have been the perfect choice from the FOSS point of view, a lot of open documentation as well as GPL licensed and stable drivers in mainline Linux and X.org. VIA is not quite there yet, but I can assure you the changes are still ongoing.

Some people, most prominently John Gilmore have raised concerns about the lack of any public documentation for neither the C7-M nor the VX855 chipset. This is unfortunately still the case. The CPU data sheets should have been public for quite some time but haven't been due to resource constraints. And the VX855 manual is not yet public, as the silicon is still being verified. But as you can see from the publicly available manuals for the VX800/820 as well as the chrome9 2D and 3D graphics reference manuals (all linked from the OLPC wiki page now), the immediate predecessor of the VX855 already has open documentation, and this will not change for the VX855 either.

So rest assured that the documentation for the VIA chips to be used in the OLPC1.5 will be publicly available. I'll also try to get personally involved in the VIA/OLPC discussions and see what I can do to help both on the technical side, as well as helping with the interaction and mutual understanding of both sides.

[ /linux/via | permanent link ]

Tue, 13 Jan 2009
More VIA related hardware manuals

Just as a quick update: VIA has silently released more hardware manuals about current-generation products at ftp://ftp.vtbridge.org/Docs/. We will try to make this the premier location for all hardware related documents, and will also copy those from linux.via.com.tw as well as those from x.org to that new site.

Once again, if you are working on some Free Software and require certain VIA hardware manuals, please contact me and I'll do my best to make it available.

[ /linux/via | permanent link ]

Wed, 17 Dec 2008
VIA submits SD/MMC driver to mainline kernel

Just a quick note, one more GPL licensed Linux kernel driver from VIA is on its way to get integrated into mainline: The SD/MMC driver.

Sure, there is some minor feedback with requests for code changes here and there, but generally the code looks good, so the journey into mainline could be fast.

Please note that I was not involved in writing the driver or any review. VIA's engineers have done this entirely on their own.

[ /linux/via | permanent link ]

Sat, 22 Nov 2008
VIA and Openchrome; Graphics Programming Manuals

Coinciding with FreedomHEC in Taipei, VIA has announced its cooperation with OpenChrome and releases Graphics Programming Manuals.

This definitely marks a big milestone in VIA's new, much more FOSS friendly Linux support. Not only releasing the source code to VIA's own graphics driver, but actually interoperating with OpenChrome to help to create one future driver base and fight against the fragmentation of the developer and user base.

After all, there's probably no other family of GPU's where there are so many different Linux/Xorg drivers like VIA's. What a terrible waste of R&D resources to reinvent the wheel over and over again. One reason for doing that (VIA's driver being closed source) has disappeared when it was made open source a couple of months ago.

So let's hope that this cooperation will be as successful as possible, and we can have one unified driver codebase with the cumulative features of both individual drivers right now. Once that has been done, we can start to think about helping the result to get into mainline X.org and put the entire history to rest.

I also appreciate and welcome the release of the graphics programming manuals for the two most recent generations of integrated graphics chips. Sure, they are by no means as exhaustive as documentation of major competitors in the GPU market - but then, VIA is a small company and they cannot release documentation which never even existed in the first place. So please accept that VIA is working on releasing the documentation it has, but is unlikely to be able to work on creating additional documentation that doesn't even exist.

There are still some things to be done, though. We still cannot include MPEG/H.263/H.264 hardware acceleration support in the driver due to unresolved legal issues (working on that, don't worry) and there is still no open source 3D support for the Chrome9 core (VX800 chipset). But then, life would be simple if all of those problems would disappear overnight. In any case, I think VIA can now legitimately claim that it is moving in the right direction, that it is not only trying to become a much better 'Free and Open Source Citizen'.

There will be more manuals and code up for release at some point, but please excuse that I simply don't want to speak about the tentative schedule of things that haven't happened yet.

[ /linux/via | permanent link ]

Thu, 11 Sep 2008
Installing Linux on systems that boot from SD card

It seems like boot-from-SD is about to become as standard in the x86 world as boot-from-USB currently is. This is generally good news. Also, the need for OS integration is minimal, as it just uses the usual BIOS ABI on doing disk reads.

However, the initrd's shipped by all distributions don't contain the SDHCI driver, and all the installers that I've seen don't support installation on /dev/mmcblk*

I've now filed bugs for all the major distributions about this issue, and you can find more information at this wiki page on installing Linux on a bootable SD card. Let's hope that the distro's consider this feature important enough to add support to it to their next releases to make sure at the time the users buy this kind of hardware they can install the then-existing versions of those distributions.

[ /linux/via | permanent link ]

Tue, 09 Sep 2008
Updates to VIA HDA Codec driver

The last two days I was busy preparing a patchset with various updates against the linux-2.6/sound/pci/hda/patch_via.c driver for HDA Codecs.

The resulting patchset has now been posted at alsa-devel and I'm waiting for the fallout from that.

The other bit that I'm currently playing is boot-from-SDcard support, apparently a feature that major BIOS vendors have in their new releases and which will become more common with upcoming mainboards and laptop devices, just like boot-from-USB in the past.

[ /linux/via | permanent link ]

Mon, 01 Sep 2008
FAQs to the VIA open source driver

There have been numerous questions regarding the recent open source release of VIA's 2D Xorg driver.

Why did VIA publish yet another driver, rather than improving any of the existing Xorg/openchrome/unichrome drivers?
Because this driver is all but new! It was the base for all the binary-only driver releases that VIA has made (and is still making) for select Linux distributions. So rather than having written a new driver, this is just the disclosure of an existing driver.

One of the commonly asked questions is _why_ not the complete source, including codec acceleration, TV out and 3D was published. I cannot disclose the particular reasons for VIA, sorry. But I can comment on the general reasons on why companies cannot disclose certain source code. As you may have noticed, the situation with regard to the ATI driver e.g. shows certain similarities.... Usually there are some parts of the code, particularly for the 3D driver, which cannot be disclosed due to either

  • parts of the source code are under a proprietary license from a 3rd party
  • parts of the source code refer to technologies (e.g. macrovision) which are subject to very strong NDA's by the licensor, which in turn prohibit the open documentation or distribution in source code form

Will VIA learn to build a community around that new driver? Will there be mailing lists and a public revision control system?
As of now, this is unlikely. Not because VIA doesn't believe in the community, but rather because the disclose of VIA's source now enables everyone involved to look at all the available drivers. Some consensus has to be found on which driver is best to be used as a base for a future Xorg mainline driver, and then the community and VIA can work together on merging bits from other drivers into that base. Creating VIA's own mailing lists (and community) would lead to more fragmentation, rather than unification.

[ /linux/via | permanent link ]

Fri, 29 Aug 2008
VIA releases open source Xorg driver

VIA has just released a open source Xorg driver for their integrated graphics chips on their linux.via.com.tw portal. Here's the actual download link for the source code tarball.

I am very happy to see this! It's one more step that VIA has been working on to improve and show their support for Free Software and Linux.

Please notice that this driver (as opposed to VIA's proprietary binary-only Xorg driver) has no support for 3D, hardware video codec or TV encoder support. Nevertheless, it is a big step ahead.

Of course everyone involved understands that this simple "code drop" is not enough and that it is just the first step for actual 'Free Software integration'. There is a lot to be done to harmonize the current FOSS driver landscape for VIA's graphics products, from the old via driver in the Xorg git tree, over the unichrome and openchrome and now this new driver. Stay tuned!

[ /linux/via | permanent link ]

Sat, 23 Aug 2008
Back to Taipei: More work with VIA.

I've just arrived in Taipei two days ago. I'm looking forward to an exciting four weeks of close work with VIA, talking with various different groups in management as well as actual software engineers.

I can only repeat my earlier statements: It still feels great to be able to play such a substantial role in improving the Free Software interaction of a large chip maker and key player in the PC industry.

Of course being in Taipei also enables me to meet again with former colleagues at OpenMoko. I just returned from a very nice dinner conversation with jserv.

[ /linux/via | permanent link ]

Fri, 01 Aug 2008
Small update on my VIA related work

I know there are many curious readers about what is happening at VIA with regard to Free Software. There are many things that I cannot talk about, but I can still state how excited I am by my new role, and how many (some big, some mall) steps I have managed to make during the short time that I'm working with VIA now.

The last week was mainly talking to various FOSS developers that have written or are maintaining existing Linux drivers for VIA hardware, like Ethernet, I2C, SATA/RAID, AGP, DRM/DRI and others. I have been able to provide hardware reference manuals that some of them have been trying to get their hands on for a long time (even willing to sing and NDA). VIA has also starting to offer reference hardware to selected Linux developers.

I'll be back to Taipei in roughly three weeks (August 21st) and am looking forward to the many interactions with Product Managers and Developers. Meanwhile, I'll continue to have conf calls at weird times and sending tons of emails back and forth, trying to establish the right contacts, getting the right people to talk to each other, etc.

So far I have resisted the temptation to touch a lot of the code. But I think I will not be able to resist very long ;) Right now I just don't want to step onto anyones toes (and/or duplicate work), no matter whether in the community or inside VIA.

[ /linux/via | permanent link ]

Thu, 24 Jul 2008
Becoming VIA Open Source Liaison

Today, VIA made public what I've already been doing behind the scenes for some time: I've been contracted and appointed to be VIA's Open Source Liaison. As first part of the process, they've released the Padlock programming guide and the CX700/VX700 integrated north+southbridge manuals on linux.via.com.tw.

This basically means that I'll be helping VIA with improving their strategy for Open Source support, such as Open Source driver support, merging those drivers into the respective mainline projects as well as working on publicly available reference documentation for their hardware.

This is an incredible chance to contribute my part to help a major manufacturer of CPU, Chipset, Ethernet, WiFi, Card Reader and PC Graphics components understand what it takes to interact properly with the Free Software community. This is a big learning experience for VIA, and a teaching experience on my part, of course. I feel very happy to be able to work in such a key position, and to be able to put all my knowledge about Linux driver development, the development process, the FOSS community values/ethics/practises as well as licensing related knowledge at work.

VIA is truly interested to learn, and they're already doing a lot internally which you might not have been aware about. I am well aware of many of the historic problems between VIA and the community, related to binary only drivers, not cooperating with mainline development, suboptimal press announcements with little action, etc.

I'm very confident that together we can move beyond this and take a fresh start for much better FOSS support of VIA products. Of course the change will not come overnight. It's a process, and it involves many groups in a large company, each group with their own management, R&D and so on. So please bear with us, and don't expect all drivers to be finished in mainline quality tomorrow.

If you are a Free Software developer and you have some comment/feedback/demand to via, please feel free to contact me (preferably at HaraldWelte@viatech.com. I will try my best to follow-up with all those comments. If you are missing some piece of documentation for hardware or have some other issue, please let me know. I do care, and I will take up the issue with VIA's management.

[ /linux/via | permanent link ]