LaForge's home page (Posts about via)https://laforge.gnumonks.org/blog/tags/via.atom2022-06-21T07:49:57ZHarald WelteNikolaWondermedia WM8505 Linux + u-boot source codehttps://laforge.gnumonks.org/blog/20100813-wondermedia_wm8505_source/2010-08-13T03:00:00+02:002010-08-13T03:00:00+02:00Harald Welte<p>
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.
</p>
<p>
I had investigated this issue even before there were any reports, and I'd like
to publicly state that:
</p><ul>
<li>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.</li>
<li>Any references to VIA in the source code or old data sheets date from that
time before the SoC business became part of Wondermedia</li>
<li>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.</li>
<li>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)</li>
<li>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</li>
</ul>
<p>
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.
</p>
<p>
You can download the released source code from <a href="ftp://ftp.gpl-devices.org/pub/vendors/Wondermedia/WM8505/">the gpl-devices.org ftp-server</a>, more specifically here are the latest <a href="ftp://ftp.gpl-devices.org/pub/vendors/Wondermedia/WM8505/linux-2.6.29-android-wmt.tar.bz2">Linux kernel</a> (modified 2.6.29 android derivative) and <a href="ftp://ftp.gpl-devices.org/pub/vendors/Wondermedia/WM8505/u-boot-0.12.01.00.25.tar.bz2">u-boot</a> source code archives.
</p>
<p>
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.
</p>OLPC XO1.5 samples has arrived for VIA driver related workhttps://laforge.gnumonks.org/blog/20090616-olpc_xo15_arrived/2009-06-16T03:00:00+02:002009-06-16T03:00:00+02:00Harald Welte<p>
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.
</p>
<p>
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.
</p>
<p>
Today I'm still busy with generic non-OLPC VIA driver related work, but
tomorrow I can hopefully look into OLPC related issues.
</p>Working on a new VIA graphic chip debug toolhttps://laforge.gnumonks.org/blog/20090614-via_gpu_debug_tool/2009-06-14T03:00:00+02:002009-06-14T03:00:00+02:00Harald Welte<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
You can see the early beginnings of that tool at <a href="http://svn.gnumonks.org/trunk/via-chrome-tool/">svn.gnumonks.org/trunk/via-chrome-tool</a>. Theres lots
of uncommitted code not yet in that repository, will push it tomorrow after I'm
back to Germany.
</p>Updated via-sdmmc driver submitted to mainlinehttps://laforge.gnumonks.org/blog/20090611-via-sdmmc/2009-06-11T03:00:00+02:002009-06-11T03:00:00+02:00Harald Welte<p>
Today, I've <a href="http://article.gmane.org/gmane.linux.kernel/850334">submitted the latest
version of the via-sdmmc driver</a> to lkml and Pierre Ossman, the kernel sdmmc
maintainer.
</p>
<p>
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.
</p>Linux kernel cpu_debug support for VIA CPU'shttps://laforge.gnumonks.org/blog/20090609-via-cpu_debug/2009-06-09T03:00:00+02:002009-06-09T03:00:00+02:00Harald Welte<p>
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 <a href="http://git.gnumonks.org/cgi-bin/gitweb.cgi?p=linux-2.6-via.git;a=commitdiff;h=6808d05b773073995857570fdb1346f177485d3d">available here as commitdiff</a>.
</p>
<p>
cpu_debug allows you to read all existing MSR (machine specific registers) from
userspace using a debugfs interface.
</p>
<p>
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.
</p>Linux kernel hwmon driver for on-die temperature sensor of VIA CPUhttps://laforge.gnumonks.org/blog/20090609-via-cpu-hwmon/2009-06-09T03:00:00+02:002009-06-09T03:00:00+02:00Harald Welte<p>
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.
</p>
<p>
You can get the code from the <i>via-cputemp</i> branch of my linux-2.6-via git
tree. The code is also available as <a href="http://git.gnumonks.org/cgi-bin/gitweb.cgi?p=linux-2.6-via.git;a=commitdiff;h=bb3796c7c8d2209e7c3ab112f32ec4dec63e0d48">git commitdiff</a>.
</p>
<p>
Let's hope this is another building stone in debugging any problems related to
power management on VIA's CPUs.
</p>Some more VX855 work related to OLPChttps://laforge.gnumonks.org/blog/20090520-vx855-gpiolib-i2c/2009-05-20T03:00:00+02:002009-05-20T03:00:00+02:00Harald Welte<p>
Today I wrote <a href="http://dev.laptop.org/git/olpc-2.6/commit/?h=xo-1.5&id=31de651f9aea2e4cecd051ad9e89617fd66cd481">a
VX855 southbridge GPIO GPIOLIB driver</a>, which is required by the OLPC <a href="http://wiki.laptop.org/go/DCON">DCON</a> display controller.
</p>
<p>
I've also <a href="http://marc.info/?l=linux-fbdev-devel&m=124285257009198&w=2">spammed a
queue of 15 patches to linux-fbdev-devel</a>, hoping that the majority of the
viafb improvements/extensions can go mainline quite quickly.
</p>
<p>
What the XO1.5 DCON also needs, is <a href="http://git.gnumonks.org/cgi-bin/gitweb.cgi?p=linux-2.6-via.git;a=shortlog;h=refs/heads/via-viafb-i2c">a redesign of how viafb drives its multiple internal I2C busses</a>, but this is not ready for submission yet.
</p>
<p>
Let's hope that this helps OLPC to get Linux up and running very quickly...
</p>VX800/VX855 accelerated kernel framebufferhttps://laforge.gnumonks.org/blog/20090519-vx855-fb/2009-05-19T03:00:00+02:002009-05-19T03:00:00+02:00Harald Welte<p>
I've been working long hours to hunt the remaining bugs in the code, but
it's finally working: <a href="http://git.gnumonks.org/cgi-bin/gitweb.cgi?p=linux-2.6-via.git;a=shortlog;h=refs/heads/via-viafb-m1_accel">this
branch</a> of my git tree now contains everything needed for having 2D
accelerated kernel framebuffer, i.e. fast scrolling console text without much CPU usage :)
</p>
<p>
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.
</p>
<p>
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.
</p>VIA Integrated Graphics / VGA De-ja-vue!https://laforge.gnumonks.org/blog/20090516-vga_dejavue/2009-05-16T03:00:00+02:002009-05-16T03:00:00+02:00Harald Welte<p>
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.
</p>
<p>
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 <i>indexed</i> VGA register. You write the register number to 0x3c4 and you can read/write the actual data from/to 0x3c5.
</p>
<p>
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.
</p>
<p>
I cannot believe that this kind of legacy is still around, in hardware that is
produced 2009 :)
</p>Some VIA VX855 integrated graphics related workhttps://laforge.gnumonks.org/blog/20090511-vx855-graphicx/2009-05-11T03:00:00+02:002009-05-11T03:00:00+02:00Harald Welte<p>
Today I've managed to work on bits and pieces on the minimal support for VX855 graphics such as <a href="http://sourceforge.net/mailarchive/forum.php?thread_name=20090511102604.GG8192%40prithivi.gnumonks.org&forum_name=linux-fbdev-devel">ensuring the viafb driver works on x86_64 builds</a> as well as <a href="http://sourceforge.net/mailarchive/forum.php?thread_name=20090511165436.GD4163%40prithivi.gnumonks.org&forum_name=linux-fbdev-devel">a preliminary patch to get VX855 supported by viafb</a>.
</p>
<p>
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.
</p>Some more testing with the PadLock hardware on VIA Nano CPUhttps://laforge.gnumonks.org/blog/20090510-padlock_nano/2009-05-10T03:00:00+02:002009-05-10T03:00:00+02:00Harald Welte<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>Will have the honor to assist with OLPC XO1.5 bring-uphttps://laforge.gnumonks.org/blog/20090501-olpc_xo15_bringup/2009-05-01T03:00:00+02:002009-05-01T03:00:00+02:00Harald Welte<p>
As you can see at the <a href="http://wiki.laptop.org/go/XO1.5_Bringup">XO1.5
bring-up page</a>, I've been invited to helping the various OLPC, Quanta and VIA
folks with the bring-up of the XO1.5 board from OLPC.
</p>
<p>
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, ...).
</p>OLPC 1.5 to be using VIA C7-M CPU and chipset / VIA reference documentationhttps://laforge.gnumonks.org/blog/20090424-oplc15/2009-04-24T03:00:00+02:002009-04-24T03:00:00+02:00Harald Welte<p>
To many of you this might not be new. About a week ago, <a href="http://lists.laptop.org/pipermail/devel/2009-April/024127.html">OLPC
announced that they have selected a VIA CPU and integrated graphics chipset for
their OLPC 1.5 hardware version</a>.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>More VIA related hardware manualshttps://laforge.gnumonks.org/blog/20090113-vtbridge/2009-01-13T03:00:00+01:002009-01-13T03:00:00+01:00Harald Welte<p>
Just as a quick update: VIA has silently released more hardware manuals about
current-generation products <a href="ftp://ftp.vtbridge.org/Docs/">at
ftp://ftp.vtbridge.org/Docs/</a>. 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.
</p>
<p>
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.
</p>VIA submits SD/MMC driver to mainline kernelhttps://laforge.gnumonks.org/blog/20081217-sdmmc/2008-12-17T03:00:00+01:002008-12-17T03:00:00+01:00Harald Welte<p>
Just a quick note, one more GPL licensed Linux kernel driver from VIA is on
its way to get integrated into mainline: <a href="http://marc.info/?l=linux-kernel&m=122942777230678&w=2">The SD/MMC driver</a>.
</p>
<p>
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.
</p>
<p>
Please note that I was not involved in writing the driver or any review. VIA's
engineers have done this entirely on their own.
</p>VIA and Openchrome; Graphics Programming Manualshttps://laforge.gnumonks.org/blog/20081122-via-openchrome/2008-11-22T03:00:00+01:002008-11-22T03:00:00+01:00Harald Welte<p>
Coinciding with FreedomHEC in Taipei, <a href="http://www.via.com.tw/en/resources/pressroom/pressrelease.jsp?press_release_no=2887">VIA
has announced its cooperation with OpenChrome and releases Graphics Programming
Manuals</a>.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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'.
</p>
<p>
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.
</p>Installing Linux on systems that boot from SD cardhttps://laforge.gnumonks.org/blog/20080911-b-oot_from_sdcard/2008-09-11T03:00:00+02:002008-09-11T03:00:00+02:00Harald Welte<p>
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.
</p>
<p>
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*
</p>
<p>
I've now filed bugs for all the major distributions about this issue,
and you can find more information at <a href="http://wiki.gpl-devices.org/wiki/Installing_Linux_on_booting_SD_card">this
wiki page on installing Linux on a bootable SD card</a>. 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.
</p>Updates to VIA HDA Codec driverhttps://laforge.gnumonks.org/blog/20080909-via-hda-codec-updates/2008-09-09T03:00:00+02:002008-09-09T03:00:00+02:00Harald Welte<p>
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.
</p>
<p>
The <a href="http://article.gmane.org/gmane.linux.alsa.devel/56102">resulting
patchset has now been posted at alsa-devel</a> and I'm waiting for the fallout
from that.
</p>
<p>
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.
</p>FAQs to the VIA open source driverhttps://laforge.gnumonks.org/blog/20080901-via-xorg-opensource-faq/2008-09-01T03:00:00+02:002008-09-01T03:00:00+02:00Harald Welte<p>
There have been numerous questions regarding the recent open source release of
VIA's 2D Xorg driver.
</p>
<p>
<i>Why did VIA publish yet another driver, rather than improving any of the
existing Xorg/openchrome/unichrome drivers?</i><br>
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.
</p>
<p>
One of the commonly asked questions is <i>_why_ not the complete source, including
codec acceleration, TV out and 3D was published</i>. 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
</p><ul>
<li>parts of the source code are under a proprietary license from a 3rd party</li>
<li>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</li>
</ul>
<p><i>
Will VIA learn to build a community around that new driver? Will there be
mailing lists and a public revision control system?
</i><br>
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.
</p>VIA releases open source Xorg driverhttps://laforge.gnumonks.org/blog/20080829-via-xorg-driver-opensource/2008-08-29T03:00:00+02:002008-08-29T03:00:00+02:00Harald Welte<p>
VIA has just released a open source Xorg driver for their integrated graphics
chips on their <a href="http://linux.via.com.tw/">linux.via.com.tw</a> portal.
Here's the <a href="http://linux.via.com.tw/support/beginDownload.action?eleid=201&fid=301">actual download link</a> for the source code tarball.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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!
</p>Back to Taipei: More work with VIA.https://laforge.gnumonks.org/blog/20080823-back_to_taipei/2008-08-23T03:00:00+02:002008-08-23T03:00:00+02:00Harald Welte<p>
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.
</p>
<p>
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.
</p>
<p>
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 <a href="http://www.advogato.org/person/jserv/">jserv</a>.
</p>Small update on my VIA related workhttps://laforge.gnumonks.org/blog/20080801-small-update/2008-08-01T03:00:00+02:002008-08-01T03:00:00+02:00Harald Welte<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>Becoming VIA Open Source Liaisonhttps://laforge.gnumonks.org/blog/20080724-via_opensource_liaison/2008-07-24T03:00:00+02:002008-07-24T03:00:00+02:00Harald Welte<p>
Today, <a href="http://www.via.com.tw/">VIA</a> made public what I've already
been doing behind the scenes for some time: <a href="http://www.via.com.tw/en/resources/pressroom/pressrelease.jsp?press_release_no=2547">I've been contracted and
appointed to be VIA's Open Source Liaison.</a> As first part of the process,
they've released the Padlock programming guide and the CX700/VX700 integrated
north+southbridge manuals on <a href="http://linux.via.com.tw/">linux.via.com.tw</a>.
</p><p>
</p>
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.
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
If you are a Free Software developer and you have some comment/feedback/demand
to via, please feel free to contact me (preferably at <a href="mailto:HaraldWelte@viatech.com">HaraldWelte@viatech.com</a>. 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.
</p>