WM8850 Kernel

[Tony Prisk]

Might need a little help with this - think it's a bit out of my
understanding.

I tried booting the WM8850 with a slightly modified version of our
kernel (Already confirmed it doesn't boot with an unmodified version).

I changed 'select CPU_ARM926T' to CPU_V7 which seemed right for a Cortex
A9. Also tried CPU_V6 with the same result.

I noticed a few other A9-based platforms used ARM_AMBA but it seems to
have a reliance on clock code which we don't have at the moment.

At the moment, it decompresses the kernel and then hangs.


Console log attached:

textout - show text to the
screen
textout x y "str"
color
color is 24bit Hex, R[23:16], G[15:8],
B[7:0]
for example: textout 0 0 "hello world"
FFFFFF

part_offset : 2000, cur_part :
1
reading /script/uzImage.bin

1870336 bytes
read
## Booting image at
00000000 ...
Image Name: WM8850
Linux
Image Type: ARM Linux Kernel Image
(uncompressed)
Data Size: 1870272 Bytes = 1.8
MB
Load Address:
00008000
Entry Point:
00008000
Verifying Checksum ...
OK
OK

Starting
kernel ...

Uncompressing Linux... done, booting the
kernel.

[Tony Prisk]

Ignore me - I will retry this tomorrow. I haven't enabled tty output for the kernel. :/

Must be friday.

Tony P

[Arnd Bergmann]

On Friday 10 August 2012, Tony Prisk wrote:
>
> Might need a little help with this - think it's a bit out of my
> understanding.
>
> I tried booting the WM8850 with a slightly modified version of our
> kernel (Already confirmed it doesn't boot with an unmodified version).
>
> I changed 'select CPU_ARM926T' to CPU_V7 which seemed right for a Cortex
> A9. Also tried CPU_V6 with the same result.
>
> I noticed a few other A9-based platforms used ARM_AMBA but it seems to
> have a reliance on clock code which we don't have at the moment.
>

Most of the Cortex-A9 chips nowadays use a GIC rather than a homegrown
interrupt controller. If this is the case here, you won't get any
interrupts until you find and initialize the GIC correctly. Also all
the IRQ numbers may have changed.

Arnd

[Tony Prisk]

From the /proc/iomem on my wm8850 i get:

fe140000-fe15ffff : irqs

which translates back to d8140000, the same as previous models so I am
making an assumption that the IC is still the same.
UART0 is on IRQ 32, again the same as previous models.

Still haven't been able to get any output from the kernel with either
console=ttyS0,115200n8 or earlyprintk=serial,uart0,115200

Even with a broken IC controller config, I thought I might see the first
character if the uart registers are correct.

It's always the hardest part debugging problems when you can't get any
output (especially when you don't fully understand what you're doing) :)

Regards

Tony Prisk

[Tony Prisk]

Should mention, I also tried ttyWMT0 after I noticed that our serial
ports are not on ttyS0 :)

Tony P

[Ed Spiridonov]

2012/8/11 Tony Prisk <li...@prisktech.co.nz>:

>
> Even with a broken IC controller config, I thought I might see the first
> character if the uart registers are correct.

uboot initializes framebuffer correctly, so you can write something to
frambuffer memory for debug purposes.
it does not need working interrupt controller or anything else - only
correct memory mapping.

[Arnd Bergmann]

On Friday 10 August 2012, Tony Prisk wrote:
> On Sat, 2012-08-11 at 11:15 +1200, Tony Prisk wrote:

> > From the /proc/iomem on my wm8850 i get:
> >
> > fe140000-fe15ffff : irqs
> >
> > which translates back to d8140000, the same as previous models so I am
> > making an assumption that the IC is still the same.
> > UART0 is on IRQ 32, again the same as previous models.

Ok, good point. There might still be a GIC somewhere in there that
forwards the IRQs from the old interrupt controller, but since they
don't have SMP support on WM8850, you are probably right with your
observation.

> > Still haven't been able to get any output from the kernel with either
> > console=ttyS0,115200n8 or earlyprintk=serial,uart0,115200
> >
> > Even with a broken IC controller config, I thought I might see the first
> > character if the uart registers are correct.
> >
> > It's always the hardest part debugging problems when you can't get any
> > output (especially when you don't fully understand what you're doing) :)
> >
>

> Should mention, I also tried ttyWMT0 after I noticed that our serial
> ports are not on ttyS0 :)

It can take quite a while until even the earlyprintk support is started
in the kernel. There are in fact two other logging services that come
before that:

1. The "uncompress" output from
arch/arm/mach-vt8500/include/mach/uncompress.h
This should be fairly easy to see if it's working, and once it is you
know exactly what the UART address is. This code only gets used
before we jump into the uncompressed kernel.

2. Calling early_write directly: this goes through the printch
function and the code in arch/arm/mach-vt8500/include/mach/debug-macro.S
that is also used by early_console. Once you have the uncompress
code working, you can start adding some calls to printascii very
early in the boot process and see how far you get before a crash.

Arnd

[Alexey Charkov]

2012/8/11 Arnd Bergmann <ar...@arndb.de>:

Tony, just for clarification: have you actually enabled earlyprintk
support in kernel config? Also, does your virtual memory mapping put
the UART at the same virtual address where it used to be in my legacy
code that debug-macro.S relies upon?

Given that you get the "Uncompressing Linux" line printed, your UART
is working fine and still lives at the same physical address as it
used to.

Best,
Alexey

[Tony Prisk]

I believe so - earlyprintk is enabled in kernel hacking.
I have added earlyprintk=serial,uart,115200n8 to my scriptcmd - still no
output. No output.

>
> Given that you get the "Uncompressing Linux" line printed, your UART
> is working fine and still lives at the same physical address as it
> used to.

I have confirmed that I'm getting kernel output from the compressed
kernel. I added a new text string and it printed.
>
> Best,
> Alexey

I'm sure this is probably a silly configuration problem on my part -
will get there eventually I'm sure.

[Tony Prisk]

I can get serial output from this section as confirmed by adding my own
strout()'s.

>
> 2. Calling early_write directly: this goes through the printch
> function and the code in arch/arm/mach-vt8500/include/mach/debug-macro.S
> that is also used by early_console. Once you have the uncompress
> code working, you can start adding some calls to printascii very
> early in the boot process and see how far you get before a crash.
>
> Arnd

I cannot figure out where the kernel 'goes' after leaving
arm/boot/head.S so I'm not sure where to start adding debug strings to
watch out for. Doing some 'googling' as we speak.

Regards

Tony P

[Tony Prisk]

On Sat, 2012-08-11 at 07:41 +0000, Arnd Bergmann wrote:

Narrowed it down a bit - but I'm not sure that where it's stopping is
even doing anything. Has it branch off in another direction somewhere??

I don't have a /init in my bootargs.

Regards

Tony P


Here is the relevant code from init/main.c

static int __init kernel_init(void * unused)
{
/*
* Wait until kthreadd is all set-up.
*/
wait_for_completion(&kthreadd_done);

/* Now the scheduler is fully set up and can do blocking allocations */
gfp_allowed_mask = __GFP_BITS_MASK;
/*
* init can allocate pages on any node
*/
set_mems_allowed(node_states[N_HIGH_MEMORY]);
/*
* init can run on any cpu.
*/
set_cpus_allowed_ptr(current, cpu_all_mask);
cad_pid = task_pid(current);

smp_prepare_cpus(setup_max_cpus);
do_pre_smp_initcalls();
lockup_detector_init();

smp_init();
sched_init_smp();

do_basic_setup();

/* Open the /dev/console on the rootfs, this should never fail */
if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
printk(KERN_WARNING "Warning: unable to open an initial console.\n");

< early_printk prints a message here >

(void) sys_dup(0);
(void) sys_dup(0);
/*
* check if there is an early userspace init. If yes, let it do all
* the work
*/

if (!ramdisk_execute_command)
ramdisk_execute_command = "/init";

if (sys_access((const char __user *) ramdisk_execute_command, 0) != 0)
{
ramdisk_execute_command = NULL;
prepare_namespace();
}
< early_printk doesn't print the message here >

/*
* Ok, we have completed the initial bootup, and
* we're essentially up and running. Get rid of the
* initmem segments and start the user-mode stuff..
*/

init_post();

return 0;
}

[Alexey Charkov]

2012/8/11 Tony Prisk <li...@prisktech.co.nz>:

Can it be the case that your U-boot or device tree pass some
extraneous initramfs argument? Have you actually got any initramfs?

Best,
Alexey

[Tony Prisk]

Have done a bit more research - there isn't actually a boot problem so
to speak. I'm just not getting any printk messages sent to uart.

I replaced some printk messages with early_printk and it appears that it
is getting to a point where it wants a usb to load /root from but its
not plugged in so it stops.

early_printk() is working fine. Replacing instances of printk gives me
the output - just not with printk.

Any obvious problem with
bootargs console=ttyS0,115200n8
??

I also tried console=ttyWMT0,115200n8 but no difference.

I have VIA VT8500 on-chip serial port support and VIA VT8500 serial
console support enabled.

It must be something silly - but I can't see it :\

Tony P

[Tony Prisk]

I can now confirm that this must be a silly config error on my part
somehow.

Plugged in the USB filesystem and it appears to be reading it and
booting. Still can't get any uart output though :/

Is there a way to redirect all printk() to early_printk()? :)

Tony P

[Alexey Charkov]

Have you tried to remove the 'console' argument completely and only include 'earlyprintk' without any further arguments to it (i.e. without =whatever)?

[Tony Prisk]

I haven't - but I will.

I noticed another problem which I missed when porting to devicetree, and
may be related to this problem now.

The serial driver uses pdev->id to set uart->line and as an index to
vt8500_uart_ports[]. When the code was changed to devicetree, ->id
became -1 :)

I have noticed that the serial is being probed, but vt8500_console_setup
is never being called.

I'll keep playing - must be getting closer :)

Tony P

[Tony Prisk]

Hooray - got it working finally. Two problems in the end.

1) I'm an idiot :/ I was replacing scriptcmd on my sdcard, but it was
using wmt_scriptcmd. I didn't discover this until after I got a log out
successfully and noticed it was reporting mem=112M which I was sure I
had removed.

2) Even if I had got it right, the serial driver is broken since
converting to devicetree - due to it using pdev->id. Add it to my list
of things to do :)


Now for the good news (I suppose):

wmt_ge_rops seems to startup fine - whether it works is another
question.
wm8505fb_probe causes a warning/dump in mm/page_alloc.c
__alloc_pages_nodemask()

Fails to allocate the framebuffer and error -12 (ENOMEM).
I'm guessing this is something to do with CMA.

EHCI and UHCI seem to startup fine.


Fingers crossed it shouldn't take toooooo long to get it working without
need serial.

[Tony Prisk]

Quick update.

The driver crash was a simply nomem as reported - enabled CMA and the fault disappeared and the fb was allocated properly. Still no output though - it still hows the android logo on the screen so I assume its not initializing the hardware correctly.

Tony P

On Friday, August 10, 2012 9:42:09 PM UTC+12, Tony Prisk wrote:

[Tony Prisk]

I've managed to get something on the lcd panel finally - but I've had to reuse the framebuffer setup by uboot.

The only code I've changed is removing the dma_alloc and setting phys=0x1c100000 and virt=phys_to_virt(phys)
A bit of tweaking to the display configuration and hooray... pictures.

It seems to be completely ignoring register writes to govrh, and I've had enough so I'm going to bed :)

At the moment, I'm working on the assumption that the apc-io 8750 code we have is the closest match to this chip, so I'll work through the uboot code from via and see if I can get our driver accepting values in govrh.

For my own filekeeping (and sanity next year when I can't remember), my WM8850 tablet seems to have a 800x480x16bit lcd panel.

Tony P

[Tony Prisk]

On Wednesday, September 19, 2012 12:10:38 AM UTC+12, xvlabby wrote:

Hi All!
I have just got my tablet. It has Via VM8850 processor. It works with 3.0.8+ kernel. (I don't know what means the '+' sign). By the way, I would like to compile modules and add to the kernel. For example Ftdi.

I have been searching a log for kernel source, .. etc. I 've tried to compile ( it built), but it did not work. (exec format error)

Have anybody an idea, or source, or something. It will be really helpfull.

Best regards.

xvlabby (hu)

I haven't seen a vendor source release for WM8850 so unless one has come out recently its unlikely whatever you have will support WM8850.

Having said that, most of the WM8850 features seem to be compatible with WM8650 so it shouldn't (hopefully) take too long until we see some progress on WM8850. The biggest hurdle at the moment is the framebuffer/display driver.

Regards

Tony P

[Tony Prisk]

On Mon, 2012-10-29 at 15:37 -0700, peter...@gmail.com wrote:
> Hello everyone,
> I've recently bought a little netbook with WM8850 and I've already
> spent some time playing with it. I'm connected to the serial console,
> so I have full access to the bootloader. I've managed to put together
> a simple archlinux image with initrd on the android kernel (3.0.8+).
> It boots fine into the serial console, with working network and
> everything, even wifi seems to be working with modules from original
> android. Main problem is I have no access to the display, the
> framebuffer devices just don't work. I can see both /dev/fb0
> and /dev/fb1, fbset shows correct values, but whenever I try to start
> X server with fbdev driver on /dev/fb0, display just lights up and
> then gets dark slowly, no trace of any picture, and I get a crash dump
> from the kernel in console. I probably have to initialize something,
> but I have no idea what. Android kernel modifications are not my
> strongest point... even hexdumping the /dev/input/eventX devices
> produces similar crash dumps in console, though the same hexdump works
> when I boot original android system with the same kernel. Any ideas
> what could be wrong? I'll produce the boot logs from both original
> android system and my archlinux in a day or two, I can put them here
> if anyone's interested.
> Btw. I can boot any custom system quickly from SD card, so if anyone
> needs to test anything just let me know ;-)
> Regards,
> Peter
>
This is exactly the problem I get when I try to initialize the
framebuffer with our custom framebuffer driver. It just doesn't seem to
like being reinitialized - unfortunately I still haven't found a cause
or fix for this. If this could be figured out, we could add WM8850 to
mainline as well.

Regards
Tony P

[Tony Prisk]

On Thu, 2012-11-01 at 17:12 -0700, peter...@gmail.com wrote:
> Short update: after a "little" tweaking of vanilla 3.0.8 kernel I've
> managed to build tun.ko loadable in the stock android kernel (Linux
> version 3.0.8+ (reilienchen@szmce14) (gcc version 4.5.2 (Sourcery G++
> Lite 2011.03-41) ) #1 Wed Aug 1 18:40:11 HKT 2012). I'm quite
> confident I can build any module from vanilla kernel, the question is
> if hardware drivers (like usb wifi adapters) would actually work...
> I'll have to try it later with some usb wifi-n dongles. There's still
> a problem with built-in wifi in my archlinux build, some kind of
> conflict with evdev, or something. I could build a new driver module,
> but I'll have to find a way to control GPIO first, as the built-in
> adapter is turned off by default (not even seen by lsusb). I can see
> stock module switching some gpio in android, I suppose it's
> wmt.gpo.wlan in uboot properties. Perhaps if I could turn it on
> manually, I could get default linux driver for rtl8192cu to work.
> Problem is I don't know how to talk to /dev/wmtgpio device yet,
> sources from apc-wm8750 are apparently not compatible. I've tried to
> attach strace to some system processes in android yesterday to find
> out what's it doing to switch GPIOs, and the response was "operation
> not permitted" even though I was root. Will have to look into that,
> perhaps the problem was running strace in chroot...
> One question, Tony - is your modified kernel for WM8850 available for
> download somewhere? I'd like to try it out ;-)
>
I didn't bother posting it because I didn't want to deal with a stream
of "my display doesn't work" emails :)

There is not much involved in converting mainline 3.7 to run on wm8850.
In arch/arm/Kconfig, find:

config ARCH_VT8500
bool "VIA/WonderMedia 85xx"
...
select CPU_ARM926T
...

and replace with:

config ARCH_VT8500
bool "VIA/WonderMedia 85xx"
...
select CPU_ARMv7
...


You will also need to create a boardfile (arch/arm/boot/dts/) for the
wm8850. You can actually use the wm8650.dtsi/wm8650-mid.dts files as
they seem to be compatible with wm8850 (although some devices might not
work - I didn't really test everything).

Regards
Tony P

[Alexey Charkov]

2012/11/6 <peter...@gmail.com>
>
> Uff, it's been a long time since my last kernel development :-) Took me some time and a few different cross compilers to finally find out the CPU_ARMv7 change should really be CPU_V7... Anyway, now I have an arm-linux-gnueabihf- 4.7.2 Linaro toolchain and I managed to compile the kernel. I had to include "select MIGHT_HAVE_PCI" into ARCH_VT8500 section of arch/arm/Kbuild and activate PCI in Bus Types to be able to add correct ethernet driver (VIA Rhine III), which probably screwed the USB system a bit. I don't know what it looks like on your tablet, but my netbook actually has USB hubs on PCI:
>
> root@minibook1:/boot# lspci
> 00:01.0 IDE interface: VIA Technologies, Inc. Device 1359
> 00:02.0 Ethernet controller: VIA Technologies, Inc. VT6105/VT6106S [Rhine-III] (rev 84)
> 00:04.0 USB controller: VIA Technologies, Inc. USB 2.0 (rev 90)
> 00:05.0 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 90)
> 00:06.0 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 90)

WonderMedia's kernels actually emulate a virtual PCI bus to be able to
use PCI drivers with actual platform devices without modification. We
haven't seen any evidence of 'real' PCI in our systems. You don't need
to enable PCI to get USB to work. Ethernet just requires changes to
the driver to make it platform-ready.

Best,
Alexey

>
> However, by activating PCI I got a compile conflict:
>
> In file included from drivers/usb/host/ehci-hcd.c:1278:0:
> drivers/usb/host/ehci-vt8500.c:22:12: error: redefinition of 'ehci_update_device'
> In file included from drivers/usb/host/ehci-hcd.c:1203:0:
> drivers/usb/host/ehci-pci.c:383:12: note: previous definition of 'ehci_update_device' was here
> drivers/usb/host/ehci-hcd.c:1339:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
> drivers/usb/host/ehci-hcd.c:1279:0: note: this is the location of the previous definition
> In file included from drivers/usb/host/ehci-hcd.c:1278:0:
> drivers/usb/host/ehci-vt8500.c:159:31: warning: 'vt8500_ehci_driver' defined but not used [-Wunused-variable]
>
> Basically, in drivers/usb/host/ehci-hcd.c both CONFIG_ARCH_VT8500 and CONFIG_PCI included their respective ehci-XXX.c files. As my root hubs are on PCI, I've commented out the VT8500-specific ehci include. That allowed kernel to compile, let's see what it does in runtime.
> I have the kernel and modules ready, will test it later tonight when I get home.
> Regards,
> Peter

[Tony Prisk]

On Tue, 2012-11-06 at 14:33 -0800, peter...@gmail.com wrote:
> Hm, apparently I have a bigger problem. Whatever I tried, I simply
> can't make my uboot to pass flat_dt image address to the
> kernel :-( That's why it can't identify machine ID - it tries standard
> ID comparison, while the kernel is built for device tree compatibility
> check.
> Here's what I've done in uboot:
>
>
> WMT # tftpboot 0 uzImage
>
>
> TFTP from server 10.168.11.78; our IP address is 10.168.11.91
> Filename 'uzImage'.
> Load address: 0x0
> done
>
> Bytes transferred = 2240936 (2231a8 hex)
> WMT # tftpboot 0x03900000 flat_dt.img
>
>
> TFTP from server 10.168.11.78; our IP address is 10.168.11.91
> Filename 'flat_dt.img'.
> Load address: 0x3900000
> done
>
> Bytes transferred = 3059 (bf3 hex)
> WMT # tftpboot 0x04000000 initrd.img
>
>
> TFTP from server 10.168.11.78; our IP address is 10.168.11.91
> Filename 'initrd.img'.
> Load address: 0x4000000
> done
>
> Bytes transferred = 7412202 (7119ea hex)
> WMT # bootm 0 0x04000000 0x03900000

> ## Booting image at 00000000 ...

> Image Name: linux-3.7-rc3+

> Image Type: ARM Linux Kernel Image (uncompressed)

> Data Size: 2240872 Bytes = 2.1 MB

> Load Address: 00008000
> Entry Point: 00008000
> Verifying Checksum ... OK
> OK

> ## Loading Ramdisk Image at 04000000 ...
> Image Name: initrd
> Image Type: ARM Linux RAMDisk Image (gzip compressed)
> Data Size: 7412138 Bytes = 7.1 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK

>
>
> Starting kernel ...
>
>
> Uncompressing Linux... done, booting the kernel.
>
>

> Error: unrecognized/unsupported machine ID (r1 = 0x000002d8).
>
>
> Available machine support:
>
>
> ID (hex) NAME
> ffffffff VIA/Wondermedia SoC (Device Tree Support)
>
>
> Please check your kernel config and/or bootloader.
>
>
> It looks like uboot didn't even register the third image, even though
> it was a flat_dt type created with mkimage. I even tried raw dtb file,
> or uboot image with ramdisk type... doesn't matter what I write after
> bootm command, it seems only to consider first 2 arguments. printenv
> says "ver=U-Boot 1.1.4 (Aug 2 2012 - 10:19:57)", so it should be
> pretty recent one. Could the vendor have removed that functionality??
> Or am I screwing something up?

Its quite possibly that CONFIG_OF_LIBFDT and/or CONFIG_OF_BOARD_SETUP or
missing from the uboot build, specially since WMT didn't need FDT
support :)

You could test some of the fdt related commands in the uboot console and
see if it works.

Regards
Tony P

[Alexey Charkov]

2012/11/7 Tony Prisk <li...@prisktech.co.nz>:

I'm fairly sure that WMT u-boot does not support fdt, just because
it's in fact really old (in terms of u-boot codebase). I suggest
simply using the "Append dtb to zimage" method as per Tony's
instructions on Sourceforge before we get to a point of porting a
fresh bootloader to our hardware.

Best,
Alexey

[Peter Vasil]

Hi, thanks for info :-) You're right, there's really no fdt support in my uboot, I haven't found any fdt related commands. Too bad. At least the append to zimage method seems to work, device tree has been loaded. I forgot to set bootargs variable, so the kernel got stuck with no serial console. I have no way yet to reboot it remotely, any further experiments will have to wait till tonight...

Btw. I figured out how to access GPIO with stock android kernel (/dev/mem rulez!) and I've got WIFI driver working in archlinux, also my custom built fbcon module works with stock kernel, so I have standard consoles on the display - alt-fX switching works, scrollback works, 8x16 font only, and no cursor of any kind although I've tried pretty much all the tweaks I could think of :-(

One drawback is my custom tun.ko module crashes whenever openvpn attempts to create new tun device, stack trace shows something about net_device_name ... I suppose the differences between stock and vanilla kernel are too much.

Even without VPN the netbook is pretty much usable now with wifi, consoles and X server running.

BR,

Peter

[J T Dsouza]

On Wed, Nov 7, 2012 at 1:18 PM, Peter Vasil <peter...@gmail.com> wrote:
> Hi, thanks for info :-) You're right, there's really no fdt support in my
> uboot, I haven't found any fdt related commands. Too bad. At least the
> append to zimage method seems to work, device tree has been loaded. I forgot
> to set bootargs variable, so the kernel got stuck with no serial console. I
> have no way yet to reboot it remotely, any further experiments will have to
> wait till tonight...
> Btw. I figured out how to access GPIO with stock android kernel (/dev/mem
> rulez!) and I've got WIFI driver working in archlinux,

Could you provide details of what you did?
I have had no luck with rt3070sta module, nor with other usb dongles.

> also my custom built
> fbcon module works with stock kernel, so I have standard consoles on the
> display - alt-fX switching works, scrollback works, 8x16 font only, and no
> cursor of any kind although I've tried pretty much all the tweaks I could
> think of :-(

With 3.0.6+ and Tony's append method cursor is displayed ok.

To solve my shutdown problem I used a spare pin on a cp2101
usbtoserial and some c to do a graceful shutdown.

[Peter Vasil]

Hi

Just a reminder - these experiments have been done on the stock 3.0.8+ kernel with no modifications. I just extracted full symbol version table from it and hacked correct versions to the vanilla 3.0.8 kernel, to build custom loadable modules for stock kernel. That's also the most probable reason tun.ko doesn't work correctly - it's too incompatible with the kernel itself and crashes when it tries to call other kernel functions. I suspect that's also the reason for missing cursor in fbcon - I've just built and loaded 4 new modules (bitblit, font, softcursor and fbcon), and apparently they're not compatible enough with the kernel to make cursor work (could be missing TILEBLITTING setting in the stock kernel, but honestly no idea).

As for the wifi, that is a very interesting question. I'm not quite sure why it's working now, so I'll try to describe the whole process :-) Built-in adapter is RTL8188CU, at least according to lsusb when the controlling GPIO is active. Original stock module rt3070sta-rtl8188 loaded successfully since the beginning, but displayed some error messages. It almost looked like it tried to initialize the device more than once, though I have no idea why would it do that. However, it was somehow in conflict with evdev drivers and the kernel crashed on any access to /dev/input/eventX devices. I've built the driver for rtl8188cu from vanilla 3.0.8 kernel, it loaded ok and didn't fight with evdev, but didn't activate GPIO to turn the built-in wifi on (stock module did that internally, I could see it in dmesg). Without that the adapter wasn't even visible on USB bus. I've tried an external USB dongle (some ralink rl28xx-something) with vanilla module but that crashed on adapter initialisation - I suppose the network subsystem in stock android kernel is too different from vanilla 3.0.8 for any custom-built network modules to work :-( After that I played with GPIO, made a small program that maps /dev/mem and can control GPIO (took the code from wm8505 uboot). With that I was able to turn on the builtin wifi and see it register itself on the usb bus, but like external ralink this custom module also crashed on initialisation, I suspect when it tried to register wlan0/ra0 interface. I've played with it a bit without success, and just for comparison I also tried to load the stock rt3070sta-rtl8188 module - and suddenly there was no conflict with evdev!! Beats me why. Perhaps I've changed something seemingly unrelated since than, but I really can't recall anything besides finally getting archlinux initramfs to work with some hacks, and perhaps installing LXDE and networkmanager. I can give you the gpio controller code and my full configuration (or even full SD card image ;-) ) if you're interested, but I really can't point out exact reason why the wifi is suddenly working.

[Peter Vasil]

Sorry, I forgot to ask - what exactly did you do with that spare pin? Is there some pin on the tablet board where I can cause a CPU reset, or something? Or did you just connect a pull-down to the existing reset button?

What I really need isn't particularly graceful ;-) right now the kernel is stuck somewhere in early boot phase, so I basically need a hardware system reset, or power disconnect or something similar...

On Wed, Nov 7, 2012 at 9:54 AM, J T Dsouza <jtd...@gmail.com> wrote:

[J T Dsouza]

On Wed, Nov 7, 2012 at 3:51 PM, Peter Vasil <peter...@gmail.com> wrote:
> Sorry, I forgot to ask - what exactly did you do with that spare pin? Is
> there some pin on the tablet board where I can cause a CPU reset, or
> something?

The "spare pin" is RI (ring indicator ) on a cp2102 usb to serial
dongle. Not a spare pin of the WM8650 SOC.

> Or did you just connect a pull-down to the existing reset button?

The existing reset button which sits between the power socket and the
sound socket on my board is hardwired. Pressing that will always reset
the SOC

[J T Dsouza]

That would be most useful.

[Peter Vasil]

:-D Yes I understood that. My question was, what did you do with that spare cp2102 pin? Where on the tablet have you connected it?

As to the button, on my board it's of course in a completely different place (it's a netbook after all), I'll get some pictures later this week and post them somewhere. But to the point - such buttons are usually wired as pull-downs, meaning when they're not pressed their input pin is connected to Vcc through a resistor (quite large one, >5K usually) making the pin read logical 1, and pressing them shorts that input pin to ground, changing input to logical 0. So, one possible way to implement remote hardware reset would be connecting a parallel controllable pull-down to that pin, that could short the input to ground electronically. Like, you could connect your spare pin on cp2102 to that pin on the board (or to the correct contact on the button, or anywhere in that net) - normally the pin would be high (1) or hi-z (disconnected, if possible on cp2102), but you could set it to 0 for a moment, emulating the button press and resetting the system. It would also keep the button itself working as usual. At least that's what I'm considering, though I'll have to check for the right place to hack into.

Well, that was long, and quite beside the point :-D

I'll try to simplify my android-kernel-archlinux boot configuration tonight as much as possible with wifi still working, and I'll send you what I have.

BR,

Peter

[J T Dsouza]

On Wed, Nov 7, 2012 at 6:52 PM, Peter Vasil <peter...@gmail.com> wrote:
> :-D Yes I understood that. My question was, what did you do with that spare cp2102 pin?

The cp2102 is hooked to the usb. A little c program monitors that pin.
The pin is controlled by another atmel microcontroller which runs on a
cr2032 battery and monitors several i/o connected to it. when it wants
the 8650 to halt it pulls RI low.

>Where on the tablet have you connected it?
> As to the button, on my board it's of course in a completely different place
> (it's a netbook after all), I'll get some pictures later this week and post
> them somewhere. But to the point - such buttons are usually wired as
> pull-downs, meaning when they're not pressed their input pin is connected to
> Vcc through a resistor (quite large one, >5K usually) making the pin read
> logical 1, and pressing them shorts that input pin to ground, changing input
> to logical 0. So, one possible way to implement remote hardware reset would
> be connecting a parallel controllable pull-down to that pin, that could
> short the input to ground electronically. Like, you could connect your spare
> pin on cp2102 to that pin on the board (or to the correct contact on the
> button, or anywhere in that net) - normally the pin would be high (1) or
> hi-z (disconnected, if possible on cp2102), but you could set it to 0 for a
> moment, emulating the button press and resetting the system. It would also
> keep the button itself working as usual. At least that's what I'm
> considering, though I'll have to check for the right place to hack into.

In my case I need an orderly shutdown, hence the RI pin of cp21012 etc.
The microcontroller also connects to the power pin and turns the 8650
on when required by pulling the power-switch low. Or if inevitable a
forced shutdown by pulling powerswitch low for 3 secs, if the micon
does not receive a keepalive when 8650 power led also wired to micon
says it is on etc etc.
My board is a tablet board.

Also the ttyWMT0 is working and is perfectly useable with some
external device. It also seems that ttyWMT1 is functional, except I
dont know where the pins are. There is an unmounted smt connector
where the ttyWMT0 signals are present along with several other tracks.
will check if one of these is ttyWMT1.

[Peter Vasil]

Ahha, that's a bit more complicated solution than I had in mind :-) I'm not sure I would fit another MCU board in the netbook case, it was quite enough to put the usb/uart converter inside (my board's usb connector is charging-only, there was no other way to get in than ttyS0).

Anyway, here's my configuration... I have stock kernel with most modules from android /system/modules directory (I think), like I said the only working custom ones are bitblit, font, softcursor and fbcon for display console. I deactivated initrd completely, bootscript now looks like this:

display init force

textout -1 -1 \"Booting from SD card ...\" FFFF00

echo "Booting from SD card ..."

mmcinit 0

fatload mmc 0 0 uzImage

setenv bootargs mem=${memtotal} root=/dev/mmcblk0p2 rw init=/sbin/init console=ttyS0,115200n8

bootm 0

It's stored on /dev/mmcblk0p1 (vfat) in /FirmwareInstall/autorun.1.wmt with uboot script header. I think the location depends on specific bootloader. uzImage was just grabbed from android boot partition. /dev/mmcblk0p2 is ext4 with standard archlinuxarm rootfs, I think this one http://us.mirror.archlinuxarm.org/os/ArchLinuxARM-imx6-latest.tar.gz, nothing special about it (/dev/mmcblk0p1 is mounted in /boot). This is in /etc/modules-load.d/00-init.conf:

mali

g-wmt-lock

g-wmt-vd-jdec

g-wmt-vd-mpeg2

g-wmt-vd-mpeg4

g-wmt-vd-divx

g-wmt-vd-h263

g-wmt-vd-h264

g-wmt-vd-vc1

g-wmt-vd-vpx

g-wmt-ve-h264

g-wmt-v4l2-cmos

g-wmt-cmoscam

fbcon

cdc-acm

option

g-crypto

rt3070sta-rtl8188

(tun used to be the last one, but it's still crashing with __bug in register_netdevice call)

This is memgpio.c, built directly on device:

#include <stdlib.h>

#include <unistd.h>

#include <stdio.h>

#include <fcntl.h>

#include <sys/mman.h>

#include <sys/ioctl.h>

#define GPIO_BASE 0xd8110000

int main(int argc, char **argv) {

    int i;

    int memfd = 0;

    unsigned int *memp = 0;

    int value,bit,ctl,oc,od;

    if (argc != 6) {

        printf("Usage: memgpio <value> <bit> <ctl> <oc> <od>\n");

        exit(1);

    }

    value = atoi(argv[1]);

    bit = atoi(argv[2]);

    ctl = strtol(argv[3], NULL, 16);

    oc  = strtol(argv[4], NULL, 16);

    od  = strtol(argv[5], NULL, 16);

    bit = 1 << bit;

    ctl >>= 2;

    oc  >>= 2;

    od  >>= 2;

    // Open the file for reading and writing

    memfd = open("/dev/mem", O_RDWR);

    if (memfd == -1) {

        perror("Error: cannot open memory device");

        exit(1);

    }

    // Map the device to memory

    memp = (unsigned int *)mmap(0, 0x10000, PROT_READ | PROT_WRITE, MAP_SHARED, memfd, 0xd8110000);

    if ((int)memp == -1) {

        perror("Error: failed to map memory device to memory");

        exit(4);

    }

    memp[ctl] |= bit;

    memp[oc]  |= bit;

    if (value) memp[od] |= bit;

    else memp[od] &= (~bit);

    munmap(memp, 0x10000);

    close(memfd);

    return 0;

}

It's used by gpiowifi.sh:

#!/bin/sh

./memgpio $1 6 40 80 c0

Usage is pretty straightforward, ./gpiowifi.sh 0|1 ;-) However I don't use it currently, as the android wifi module turns the adapter on/off automatically on load/unload.

My rootfs has currently over 2GB, if you want it I'll have to find some place to upload it.

Btw. is anyone here good in kernel network development? tun module crashlog looks like this:

[  320.512620] Backtrace: 

[  320.515065] [<c003de30>] (__bug+0x0/0x30) from [<c0486db0>] (register_netdevice+0x224/0x244)

[  320.523470] [<c0486b8c>] (register_netdevice+0x0/0x244) from [<bf189498>] (tun_chr_ioctl+0xa5c/0xbf4 [tun])

[  320.533161]  r6:f49b8f80 r5:be89922c r4:00000000 r3:000005dc

[  320.538806] [<bf188a3c>] (tun_chr_ioctl+0x0/0xbf4 [tun]) from [<c00d4f28>] (do_vfs_ioctl+0x88/0x50c)

[  320.547900] [<c00d4ea0>] (do_vfs_ioctl+0x0/0x50c) from [<c00d53ec>] (sys_ioctl+0x40/0x68)

[  320.556041]  r9:f3700000 r8:c003a844 r7:00000003 r6:400454ca r5:be89922c

[  320.562541] r4:f49b8f80

[  320.565153] [<c00d53ac>] (sys_ioctl+0x0/0x68) from [<c003a6c0>] (ret_fast_syscall+0x0/0x30)

[  320.573461]  r7:00000036 r6:be899e08 r5:0007e648 r4:008f1c30

[  320.579098] Code: e34c006a e1a0100c eb15cc64 e3a03000 (e5833000) 

I've checked vanilla 3.0.8 sources, found register_netdevice in net/core/dev.c, there are 3 suspicious lines:

BUG_ON(dev_boot_phase);

...

BUG_ON(dev->reg_state != NETREG_UNINITIALIZED);

BUG_ON(!net);

No idea which one actually crashes... if any at all, as all these lines are at the start of the function, and +0x224/0x244 would hint at somewhere towards the end. Any ideas?

BR,

Peter

[J T Dsouza]

On Thu, Nov 8, 2012 at 1:38 AM, Peter Vasil <peter...@gmail.com> wrote:
> Ahha, that's a bit more complicated solution than I had in mind :-) I'm not
> sure I would fit another MCU board in the netbook case, it was quite enough

My board minus the LCD is mounted in a remote hostile environment
50Mtr underground ;-).

> to put the usb/uart converter inside (my board's usb connector is
> charging-only, there was no other way to get in than ttyS0).
> Anyway, here's my configuration... I have stock kernel with most modules
> from android /system/modules directory (I think), like I said the only
> working custom ones are bitblit, font, softcursor and fbcon for display
> console. I deactivated initrd completely, bootscript now looks like this:
>
> display init force
> textout -1 -1 \"Booting from SD card ...\" FFFF00
> echo "Booting from SD card ..."
> mmcinit 0
> fatload mmc 0 0 uzImage
> setenv bootargs mem=${memtotal} root=/dev/mmcblk0p2 rw init=/sbin/init
> console=ttyS0,115200n8
> bootm 0
>
> It's stored on /dev/mmcblk0p1 (vfat) in /FirmwareInstall/autorun.1.wmt with
> uboot script header. I think the location depends on specific bootloader.
> uzImage was just grabbed from android boot partition. /dev/mmcblk0p2 is ext4

Aha. The stock android kernel extracted from flash works on my board
with everything fully functional. That is linux 2.6.32-9

The problem is with 3.0.6+ a tarball of which Tony was kind enough to
provide. This one is running on a debian sqeeze rootfs.

Thanks for this. Will try and use it.

[Tony Prisk]

On Thu, 2012-11-08 at 02:20 -0800, peter...@gmail.com wrote:
> Thanks for info, with append to zImage I have now booted the 3.7-rc3
> kernel with single modification (CPU_V7 for ARCH_VT8500) on archlinux
> rootfs. I couldn't get linuxwmt (3.7-rc1) from sourceforge to work,
> kernel started but couldn't initialize USB devices. Host system seemed
> to initialize:
>
3.7-rc1 has broken USB. Fixed in RC2 :)

Regards

Tony P

[Alexey Charkov]

Hi Peter!

It's great that you are investigating these, more eyes are always better, and definitely welcome!

Regarding your USB problems, I'm very suspicious that it might be related to IRQ. Have you had chance to cross-check your dts file vs. /proc/interrupts under the stock kernel?

Best,
Alexey

On Nov 12, 2012 2:00 PM, <peter...@gmail.com> wrote:

Time for another update :-) Didn't have as much time over the weekend as I'd like to, but I still checked out a few things. Archlinux on stock android 3.0.8 kernel has a pretty critical flaw - the wifi adapter apparently turns off the radio whenever external power adapter is disconnected. I haven't found any way to control it so far, I don't even know if it's done by hardware or by the stock driver module. If it's done by hardware there could be the same problem for driver module in 3.7, that would somehow have to keep the radio on while on battery power. Well, with this problem the netbook is quite useless with stock kernel, as mobility is pretty much it's only positive :-(

3.7-rc3 kernel still has a problem with USB2 speed I've already mentioned. It's a real pain, just to boot the system takes som 10-12 minutes.

Built-in wifi doesn't work at all, even if I turn on the controlling GPIO, I can't see any changes on USB bus. I don't know if the problem is in wifi initialization (something else needs to be done beside the GPIO?) or in the USB system (which is far from perfect anyway).

I've connected external USB WIFI dongle (some ralink rt2800), this gets detected on the USB2 bus, driver module loads fine (although terribly slowly) and I can see wlan0. "iw" tool can see it and also control it partially (I could see my 11g wlan on scan, but not the 11n one, though the adapter is 150Mbps 11n). Funny thing is iwconfig/iwlist don't report it as wifi at all... I could not establish a wifi connection, it always failed somewhere in wpa_supplicant. I can supply the debug log from supplicant if anyone's interested, I haven't been able to pinpoint the exact problem myself. Perhaps the faulty USB2 bus screws up somehow?

As for framebuffer, apparently it doesn't work as easily as with stock kernel. I have a test program that just checks /dev/fb0 with some ioctls (simple screensize/bpp detection) and then mmaps framebuffer memory and tries to write some pixels. On stock 3.0.8 kernel this works just fine, draws a rectangle over anything on screen. In 3.7-rc3 I can't see anything at all. Maybe some additional initialization is required, haven't yet got time to look into it.

Regards,

Peter

[Alexey Charkov]

2012/11/12 <peter...@gmail.com>:
> Hi, thanks for info, irqs didn't even occur to me yet. I've checked it,
> apparently some of them were wrong in the dts.
> Here's stock kernel /proc/interrupts:
>>
>> CPU0
>> 7: 0 normal i2c2
>> 10: 3416 normal eth0
>> 17: 0 normal dma
>> 18: 0 normal i2c1
>> 19: 0 normal i2c0
>> 20: 41142 normal sdmmc
>> 21: 19237 normal sdmmc
>> 22: 0 normal pmc
>> 26: 2646 normal ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3,
>> wmotgdev
>> 27: 0 normal dma
>> 28: 331 normal NFC
>> 29: 504 normal NFC
>> 32: 7165 normal uart0
>> 34: 0 normal dma
>> 37: 3559623 normal timer
>> 40: 0 normal dma
>> 41: 0 normal dma
>> 45: 0 normal dma
>> 46: 0 normal dma
>> 51: 0 normal dma
>> 55: 0 normal rmtctl
>> 64: 0 normal jdec
>> 68: 0 normal scl
>> 79: 888568 normal vpp
>> 81: 0 normal govw
>> 82: 0 normal govm
>> 83: 0 normal ge
>> 87: 0 normal wmt-h264enc
>> 88: 0 normal vpx
>> 90: 0 normal mali_mmu_irq_handlers
>> 92: 0 normal dma
>> 93: 0 normal dma
>> 94: 0 normal dma
>> 95: 0 normal dma
>> 96: 0 normal dma
>> 97: 0 normal dma
>> 98: 0 normal dma
>> 99: 0 normal dma
>> 100: 0 normal mali_gp_irq_handlers
>> 101: 0 normal mali_mmu_irq_handlers
>> 102: 0 normal mali_pp_irq_handlers
>> 104: 0 normal cec
>> 107: 0 normal govr2
>> 111: 0 normal govr
>> 113: 0 normal vpu
>> 115: 0 normal hdmi cp
>> 116: 0 normal hdmi plug
>> 117: 0 normal hdmi plug
>> Err: 0
>
>
> Now to interrupts in dts - first there is a whole list of them in intc1:
> interrupts = <56 57 58 59 60 61 62 63> but none of those is mentioned in
> /proc/interrupts, so I've left them be for now. Then there was timer:
> interrupts = <36>, I've changed that to <37> according to stock kernel (with
> original <36> value the kernel booted, but there have been 2 div-by-zero
> errors in dmesg log, I thought this might eliminate them). EHCI and UHCI
> were wrong too (<43>), changed those to <26>. Kernel didn't come up at all
> :-( Last message in console is "Calibrating delay loop...", there's no
> kernel panic or anything, so basically the machine is stuck until I get to
> it and reboot it physically, which will be in about 6 hours... I'll try to
> set timer back to <36>, that should let it boot (with those 2 errors I
> expect), then I can try if EHCI works better with new IRQ.
> Any ideas why the delay loop calibration fails?

That's precisely it. Calibrating delay loop is basically matching the
kernel's simplest timing mechanism (int loop = DESIRED_TIMEOUT; while
(--loop) /*do nothing*/;) against a timing source with a known tick
rate. In our case this timing source is the WMT OS timer 0 that the
kernel programs to raise an interrupt after a predefined timeout and
counts loop iterations that elapse before that interrupt.

In your case the kernel expected the interrupt from a wrong source, so
it couldn't calibrate the loop. As too many of its features depend on
this basic busy-wait time accounting, it can't boot any further and
just keeps counting forever until IRQ37 fires (and your CPU probably
gets really hot in the meantime, as it's 100% loaded with counting
nothing).

The timer interrupt never changes in our machines (although WMT could
have used timer 1 instead of timer 0 in their kernel just as well).
I'd recommend to double check whether irq numbers that you see are
zero-based or one-based. The ones in dts should be zero-based.

By the way, the tick rate of WMT timer should be 3 MHz, not 100 Hz as
your dmesg output says... Not sure whether this is a problem.

Best,
Alexey

[Alexey Charkov]

2012/11/12 <peter...@gmail.com>:
> Well, uart0 is irq 32 in both stock kernel and my dts and it works OK, so i
> suppose the base is the same, whether 0 or 1 I don't know. Perhaps stock
> kernel really uses timer1, in that case I suppose I'd also have to change
> d8130100 in dts to some other address to initialize it properly. I'm not
> really sure what the correct address would be. Btw. I've noticed something
> in the dts: there's pmc@d8130000 device which has reg = <0xd8130000 0x1000>;
> and also timer@d8130100 with reg = <0xd8130100 0x28>; which is actually in
> the same address space - ain't those 2 devices in conflict? Or does pmc
> internally ignore the addresses 0x100-0x128 used by timer? Is there some
> hardware datasheet available for WM8650, or 8505 at least with memory
> spaces, registers and such?
> As for the 100Hz, I'm not at all sure it's supposed to be 3MHz. I found the
> kernel option CONFIG_HZ which is set to 100 in my 3.7 .config, but in config
> I've extracted from stock kernel it's actually set to 300, so I suppose tick
> rate in my machine is 300Hz, that would also correspond to the stock
> /proc/timer_list resolution:
>
>> cpu: 0
>> clock 0:
>> .base: c0750fc0
>> .index: 0
>> .resolution: 3333333 nsecs
>> .get_time: ktime_get
>> active timers:
>> #0: <c07858d0>, sched_rt_period_timer, S:01
>> # expires at 13136000000000-13136000000000 nsecs [in 765065996 to
>> 765065996 nsecs]
>> #1: <f308bb30>, hrtimer_wakeup, S:01
>> # expires at 13136000934006-13136004930006 nsecs [in 766000002 to
>> 769996002 nsecs]
>> #2: <f4839a80>, hrtimer_wakeup, S:01
>> # expires at 13138834934004-13138839934004 nsecs [in 3600000000 to
>> 3605000000 nsecs]
>> #3: <f4315f20>, hrtimer_wakeup, S:01
>> # expires at 13138934934005-13138934984005 nsecs [in 3700000001 to
>> 3700050001 nsecs]
>> #4: <f30dbeb0>, hrtimer_wakeup, S:01
>> # expires at 13150658267338-13150688267338 nsecs [in 15423333334 to
>> 15453333334 nsecs]
>> #5: <f3055b30>, hrtimer_wakeup, S:01
>> # expires at 13162000600671-13162030579671 nsecs [in 26765666667 to
>> 26795645667 nsecs]
>> #6: <f3103f20>, hrtimer_wakeup, S:01
>> # expires at 13180621600671-13180621650671 nsecs [in 45386666667 to
>> 45386716667 nsecs]
>> clock 1:
>> .base: c0750ff8
>> .index: 1
>> .resolution: 3333333 nsecs
>> .get_time: ktime_get_real
>> active timers:
>> clock 2:
>> .base: c0751030
>> .index: 2
>> .resolution: 3333333 nsecs
>> .get_time: ktime_get_boottime
>> active timers:
>
>
> As far as I'm able to tell, it's simply a fixed value configured in kernel.
> 100 is default in arch/arm/Kconfig, I've changed it to 300 for ARCH_VT8500,
> will test it with irq both 36 and 37, let's see what that does. There are
> also CONFIG_NO_HZ and CONFIG_HIGH_RES_TIMERS, wonder what those would do...

Oh, so you don't use NO_HZ... That didn't occur to me :) Without this
option the kernel schedules a regular timer interrupt at the frequency
you set (100 Hz or 300 Hz, whatever) to process any random bits of
minor work that get accumulated by that time. It then keeps firing
even if there's nothing to do (e.g. the system is idle). With NO_HZ,
though, timer interrupts are only scheduled when there is work to be
done, which keeps power consumption lower by not waking up the CPU
unnecessarily when the system is idling. I always enable this option,
not sure why it isn't always enabled by default (apparently, there
must be some specific use cases which rely on such periodic wakeups).

You do not need to change the code or interrupts if the timer worked
for you with IRQ36. Our hardware can raise up to 4 different
interrupts (OS timer 0~3) when the timer counter reaches a specific
value programmed in respective match registers (one for each of those
"timers"). There is no difference between these match registers,
except for the fact that one of them can also be used as a watchdog
that will forcefully reboot the machine upon "match" (as far as I
remember) - so in this mode the match register has to be regularly
reprogrammed to a larger value by the kernel as the counter ticks. We
have no support for this watchdog functionality yet, though.

Best,
Alexey

[Alexey Charkov]

2012/11/12 <peter...@gmail.com>:
> NO_HZ was off by default, so I didn't touch it :-) Now it's activated, but I
> don't think it'll help with the calibration (checked mach-vt8500/timer.c,
> timer0 on irq 36 is hardcoded). I found the datasheet for WM8505, I'm much
> more at home on the hardware level :-) (I'm used to dealing with MCUs from
> scratch without any OS). It's timer match register 0 (0x0100 in pmc 0xd813
> space) that can generate a watchdog reset, so I suppose this one should not
> be used for a general-purpose OS timer interrupt to leave it free for future
> watchdog support... shouldn't be a problem to implement, in 0x0118 is a
> simple flag whether timer match 0 should cause a reset or not. Perhaps
> that's why stock kernel uses IRQ 37?? We should use it in 3.7 kernel as
> well, to free timer 0. According to both WM8505 datasheet and WM8650 kernel
> source each timer has its own irq (36..39), so I'll try to get 37 working
> (few values changed in mach-vt8500/timer.c).

This should be a safe change and easy enough to push upstream for 3.8
inclusion (given appropriate comments and testing).

> Btw. it's gonna be complicated with some IRQs, apparently they're different
> in each chipset version :-( USB for example uses 0 and 1 in WM8505 according
> to datasheet, for WM8650 you have 43 in the dtsi, then according to apc-8750
> kernel source IRQ_UHDC=26 in WM8750. Hopefully it's the same for WM8850, at
> least in /proc/interrupts it looks like 26 is the right one here.

This is the very reason why all of this information should be encoded
in device trees: although they shuffle around so much stuff with every
chip revision, fundamentally it is still not that much different from
the good old VT8500. I guess it would be nice to add some minimal
dts/dtsi files for 87xx and 88xx chips and submit those upstream as
well.

I have a 8750-based device to test stuff on, just in case. However,
it's a set-top box with only HDMI output (no familiar LCD), and I
still haven't found UART pins on the board.

> I've modified timer.c for timer1, also changed timer resets and interrupt
> changes to only affect timer1, I'll see how much I screwed up in a couple
> hours :-)

Sounds good, keep us updated :)

Best,
Alexey

[Tony Prisk]

> Any ideas why the delay loop calibration fails? Here's console log
> from stock kernel right before loop calibration:
>
>
> [ 0.000000] SLUB: Genslabs=13, HWalign=32, Order=0-3,
> MinObjects=0, CPUs=1, Nodes=1
> [ 0.000000] NR_IRQS:128
> [ 0.000000] Console: colour dummy device 80x30
> [ 0.000000] console [ttyS0] enabled
> [ 0.161640] Calibrating delay loop... 2420.32 BogoMIPS
> (lpj=2270747136)
>
>
> And here's the frozen 3.7 with timer on <37>:
> [ 0.000000] SLUB: Genslabs=11, HWalign=64, Order=0-3,
> MinObjects=0, CPUs=1, Nodes=1
> [ 0.000000] NR_IRQS:128
> [ 0.000000] Added IRQ Controller @ f8140000 [virq_base = 0]
> [ 0.000000] Added IRQ Controller @ f8150000 [virq_base =
> 64]
> [ 0.000000] vt8500-irq: Enabled slave->parent interrupts
> [ 0.000000] sched_clock: 32 bits at 100 Hz, resolution
> 10000000ns, wraps every 4294967286ms
> [ 0.000000] Console: colour dummy device 80x30
> [ 0.000000] Calibrating delay loop...
>
>
> I'll post the 3.7 log with timer back on <36> when I get the chance to
> boot it again.
> Regards,
> Peter

According this output (and seeing it reminds me now), you need to change
the EHCI and UHCI interrupts to 26 in the dtsi, otherwise it just
times-out, checks the result (which is ok because it did actually
complete) and then continues - basically it's reallly slow but it works.

The timer osc #0 is the same on every SoC at the moment. No need to
change it (hence why it's still hardcoded).

Regards
Tony P

[Alexey Charkov]

2012/11/12 Tony Prisk <li...@prisktech.co.nz>:

> The timer osc #0 is the same on every SoC at the moment. No need to
> change it (hence why it's still hardcoded).

Tony, there's been a valid concern that it's better not to use osc0
for the general system timer, as it's the only one of four that is
also capable of serving as a watchdog. We lose nothing if we use osc1
(or 2, or 3) as the general timer, though (just a couple of
adjustments needed).

Best,
Alexey

[Marius Cirsta]

On Mon, Nov 12, 2012 at 11:27 PM, <peter...@gmail.com> wrote
>> [ 0.000000] Kernel command line: mem=1024M vmalloc=128M
>> console=ttyWMT0,115200n8 root=/dev/sda2 rw init=/sbin/init debug

1024M ? Is this the system RAM ? Because I think that's kinda wrong.
I haven't really seen Wondermedia devices with more than 512M.

[Tony Prisk]

On Mon, 2012-11-12 at 13:49 -0800, peter...@gmail.com wrote:
> Very quick round two: forget what I wrote about timer interrupt calls
> and NO_HZ, I forgot to deploy kernel image to tftp server root :-/ now
> it's there and values in /proc/uptime and /proc/interrupts behave like
> expected.
> Also I've removed the vmalloc=128M from kernel parameters and,
> surprisingly, no more garbage on the display :-) Unfortunately default
> vmalloc is 240M, which eats quite a large chunk of memory. In stock
> kernel vmalloc=136M, there's also 4M of DMA space which is missing in
> 3.7, but there's still 848M usable memory. In 3.7 with vmalloc=128M
> there's even more (880M, see bellow), but that's in conflict with
> framebuffer. Default vmalloc is apparently 240M, which leaves only
> some 760M of usable memory space. Well, there'll be enough time to
> play with that when everything else works ;-)
>
>
> On Monday, November 12, 2012 10:27:03 PM UTC+1, peter...@gmail.com
> wrote:
> OK, first round finished :-) Kernel started very quickly,
> actually everything is running fast. I've changed
> VT8500_TIMER_HZ in arch/arm/mach-vt8500/timer.c to 3000000
> (just guessed this could be the 3MHz oscillator frequency),
> while keeping CONFIG_HZ=300 and CONFIG_NO_HZ off (just for
> testing, so I could check timer call count
> in /proc/interrupts). Now calibration and timer setup look
> fine, BogoMIPS and lpj have much more realistic values,
> there's just those two divisions by zero on PLL init, but I
> haven't yet looked into that.
> One funny thing though - I'd expect without CONFIG_NO_HZ the
> interrupt call count for timer should be 3x bigger than
> jiffies (or 300x bigger than values in /proc/uptime) - this is
> the behaviour in stock kernel. However the values don't really
> correspond well, it's more like something I'd expect with
> NO_HZ. Well, that can wait, it doesn't seem to cause any
> problems. Another funny thing - the display is showing
> garbage :-) looks like something's overwriting framebuffer
> memory. Perhaps I shouldn't have changed vmalloc and mem
> kernel parameters :-)
> Here's dmesg log up to clocksource setting:

>
>
> Uncompressing Linux... done, booting the kernel.

> [ 0.000000] Booting Linux on physical CPU 0
> [ 0.000000] Initializing cgroup subsys cpuset
> [ 0.000000] Initializing cgroup subsys cpu
> [ 0.000000] Linux version 3.7.0-rc3+
> (nightwolf@main1) (gcc version 4.7.2 (Ubuntu/Linaro
> 4.7.2-1ubuntu1) ) #46 Mon Nov 12 21:51:46 CET 2012
> [ 0.000000] CPU: ARMv7 Processor [413fc090]
> revision 0 (ARMv7), cr=10c5387d
> [ 0.000000] CPU: PIPT / VIPT nonaliasing data
> cache, VIPT aliasing instruction cache
> [ 0.000000] Machine: VIA/Wondermedia SoC (Device
> Tree Support), model: Wondermedia WM8650-MID Tablet
> [ 0.000000] debug: ignoring loglevel setting.
> [ 0.000000] bootconsole [earlycon0] enabled
> [ 0.000000] Truncating RAM at 00000000-3fffffff to
> -36ffffff (vmalloc region overlap).
> [ 0.000000] Memory policy: ECC disabled, Data cache
> writeback
> [ 0.000000] On node 0 totalpages: 225280
> [ 0.000000] free_area_init_node: node 0, pgdat
> c04c7a7c, node_mem_map c074b000
> [ 0.000000] Normal zone: 1760 pages used for
> memmap
> [ 0.000000] Normal zone: 0 pages reserved
> [ 0.000000] Normal zone: 223520 pages, LIFO
> batch:31
> [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768
> alloc=1*32768
> [ 0.000000] pcpu-alloc: [0] 0
> [ 0.000000] Built 1 zonelists in Zone order,
> mobility grouping on. Total pages: 223520

> [ 0.000000] Kernel command line: mem=1024M
> vmalloc=128M console=ttyWMT0,115200n8 root=/dev/sda2

> rw init=/sbin/init debug ignore_loglevel earlyprintk
> oops=panic panic=30 rootdelay=15
> [ 0.000000] PID hash table entries: 4096 (order: 2,
> 16384 bytes)
> [ 0.000000] Dentry cache hash table entries: 131072
> (order: 7, 524288 bytes)
> [ 0.000000] Inode-cache hash table entries: 65536
> (order: 6, 262144 bytes)
> [ 0.000000] allocated 1802240 bytes of page_cgroup
> [ 0.000000] please try 'cgroup_disable=memory'
> option if you don't want memory cgroups
> [ 0.000000] Memory: 880MB = 880MB total
> [ 0.000000] Memory: 885976k/885976k available,
> 15144k reserved, 0K highmem
> [ 0.000000] Virtual kernel memory layout:
> [ 0.000000] vector : 0xffff0000 - 0xffff1000
> ( 4 kB)
> [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000
> ( 896 kB)
> [ 0.000000] vmalloc : 0xf7800000 - 0xff000000
> ( 120 MB)
> [ 0.000000] lowmem : 0xc0000000 - 0xf7000000
> ( 880 MB)
> [ 0.000000] modules : 0xbf000000 - 0xc0000000
> ( 16 MB)
> [ 0.000000] .text : 0xc0008000 - 0xc047afac
> (4556 kB)
> [ 0.000000] .init : 0xc047b000 - 0xc049a0c4
> ( 125 kB)
> [ 0.000000] .data : 0xc049c000 - 0xc04cd530
> ( 198 kB)
> [ 0.000000] .bss : 0xc04cd554 - 0xc055c9cc
> ( 574 kB)

> [ 0.000000] SLUB: Genslabs=11, HWalign=64,
> Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> [ 0.000000] NR_IRQS:128
> [ 0.000000] Added IRQ Controller @ f8140000
> [virq_base = 0]
> [ 0.000000] Added IRQ Controller @ f8150000
> [virq_base = 64]
> [ 0.000000] vt8500-irq: Enabled slave->parent
> interrupts

> [ 0.000000] vt8500_timer_init
> [ 0.000000] vt8500_timer_set_mode(1, c04a8340)
> [ 0.000000] vt8500_timer_set_mode(3, c04a8340)
> [ 0.000000] sched_clock: 32 bits at 300 Hz,
> resolution 3333333ns, wraps every 1431655760ms

> [ 0.000000] Console: colour dummy device 80x30

> [ 0.006666] calibrate_delay(): this_cpu=00000000
> HZ=300
> [ 0.009999] read_current_timer(&-1069480008) = -6
> [ 0.013333] Calibrating delay loop... 789.76
> BogoMIPS (lpj=1314816)
> [ 0.039999] pid_max: default: 32768 minimum: 301
> [ 0.043333] Mount-cache hash table entries: 512
> [ 0.046666] Initializing cgroup subsys cpuacct
> [ 0.049999] Initializing cgroup subsys memory
> [ 0.053333] Initializing cgroup subsys devices
> [ 0.056666] Initializing cgroup subsys freezer
> [ 0.059999] Initializing cgroup subsys blkio
> [ 0.063333] CPU: Testing write buffer coherency: ok
> [ 0.066666] Setting up static identity map for
> 0x339a00 - 0x339a58
> [ 0.069999] devtmpfs: initialized
> [ 0.073333] NET: Registered protocol family 16
> [ 0.076666] DMA: preallocated 256 KiB pool for
> atomic coherent allocations
> [ 0.079999] Division by zero in kernel.
> [ 0.083333] [<c0019834>] (unwind_backtrace
> +0x0/0x138) from [<c01892b4>] (Ldiv0+0x8/0x10)
> [ 0.086666] [<c01892b4>] (Ldiv0+0x8/0x10) from
> [<c029dc34>] (vtwm_pll_recalc_rate+0x68/0x6c)
> [ 0.089999] [<c029dc34>] (vtwm_pll_recalc_rate
> +0x68/0x6c) from [<c029ca94>] (__clk_init+0x184/0x404)
> [ 0.093333] [<c029ca94>] (__clk_init+0x184/0x404)
> from [<c029cdf8>] (clk_register+0xe4/0x1ac)
> [ 0.096666] [<c029cdf8>] (clk_register+0xe4/0x1ac)
> from [<c0491724>] (vtwm_pll_clk_init+0x104/0x154)
> [ 0.099999] [<c0491724>] (vtwm_pll_clk_init
> +0x104/0x154) from [<c0491344>] (of_clk_init
> +0x2c/0x50)
> [ 0.103333] [<c0491344>] (of_clk_init+0x2c/0x50)
> from [<c0480c40>] (vt8500_init+0x1a8/0x25c)
> [ 0.106666] [<c0480c40>] (vt8500_init+0x1a8/0x25c)
> from [<c047d494>] (customize_machine+0x1c/0x28)
> [ 0.109999] [<c047d494>] (customize_machine
> +0x1c/0x28) from [<c00086f4>] (do_one_initcall
> +0x10c/0x170)
> [ 0.113333] [<c00086f4>] (do_one_initcall
> +0x10c/0x170) from [<c032c9cc>] (kernel_init
> +0x140/0x2ec)
> [ 0.116666] [<c032c9cc>] (kernel_init+0x140/0x2ec)
> from [<c0014298>] (ret_from_fork+0x14/0x3c)
> [ 0.119999] Division by zero in kernel.
> [ 0.123333] [<c0019834>] (unwind_backtrace
> +0x0/0x138) from [<c01892b4>] (Ldiv0+0x8/0x10)
> [ 0.126666] [<c01892b4>] (Ldiv0+0x8/0x10) from
> [<c029dc34>] (vtwm_pll_recalc_rate+0x68/0x6c)
> [ 0.129999] [<c029dc34>] (vtwm_pll_recalc_rate
> +0x68/0x6c) from [<c029ca94>] (__clk_init+0x184/0x404)
> [ 0.133333] [<c029ca94>] (__clk_init+0x184/0x404)
> from [<c029cdf8>] (clk_register+0xe4/0x1ac)
> [ 0.136666] [<c029cdf8>] (clk_register+0xe4/0x1ac)
> from [<c0491724>] (vtwm_pll_clk_init+0x104/0x154)
> [ 0.139999] [<c0491724>] (vtwm_pll_clk_init
> +0x104/0x154) from [<c0491344>] (of_clk_init
> +0x2c/0x50)
> [ 0.143333] [<c0491344>] (of_clk_init+0x2c/0x50)
> from [<c0480c40>] (vt8500_init+0x1a8/0x25c)
> [ 0.146666] [<c0480c40>] (vt8500_init+0x1a8/0x25c)
> from [<c047d494>] (customize_machine+0x1c/0x28)
> [ 0.149999] [<c047d494>] (customize_machine
> +0x1c/0x28) from [<c00086f4>] (do_one_initcall
> +0x10c/0x170)
> [ 0.153333] [<c00086f4>] (do_one_initcall
> +0x10c/0x170) from [<c032c9cc>] (kernel_init
> +0x140/0x2ec)
> [ 0.156666] [<c032c9cc>] (kernel_init+0x140/0x2ec)
> from [<c0014298>] (ret_from_fork+0x14/0x3c)
> [ 0.163333] bio: create slab <bio-0> at 0
> [ 0.166666] vgaarb: loaded
> [ 0.169999] SCSI subsystem initialized
> [ 0.173333] usbcore: registered new interface
> driver usbfs
> [ 0.176666] usbcore: registered new interface
> driver hub
> [ 0.179999] usbcore: registered new device driver
> usb
> [ 0.183333] Switching to clocksource vt8500_timer
> [ 0.193333] NET: Registered protocol family 2
>
>
>
>
>
>
>
>
> On Monday, November 12, 2012 9:09:52 PM UTC+1,
> peter...@gmail.com wrote:
> So, I have booted archlinux with stock kernel and
> played a bit around with timers. First very suspicious
> message from stock kernel:

>
>
> [ 0.161640] Calibrating delay loop... 2420.32
> BogoMIPS (lpj=2270747136)
>
>

> According to 3.0.8 kernel source code this is quite
> obviously nonsense. Putting the values from message
> into the BogoMIPS equation in init/calibrate.c
> (BogoMIPS = lpj / (500000/HZ)) would yield HZ value of
> about 0.53, which is quite impossible. Well, so much
> for stock calibration.
> I've put together a small program, again accessing my
> most favorite /dev/mem device, specifically PMC
> section (64k @ 0xd8130000). It's clear from my dumps
> that stock kernel really uses timer1 - values in
> 0x0104 (timer1 match) and 0x0110 (timer counter) are
> changing accordingly. Timer frequency appears to be
> 3MHz like Alexey suggested (0x0110 increases by
> 3000000 each second), however logical linux timer
> frequency is actually 300Hz - 0x0104 timer1 match
> value increases in 10000 steps, which means the timer1
> interrupt is only activated 300 times/second. I
> presume my CONFIG_HZ=300 is correct, though I'm not
> yet sure how should I tell kernel about the 3MHz
> oscillator frequency (if it's necessary at all).
> My first boot of 3.7 kernel on 300Hz timer1 didn't go
> particularly well:
>
>
> [ 0.000000] sched_clock: 32 bits at 300 Hz,
> resolution 3333333ns, wraps every 1431655760ms

> [ 0.000000] Console: colour dummy device
> 80x30

> [ 0.103333] Calibrating delay loop... 0.87
> BogoMIPS (lpj=1406)
> [ 0.186666] pid_max: default: 32768
> minimum: 301
> [ 0.289999] Mount-cache hash table entries:
> 512
> [ 1.063333] Initializing cgroup subsys
> cpuacct
> [ 1.069999] Initializing cgroup subsys
> memory
> [ 1.089999] Initializing cgroup subsys
> devices
> [ 1.093333] Initializing cgroup subsys
> freezer
> [ 1.096666] Initializing cgroup subsys
> blkio
> [ 1.139999] CPU: Testing write buffer
> coherency: ok
> [ 1.276666] Setting up static identity map
> for 0x3399e0 - 0x339a38
> [ 3.119999] devtmpfs: initialized
> [ 5.066666] NET: Registered protocol family
> 16
> [ 5.546666] DMA: preallocated 256 KiB pool
> for atomic coherent allocations
> [ 6.329999] Division by zero in kernel.
> [ 6.339999] [<c0019834>] (unwind_backtrace
> +0x0/0x138) from [<c0189294>] (Ldiv0+0x8/0x10)
> [ 6.346666] [<c0189294>] (Ldiv0+0x8/0x10)
> from [<c029dc14>] (vtwm_pll_recalc_rate
> +0x68/0x6c)
> [ 6.353333] [<c029dc14>]
> (vtwm_pll_recalc_rate+0x68/0x6c) from
> [<c029ca74>] (__clk_init+0x184/0x404)
> [ 6.356666] [<c029ca74>] (__clk_init
> +0x184/0x404) from [<c029cdd8>] (clk_register
> +0xe4/0x1ac)
> [ 6.359999] [<c029cdd8>] (clk_register
> +0xe4/0x1ac) from [<c0491710>]
> (vtwm_pll_clk_init+0x104/0x154)
> [ 6.366666] [<c0491710>] (vtwm_pll_clk_init
> +0x104/0x154) from [<c0491330>] (of_clk_init
> +0x2c/0x50)
> [ 6.369999] [<c0491330>] (of_clk_init
> +0x2c/0x50) from [<c0480c2c>] (vt8500_init
> +0x1a8/0x25c)
> [ 6.373333] [<c0480c2c>] (vt8500_init
> +0x1a8/0x25c) from [<c047d494>]
> (customize_machine+0x1c/0x28)
> [ 6.379999] [<c047d494>] (customize_machine
> +0x1c/0x28) from [<c00086f4>] (do_one_initcall
> +0x10c/0x170)
> [ 6.383333] [<c00086f4>] (do_one_initcall
> +0x10c/0x170) from [<c032c9ac>] (kernel_init
> +0x140/0x2ec)
> [ 6.389999] [<c032c9ac>] (kernel_init
> +0x140/0x2ec) from [<c0014298>] (ret_from_fork
> +0x14/0x3c)
> [ 6.419999] Division by zero in kernel.
> [ 6.426666] [<c0019834>] (unwind_backtrace
> +0x0/0x138) from [<c0189294>] (Ldiv0+0x8/0x10)
> [ 6.433333] [<c0189294>] (Ldiv0+0x8/0x10)
> from [<c029dc14>] (vtwm_pll_recalc_rate
> +0x68/0x6c)
> [ 6.439999] [<c029dc14>]
> (vtwm_pll_recalc_rate+0x68/0x6c) from
> [<c029ca74>] (__clk_init+0x184/0x404)
> [ 6.443333] [<c029ca74>] (__clk_init
> +0x184/0x404) from [<c029cdd8>] (clk_register
> +0xe4/0x1ac)
> [ 6.446666] [<c029cdd8>] (clk_register
> +0xe4/0x1ac) from [<c0491710>]
> (vtwm_pll_clk_init+0x104/0x154)
> [ 6.453333] [<c0491710>] (vtwm_pll_clk_init
> +0x104/0x154) from [<c0491330>] (of_clk_init
> +0x2c/0x50)
> [ 6.456666] [<c0491330>] (of_clk_init
> +0x2c/0x50) from [<c0480c2c>] (vt8500_init
> +0x1a8/0x25c)
> [ 6.459999] [<c0480c2c>] (vt8500_init
> +0x1a8/0x25c) from [<c047d494>]
> (customize_machine+0x1c/0x28)
> [ 6.463333] [<c047d494>] (customize_machine
> +0x1c/0x28) from [<c00086f4>] (do_one_initcall
> +0x10c/0x170)
> [ 6.466666] [<c00086f4>] (do_one_initcall
> +0x10c/0x170) from [<c032c9ac>] (kernel_init
> +0x140/0x2ec)
> [ 6.469999] [<c032c9ac>] (kernel_init
> +0x140/0x2ec) from [<c0014298>] (ret_from_fork
> +0x14/0x3c)
> [ 11.393333] bio: create slab <bio-0> at 0
> [ 11.823333] vgaarb: loaded
> [ 12.256666] SCSI subsystem initialized
> [ 12.406666] usbcore: registered new
> interface driver usbfs
> [ 12.466666] usbcore: registered new
> interface driver hub
> [ 12.576666] usbcore: registered new device
> driver usb
> [ 13.349999] Switching to clocksource
> vt8500_timer
>
This suggests that you have and old (bad) version of the clock code.
It's causing a division by zero. I can't remember what caused this, but
I'm fairly certain its fixed in the newest patches.
>
> At which point it simply froze. BogoMIPS and lpj
> values look according to the equation in kernel source
> code now, but they're way too low :-( I'll have to
> check the calibration functions in init/calibrate.c.
> As for freezing, I'll have put in a few additional
> debug outputs to see what's really going on inside, I
> suppose I screwed something up in timer
> initialisation.
> BR
> Peter
>
>
>
>
> On Monday, November 12, 2012 6:40:58 PM UTC+1, Alexey

Fair comment, and there isn't really any reason why it couldn't be a
different timer. They are all the same on every model (interrupt-wise).
One thing I noticed that needs to be sorted out/checked is that under
multiplatform, the timer_hz is 1000000 (off the top of my head) rather
than the 3000000 that we had in our timex file. I tested that it ran,
but I didn't check the actual output so it may be out by 3x.

Peter,
One thing I'm finding hard to follow is which source you are referring
to when you make comments. Could you please use 'vendor source' for the
WMT supplied code. Stock kernel confuses me :)

Also, I don't know what state the sourceforge code is in.
tags/vt8500-3.8 is newest in git. The source tarball's are out-of-date
and contain bugs which have been fixed.

Newest code is currently in linux-next, or 3.7-rc4 is also good (except
for SD/MMC clock's giving an error about invalid clock setting - which
is fixed in -next).

I'm having trouble getting any reply from Chris Ball in regards to the
SD/MMC driver patch so I don't know whether it will be in 3.8


Framebuffer: You can 'hack' the framebuffer to work by setting the dts
parameters to match what uboot configures for the framebuffer, then
modify the wm8505-fb code to use a fixed physical address (as allocated
by uboot). I did this originally when trying to figure out the problem
with the framebuffer, and confirmed that it worked except the last line
of the screen didn't 'scroll' properly. But at least it gave screen
output - its just reinitializing the framebuffer that doesn't want to
work.


Regards
Tony P

[Marius Cirsta]

On Tue, Nov 13, 2012 at 1:25 AM, <peter...@gmail.com> wrote:
> 1GB RAM is quite right ;-)
> http://www.ebay.at/itm/170896744769?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2649#ht_5929wt_1346
>

I hope you verified that by looking at the RAM chips ... didn't know
they make it in 1GB versions and the Chinese are knows to well ...
exaggerate about the specs.

[Tony Prisk]

On Tue, 2012-11-13 at 04:20 -0800, peter...@gmail.com wrote:
> Hello Tony
> Sorry for confusion. I don't have any vendor sources (they haven't
> released anything for 8850/8950 series yet), I'm simply used to
> referring to the original device firmware as stock, hence the stock
> kernel (binary only). I'll try to use something less confusing.
vendor kernel is fine :)
> Or I won't mention vendor kernel at all anymore, when I get the
> framebuffer working I'll have all the basic functionality I require
> from the netbook, then I can leave original firmware alone at last ;-)
> I'm afraid I'm a bit lost in all the kernel revisions :-( Up to now I
> used 3.7-rc3 source downloaded as .tar.gz. I have now cloned latest
> linux-next from git.kernel.org, it's 3.7-rc5 now. I should have it
> running tonight (hopefully).

Anything after 3.7-rc2 (from kernel.org or similar) will be the same at
the moment. -rc2 included a patch to fix ehci/uhci.

Linux-next will include the multiplatform patches, and some clock fixes
for SD/MMC driver. At the moment, it doesn't really add anything useful
but it's still the 'best' code at the moment.

> Is there some functionality available for vt8500 family not present
> in this version? I've also found
> git://server.prisktech.co.nz/git/linuxwmt.git repository (yours, I
> suppose?)

I moved some of my dev work here because I can't access sourceforge
while on nightshift work (my company blocks it), so I ssh to my home
server to do some work. There is nothing on there that you can't get
from linux-next.

> and of course git://git.code.sf.net/p/linuxwmt/code (this one has
> vt8500-3.8 branch inside),

This is the 'official' repository for arch-vt8500. I haven't tidied it
up for a while, but the vt8500-3.8 branch is the newest but a little old
now. It's missing some of the fixes that are now in 3.7-rc2+ but its
functional.

> I have no idea what differences are there between these 3
> repositories.
> You've mentioned SD/MMC driver patch - should that make internal SD
> card slot work?? That would be really nice... Is it available
> somewhere? Or included in any of those repos?

I don't believe it's included anywhere. There is a patch floating around
based on 3.7-rc1 which is waiting for someone to pick it up for mainline
but I can't seem to get a reply from the subsystem maintainer so it's
kind of in limbo.
https://patchwork.kernel.org/patch/1654541/


> BR,
> Peter

[Tony Prisk]

On Tue, 2012-11-13 at 13:51 -0800, peter...@gmail.com wrote:
> Hi
> I got the framebuffer driver running. I had to disable .fb_pan_display
> (commented out its line in wm8505fb_ops), with it active the scrolling
> worked completely wrong in fb console (more like didn't work at all).
> I suppose FB initialization is not the only problem, apparently any
> setting of WMT_GOVR_xxx is ignored, or at least highly dysfunctional
> (blanking doesn't work either). Unfortunately there's nothing about it
> in WM8505 datasheet. I tried to look it up in apc-8750 kernel sources,
> but it's not there??? drivers/video/wmt/ is full of .o files, without
> any sources! F$*&%rs!
> Well, without .fb_pan_display the console works more or less ok, with
> the last line scrolling problem you've mentioned. I've tried to start
> X, but it fails with "FBIOPUT_VSCREENINFO succeeded but modified
> mode". From what I found, the problem is missing .fb_check_var in
> wm8505fb_ops, I'll try to put together some simple implementation and
> see if it helps.
> BR,
> Peter

I suppose I should have clarified what I've done :)

I actually wrote a completely new framebuffer driver that reset ALL the
graphics hardware (via the software reset features) and then set it up
again from a clean state (similar to what uboot has to do).

It worked perfectly fine for 8505 & 8650, but nothing on 8850.

As you mentioned, register writes on 8850 seem to be ignored although
the registers seem to match the previous models if you decode the
values. Even resetting the hardware doesn't seem to allow writes to the
GOVR registers. My best guess at the moment given we have no source is
that they may have implemented a write-protect register or similar.

Perhaps some clever cookie with an ARM decompiler could reverse the .o
and post a source drop ;) I don't imagine the driver will have changed
that much, especially since our driver tends to work ok with the already
initialized framebuffer.

Regards
Tony P

[Tony Prisk]

Does this mean you want me to write+submit a patch, or that I should be expecting a patch from someone else ;)

Regards
Tony P

[Tony Prisk]

Now to interrupts in dts - first there is a whole list of them in intc1: interrupts = <56 57 58 59 60 61 62 63> but none of those is mentioned in /proc/interrupts, so I've left them be for now.

FYI: These interrupts are cascades from IC1 -> IC0. They aren't mentioned in /proc/interrupts because (judging from other WMT source) they are enabled with the WMT functions and linux doesn't actually know they are being used.

Regards
Tony P

[Alexey Charkov]

2012/11/14 Tony Prisk <sent...@digitalfantasy.co.nz>:

I thought that Peter was playing around with timers, so in case he
makes any progress and shares that as a patch, it might make sense to
push it upstream as well... This doesn't feel like a high-priority
task to me, frankly.

Best,
Alexey

[Tony Prisk]

[    0.110000] [<80013bc8>] (unwind_backtrace+0x0/0x138) from [<801889b4>] (Ldiv0+0x8/0x10)
[    0.110000] [<801889b4>] (Ldiv0+0x8/0x10) from [<8029f0bc>] (vtwm_pll_recalc_rate+0x68/0x6c)
[    0.120000] [<8029f0bc>] (vtwm_pll_recalc_rate+0x68/0x6c) from [<8029de5c>] (__clk_init+0x184/0x404)
[    0.120000] [<8029de5c>] (__clk_init+0x184/0x404) from [<8029e1a4>] (_clk_register+0xc8/0x15c)
[    0.130000] [<8029e1a4>] (_clk_register+0xc8/0x15c) from [<8029e2e0>] (clk_register+0x3c/0x88)
[    0.130000] [<8029e2e0>] (clk_register+0x3c/0x88) from [<804bd024>] (vtwm_pll_clk_init+0x104/0x154)
[    0.140000] [<804bd024>] (vtwm_pll_clk_init+0x104/0x154) from [<804bcc40>] (of_clk_init+0x2c/0x50)
[    0.140000] [<804bcc40>] (of_clk_init+0x2c/0x50) from [<804acd88>] (wm8950_init+0x130/0x1b0)
[    0.150000] [<804acd88>] (wm8950_init+0x130/0x1b0) from [<804a9400>] (customize_machine+0x1c/0x28)

Have you created a new function wm8950_init, or renamed something else?

[    0.150000] [<804a9400>] (customize_machine+0x1c/0x28) from [<80008754>] (do_one_initcall+0x10c/0x170)
[    0.160000] [<80008754>] (do_one_initcall+0x10c/0x170) from [<80358868>] (kernel_init+0x140/0x2ec)
[    0.160000] [<80358868>] (kernel_init+0x140/0x2ec) from [<8000ead8>] (ret_from_fork+0x14/0x3c)
[    0.170000] Division by zero in kernel.
[    0.170000] [<80013bc8>] (unwind_backtrace+0x0/0x138) from [<801889b4>] (Ldiv0+0x8/0x10)
[    0.180000] [<801889b4>] (Ldiv0+0x8/0x10) from [<8029f0bc>] (vtwm_pll_recalc_rate+0x68/0x6c)
[    0.180000] [<8029f0bc>] (vtwm_pll_recalc_rate+0x68/0x6c) from [<8029de5c>] (__clk_init+0x184/0x404)
[    0.190000] [<8029de5c>] (__clk_init+0x184/0x404) from [<8029e1a4>] (_clk_register+0xc8/0x15c)
[    0.190000] [<8029e1a4>] (_clk_register+0xc8/0x15c) from [<8029e2e0>] (clk_register+0x3c/0x88)
[    0.200000] [<8029e2e0>] (clk_register+0x3c/0x88) from [<804bd024>] (vtwm_pll_clk_init+0x104/0x154)
[    0.200000] [<804bd024>] (vtwm_pll_clk_init+0x104/0x154) from [<804bcc40>] (of_clk_init+0x2c/0x50)
[    0.210000] [<804bcc40>] (of_clk_init+0x2c/0x50) from [<804acd88>] (wm8950_init+0x130/0x1b0)
[    0.210000] [<804acd88>] (wm8950_init+0x130/0x1b0) from [<804a9400>] (customize_machine+0x1c/0x28)
[    0.220000] [<804a9400>] (customize_machine+0x1c/0x28) from [<80008754>] (do_one_initcall+0x10c/0x170)
[    0.220000] [<80008754>] (do_one_initcall+0x10c/0x170) from [<80358868>] (kernel_init+0x140/0x2ec)
[    0.230000] [<80358868>] (kernel_init+0x140/0x2ec) from [<8000ead8>] (ret_from_fork+0x14/0x3c)
[    0.240000] bio: create slab <bio-0> at 0
[    0.240000] SCSI subsystem initialized
[    0.250000] libata version 3.00 loaded.
[    0.250000] usbcore: registered new interface driver usbfs
[    0.250000] usbcore: registered new interface driver hub
[    0.260000] usbcore: registered new device driver usb
[    0.260000] Switching to clocksource wm8950_timer

New timer driver or a rename?

[Tony Prisk]

I thought that Peter was playing around with timers, so in case he
makes any progress and shares that as a patch, it might make sense to
push it upstream as well... This doesn't feel like a high-priority
task to me, frankly.

Best,
Alexey

Given that someone is actually doing some work with wm8850 I will get a dtsi/dts added for it in 3.8

My feeling is that moving the timer from OSC#0 to OSC#1 is something that should be done at the same time as a watchdog driver is written, so I'll leave that up to whoever implements the watchdog driver :)

I'm a little annoyed because I had a wiki page on my local server with a memory map and irq map for all the SoC's, and then a HDD failed and I lost everything. Haven't found the motivation to get it done again.

Regards
Tony P

[Alexey Charkov]

2012/11/14 Tony Prisk <sent...@digitalfantasy.co.nz>:

Oh, that's a pity. Any chance that it's been cached by Google or
anyone else? Or was it a private server?

Best,
Alexey

[Tony Prisk]

Not that I can find anywhere. It was public, but I don't think it
survived long enough to get cached.

I'm back on night shift after next week so I'll get some real work done
again then.

[Alexey Charkov]

2012/11/14 <peter...@gmail.com>:
> I can create a small patch for timer.c and irq 37 in dtsi, no problem, but I
> have absolutely no experience pushing patches to kernel ;-)

In fact, I don't see much point in changing this before there are any
moves towards watchdog timer driver creation. There's no loss, but
there is no benefit either. If you are willing to implement the
watchdog functionality, though, we will definitely be happy to provide
feedback and advice on upstreaming both changes.

Best,
Alexey

[Tony Prisk]

On Wednesday, November 14, 2012 9:55:02 PM UTC+13, peter...@gmail.com wrote:

Hi, I have simply copied arch/arm/mach-vt8500 to arch/arm/mach-wm8950, created ARCH_WM8950 (changed all the sources so that everything depending on VT8500 gets activated for WM8950 as well) and created new wm8850.dtsi and wm8850-netbook.dts :-) From there I only played in mach-wm8950 directory, didn't touch anything in original VT8500. The wm8950_init comes from my new mach code, basically just copy/paste with fixed names.

I THINK I might have found out why the clock is throwing exceptions. The vtwm_pll_recalc_rate in drivers/clk/clk-vt8500.c has 2 different calculation methods for VT8500 and WM8650 clock types. Actually there are more functions in this driver dependent on whether vt8500-pll-clock or wm8650-pll-clock is specified in dts. Currently I have wm8650 clock in my dts, and I'm afraid the calculation method to get PLL multipliers and divisors for WM8850 from the register value is different than it was for 8650. I put out some logs in recalc_rate:

[    0.100000] vtwm_pll_recalc_rate(WM8650): rate=017d7840, val=00410101, mul=00000101, div=00000000

[    0.110000] vtwm_pll_recalc_rate(WM8650): rate=017d7840, val=002b0101, mul=00000101, div=00000000

I think first line is for plla and the second one for pllb. Base rate is 25MHz which is fine according to dts, but apparently register value is structured differently than 8650. I'm not sure which part is divisor and which is multiplier, or even if it's really as simple as in 8650 :-( I've checked the wmt-clk.c in apc-8750 sources, and it looks a bit more complicated than that. There's something like this:

        tmp = *(volatile unsigned int *)(PMC_PLL + 4*PLL_NO);

        PLL = SRC_FREQ*(((tmp>>16)&0xFF)+1)*base;

        //printk(KERN_INFO" PLL =%llu\n", PLL);

        div_llu = (((tmp>>8)&0x3F)+1)*(1<<(tmp&7));

PMC_PLL is PMC_BASE+0x200, PLL_NO is just index (A=0, B=1,...), so tmp gets register value (val in my log above). It looks like for the first line of log multiplier should be 0x41+1=66 and divisor (0x01+1)*(1<<0x01)=4, that would create some 412.5MHz clock (SRC_FREQ is 25 and base 1000000, for 25MHz I suppose). Second multiplier would be 44 with same divisor, thus 275MHz clock. No idea if those values are correct, though...

I'm gonna add new clock type wm8850 with this calculation, let's see what it does.

 

I should have thought about that - you are correct. The clock code is different for WM8850. When I tested my WM8850, we had no clock code in the kernel - we just relied on what u-boot had already setup.

Same with the SDMMC driver - I don't think its been tested on WM8850, but it definately won't work with the clock code being broken.

Looks like I might have a bit of work to do adding WM8850 support.

Regards
Tony P

[Alexey Charkov]

2012/11/14 Tony Prisk <sent...@digitalfantasy.co.nz>:

Can we just add dummy functions for unsupported platforms for
starters? That should leave us with the same situation as with no
clock code at all, and at much less effort.

Best,
Alexey

[Tony Prisk]

The reason there is no dummy functions is that I hadn't looked at the
WM8850 code before I wrote the mainline code, and I didn't want to add
'dummy' functions for code that may not have changed - It was possible
that 8850 could still use WM8650-style PLL's.

Regards
Tony P

[Tony Prisk]

On Thursday, November 15, 2012 8:50:50 AM UTC+13, peter...@gmail.com wrote:

OK, I have mmc working now. Not very clean method though... I couldn't get consistent results with any combination of delays or disabled caches I could think of, until it occured to me to (ab)use uboot. So now I call "mmcinit 0" before each kernel boot, and everything works like a charm, no delays, no debug logs (except clock, though I'll probably disable that, too, now) or cache disabling necessary. Surprise, surprise :-/ Apparently it eventually get's mmc interface on 55MHz, which is even more than uboot sets (41MHz I believe) :-) It's quite fast, reads my SD card over 20MB/s. Even card remove/insert detection works fine.

 

Interestingly - Wondermedia states max clock rate for SD/MMC is 52Mhz., and from memory the 52Mhz was for MMC, not SD.

[Tony Prisk]

On Thu, 2012-11-15 at 01:50 -0800, peter...@gmail.com wrote:
> Well apparently it tried to set 50MHz first, but that's impossible do
> divide from 275MHz PLL (would need 5.5 divisor),
> so vt8500_dclk_round_rate in clk-vt8500.c returned a divisor value 5.
> It only makes simple integer division, which means if required divisor
> is decimal, it will always return smaller value, which will result in
> higher device frequency. Perhaps this behaviour is incorrect? I
> suppose the round method should by default return a divisor to achieve
> no higher than requested frequency? Apparently it works for 400kHz,
> but that's only because divisor is over 31, which activates a bit
> different logic returning higher divisor. Should we change round_rate
> to always round divisor value up?

Ugh - yes it definitely should be rounding up, not down.
I'll get a patch done for that.

[Tony Prisk]

On Thu, 2012-11-15 at 07:05 -0800, peter...@gmail.com wrote:
> Yup, it screws up the time all right (5th value, hour goes from 15 to
> 21 instead of 16). I'll have to think of some way to fix this without
> having to copy whole driver...
>
>
> root@minibook1:~/dev/mem# hwclock -r ; ./memwatch
> $((0xd8100000)) 00 04 08 0c 10 14 18 1c
> Thu 15 Nov 2012 15:59:50 CET -0.673750 seconds
> 1352991590.554162: 00451327 00009415 3d552cd1 00000003
> 00452cd0 00009415 00000000 00000000
> 1352991591.547939: 00451327 00009415 3d552cd1 00000003
> 00452cd1 00009415 00000000 00000000
> 1352991591.548038: 00451327 00009415 01552cd1 00000003
> 00452cd1 00009415 00000000 00000000
> 1352991592.547966: 00451327 00009415 01552cd1 00000003
> 00452cd2 00009415 00000000 00000000
> 1352991593.547992: 00451327 00009415 01552cd1 00000003
> 00452cd3 00009415 00000000 00000000
> 1352991594.548017: 00451327 00009415 01552cd1 00000003
> 00452cd4 00009415 00000000 00000000
> 1352991595.548043: 00451327 00009415 01552cd1 00000003
> 00452cd5 00009415 00000000 00000000
> 1352991596.548069: 00451327 00009415 01552cd1 00000003
> 00452cd6 00009415 00000000 00000000
> 1352991597.548095: 00451327 00009415 01552cd1 00000003
> 00452cd7 00009415 00000000 00000000
> 1352991598.548120: 00451327 00009415 01552cd1 00000003
> 00452cd8 00009415 00000000 00000000
> 1352991599.548146: 00451327 00009415 01552cd1 00000003
> 00452cd9 00009415 00000000 00000000
> 1352991600.548172: 00451327 00009415 01552cd1 00000003
> 00480000 00009415 00000000 00000000
> 1352991601.548197: 00451327 00009415 01552cd1 00000003
> 00480001 00009415 00000000 00000000
> 1352991602.548224: 00451327 00009415 01552cd1 00000003
> 00480002 00009415 00000000 00000000
> 1352991603.548250: 00451327 00009415 01552cd1 00000003
> 00480003 00009415 00000000 00000000
> root@minibook1:~/dev/mem# hwclock -r ; ./memwatch
> $((0xd8100000)) 00 04 08 0c 10 14 18 1c
> Thu 15 Nov 2012 21:00:07 CET -0.760171 seconds
> 1352991607.554615: 00451327 00009415 3d580008 00000003
> 00480007 00009415 00000000 00000000
>
>
>
>
>
> On Thursday, November 15, 2012 3:53:11 PM UTC+1, peter...@gmail.com
> wrote:
> I've just noticed another bug comparing 3.7 source to the
> apc-8750. In rtc-vt8500.c the bit for 12/24 hour mode in
> control register is set to 1 for 24hour mode:
>
>
> /* Enable RTC and set it to 24-hour mode */
> writel(VT8500_RTC_CR_ENABLE |
> VT8500_RTC_CR_24H,
> vt8500_rtc->regbase + VT8500_RTC_CR);
>
>
> However, in wmt_rtc.h in apc-8750 kernel sources it appears
> this bit has been inverted:
>
>
> #define RTCC_12HR BIT1 /* Time Format
> 1:12-hour 0:24-hour */
>
>
> I'll have to observe this, if it causes any problems. I've
> already noticed a couple times my RTC time went haywire
> apparently randomly, I'm not sure if it's related.
> Btw. has anyone tried to implement I2C and SPI busses for
> VT8500/WM8650?
> BR,
> Peter
>
>
Blah.. I thought this bug was fixed already. I remember it coming up
years ago and being patched. I wonder if the WM8850 has reverted it back
or whether the original patch is missing from mainline.

I'll fix this too.

[Tony Prisk]

On Thu, 2012-11-15 at 13:12 -0800, peter...@gmail.com wrote:
> Well, I've just added a parameter into dts rtc object
> (ctl-24h-inverted), if it's present rtc driver will invert 24h bit in
> control register :-) If this bit is really handled differently in
> various WM chips, I find this the simplest solution probably...

Exactly what I planned on doing :) - Except I will call it
<invert_24h> :)

[Alexey Charkov]

2012/11/16 <peter...@gmail.com>:
> Forget preferences ;-) I've put internal state saving in, display brightness
> and turning on/off works like a charm.

Can we read hardware state from the enable/disable register instead of
storing a shadow copy, or does that crash as well?

I'm afraid that this in-kernel state tracker may go out of sync with
actual hardware state if we do some sort of suspend/resume or anything
like that.

I also don't quite remember whether our hardware enables/disables PWM
per pin or just kills the whole module at once, disabling all outputs?
If it's the latter, then we probably shouldn't do that at all and just
set duty to 0 per individual pin to avoid negative side effects (i.e.
one may want to disable one output but keep another one running).

Thanks,
Alexey

[Alexey Charkov]

The clock subsystem should do its reference counting internally.

I'm actually inclined to claim that the brightness driver is the faulty one, as it creates asymmetry in enable/disable routines.

On Nov 16, 2012 2:06 PM, <peter...@gmail.com> wrote:

Something else occured to me - how does kernel clock subsystem manages more devices referencing the same clock? If you wanted to use another PWM pin, you'd have to add another section in dts, I suppose, referencing the same clock. Now both PWM devices would call devm_clk_get in their _probe... what would the clock do if one of them called disable, while the other was still running? Could it be the clock system internally handles multiple instances, and only stops the clock if all using devices disabled it? In that case we would only have to avoid writing pwm registers if the clock wasn't enabled, right?

BR,

Peter

[Alexey Charkov]

2012/11/16 <peter...@gmail.com>:
> I can officially confirm clk_disable can stay, internal clock reference
> counting works correctly, disabling one PWM pin doesn't kill the clock if
> there is another device using different (enabled) PWM pin. I've temporarily
> added a second pwm-backlight with <&pwm 1 1000000> reference (lcd has <&pwm
> 0 1000000>), and now PWM clock stays on even if I set lcd brightness to 0
> and pwm-vt8500 calls clk_disable for pwm 0.
> It would seem all we need to do to fix the problem with single pwm is to
> only access the PWM registers if the clock is running. Pity there's nothing
> like clk_is_enabled function, I'll have to find some workaround.

Frankly, I really suppose to draft a small patch reordering the
enable/disable sequence in pwm backlight driver and post it as an RFC
to the relevant mailing lists. I'm reasonably assured that this is the
core of our problem, and I'm also reasonably assured that asymmetric
enable/disable are a sign of bad code.

If this new patch causes problems for any other users, I'd rather
suggest helping their devs fix their use cases, as our driver seems to
behave correctly here.

Peter, could you please check that the problem indeed goes away if we
enable PWM before configuring it?

Thanks,
Alexey

[Tony Prisk]

I'm a little confused by this actually. Looking at the WM8505 and WM8650 vendor source, it appears this has always been wrong in our code :)
Does anyone have the VT8500 source, or a VT8500 unit that confirm whether RTC operation is correct or not?

If VT8500 is working correctly, I'll add an invert property to DT for the other models. If VT8500 doesn't work either, we may as well patch the driver and ignore the invert (since all SoCs are already 'inverted').

I will test WM8505, WM8650 and WM8850 - just need someone to confirm for VT8500.

Regards
Tony P

[Tony Prisk]

The reason _config is before _enable is because you don't want to enable a PWM when you don't know its configured state - _config is before _disable because, well, you can't configure a disabled device. It's a bit of a catch-22 really.

I have figured out why this has become a problem though. When I sent through the last lot of patches, I updated PWM to devicetree and Thierry Reding recommended enabling/disabling the clock during PWM enable/disable to save power - previously the clock was enabled at driver load, and disabled never :)
Hence, we now have this problem.

I think the best fix for us is to enable the clock at driver load again, and disable it if the driver is removed.

Thoughts?

Regards
Tony P

[Tony Prisk]

Any chance we could split this topic up a bit - its getting a little confused with multiple subjects.
Granted it started as a WM8850 topic, but everything getting brought up seems to be common to most models now and with RTC, USB and PWM problems all in one topic is going to be a nightmare finding them again later :)

Maybe the next posts on particular problems could start new topics with a quick 'highlights' section to make these problems more easily referenced later.

Regards
Tony P

[Tony Prisk]

On Fri, 2012-11-16 at 01:58 -0800, peter...@gmail.com wrote:
> Well, simplest way would be to ask if vt8500->clk is enabled, however
> that can only be done by calling internal clock op
> clk->ops->is_enabled, which is unfortunately not easily available - I
> keep getting "dereferencing incomplete type" even if I include right
> header files in pwm-vt8500.c.

Since you're hacking things anyway, struct clk should expose
enable_count from linux/clk-private.h. In pwm_config, you could check if
enable_count > 0, if not, enable the clock, make the required changes in
pwm_config, and disable the clock again.

I'm not certain that enable_count is visible from a struct clk in this
context. You might need to #include <linux/clk-private.h>.

Definately not recommended practice, but it will achieve the desired
result until a proper solution is sorted.

Regards
Tony P

[Tony Prisk]

On Monday, November 19, 2012 1:45:09 AM UTC+13, peter...@gmail.com wrote:

I've done something similar. I include clk-private.h instead of clk.h, and I call clk->ops->is_enabled(clk->hw), only if it's present of course, which on clk-vt8500 always is. Its implementation in clk-vt8500 actually checks the pwm clock bit in PMC, so it should be pretty reliable.

I've added period and duty cycle for each pwm pin into vt8500_chip structure, I'm saving it there on each vt8500_pwm_config. From there it's pretty simple - I only access the registers if clock is enabled, and I call one additional vt8500_pwm_config in vt8500_pwm_enable after enabling the clock but before actually enabling the pwm pin, with period/duty saved from last config call. So the pwm pin should always be enabled with last configured values.

I'm not sure if it's recommended practice, but it's probably the simplest and less "hacked" way to avoid accessing inactive pwm registers while still only starting PWM with valid values. Until anyone thinks of a better way, I consider this issue closed ;-)

BR,

Peter

What I've done in the patch I included in the 'testing' branch is simply add a clk_enable() / clk_disable() to pwm_config(). This ensures that the clock is already running when called via this path. What I wasn't able to test was whether or not the configured parameters actually hold if the clock is disabled after being configured.

If it works, this seems to be a more mainline acceptable method as we won't be allowed to include clk-private.h in a driver. Could you rework your own patch or test the 'testing' branch to see if my method resolves the problem.

Regards
Tony P

[Tony Prisk]

On Monday, November 19, 2012 11:04:02 AM UTC+13, peter...@gmail.com wrote:

Hm, that makes sense if we have to avoid internal clock structures. I've just tried it, looks fine. No crashes, values set in backlight/brightness while bl_power=1 are then activated once bl_power is set back to 0. I can also see the pwm bit enabled for a couple ms while changing brightness value. I can't confirm for certain it's the PWM module keeping the values while disabled though, because backlight driver always calls config after enable.

BR,

Peter

It calls config after enable? I thought the entire problem was that it called config before enable. Either way, if its working it seems like a good patch.
Mind if I add a tested-by: to the patch with your details?

Small note: If you have pulled my 'testing' branch already, you might want to pull the updates - I finally got my WM8850 connected up to a serial port and noticed I forgot to add the 'wm,wm8850' compatible string to vt8500.c so it doesn't boot - fixed now.
I managed to boot up to a login prompt without any issues. SD card was detected during boot, and filesystem is on USB and that ran fine as well. I couldn't actually login to test anything because I forgot to setup a user than can login from serial console.... job for later :)

Regards
Tony P

[Tony Prisk]

On Sun, 2012-11-18 at 23:27 -0800, peter...@gmail.com wrote:
> Oops, my mistake. I forgot to remove my "fix" from pwm-backlight
> driver... will test it later again with original config/enable
> version.
> I have MMC and USB running perfectly, I've also fixed the rounding
> problem in clock frequency, so mmc is running some 48MHz now. I found
> you i2c-wmt patch, that's the next thing I'm gonna try out :-)
>
Huh.. I completely forgot I had even written an I2C driver before. You
can assume its probably untested.

There is also an AC97 driver floating around somewhere (maybe) that I
used for battery monitoring.

The battery voltage is monitored via an ADC on the touchscreen
controller (from memory) but I can't remember which SoC that was on.


Regards
Tony P

[Tony Prisk]

And thanks for reminding me about the device clock problem. I have
pushed a patch for that to 'testing' as well now.

Regards
Tony P

[Tony Prisk]

On Mon, 2012-11-19 at 11:24 -0800, peter...@gmail.com wrote:
> I have just built your testing version with only minor modifications
> (additional dts with display), it runs basically like my customized
> rc5 :-) SD/MMC still only works if I call "mmcinit 0" in uboot before
> booting kernel, and I couldn't get multi-platform configuration to
> work at all, not much surprise there.

Multiplatform is a problem to troubleshoot on WM8850 due to no
earlyprintk and no framebuffer. At present it's not recommended :)

The fact that you need to call mmcinit 0 suggests I need to look at how
we initialize the SD controller. Obviously we are not resetting
something which mmcinit is.

> One thing puzzling me (in all kernels I've tried) is SysRq. I've
> enabled it, it works from netbook keyboard with Alt+SysRq+<key>
> combination, it writes messages to serial console, but I can't invoke
> it from serial console. Break+<key> should work, but nothing happens.
> Perhaps my USB/uart module doesn't translate Break correctly. Well,
> that's just a minor nuissance.
>
I have no idea about this - I can write code.. I have minimal knowledge
of the workings of linux :)

Regards
Tony P

[Tony Prisk]

On Mon, 2012-11-19 at 12:31 -0800, peter...@gmail.com wrote:
> Hi, a little problem in your testing wm8850.dtsi:
>
>
> clkpwm: pwm {
> #clock-cells = <0>;
> compatible =
> "via,vt8500-device-clock";
> clocks = <&pllb>;
> divisor-reg = <0x348>;
> enable-reg = <0x250>;
> enable-bit = <10>;
> };
> clksdhc: sdhc {
> #clock-cells = <0>;
> compatible =
> "via,vt8500-device-clock";
> clocks = <&pllb>;
> divisor-reg = <0x328>;
> divisor-mask = <0x3f>;
> enable-reg = <0x254>;
> enable-bit = <18>;
> };
>
>
> should actually be:
>
>
> clkpwm: pwm {
> #clock-cells = <0>;
> compatible =
> "via,vt8500-device-clock";
> clocks = <&pllb>;
> divisor-reg = <0x350>;
> enable-reg = <0x250>;
>
> enable-bit = <17>;
> };
> clksdhc: sdhc {
> #clock-cells = <0>;
> compatible =
> "via,vt8500-device-clock";
> clocks = <&pllb>;
> divisor-reg = <0x330>;
> divisor-mask = <0x3f>;
> enable-reg = <0x250>;
> enable-bit = <0>;
> };
>
>
> - see apc-8750 arch/arm/mach-wmt/wmt_clk.h/.c
> I'll have to check if other settings are ok...
> For backlight the problem is clear, display shows anything only on
> maximum brightness, though sd/mmc works even with your settings
> (perhaps the default setting in correct divisor is good enough?)

I can't explain why the PWM is not working even with the wrong clock
source. Given that PWM is a duty based adjustment, it should really work
with any clock source. Either way - it's wrong and I'll fix it.

The SD controller makes more sense. Given that both the divisor and
enable registers are wrong, it is simply running on the uboot
initialized clock, and changes in the driver are having no effect on the
SD controller - When the driver sets 400Khz, it just stays at whatever
uboot left it as. Will also fix this :)

Thanks for the feedback. Fixes will be pushed in 5 minutes :)

Regards
Tony P

[Tony Prisk]

Just took a look at the uboot mmcinit. I'm not sure how we could replicate its behaviour as it configures all the SD pins as GPIO's, then sets them low, does some pullup/down configuration and then set's them back to SD pins (rather than GPIO).
This would require us to have a working pinmux driver and to reconfigure the DTS-defined pinstates in the SD driver which seems like it could be a bit naughty.
Best advice is to stick with mmcinit in uboot at the moment, and I'll look back to this another day when more important things are sorted out.

Regards
Tony P

[Tony Prisk]

On Tue, 2012-11-20 at 00:03 -0800, peter...@gmail.com wrote:
> PWM also has a problem with period time you set in DTS for backlight
> driver, it appears it was too short for hardware to handle. I have
> changed it to:
>
>
> lcd {
> compatible = "pwm-backlight";
> pwms = <&pwm 0 1000000>;
> brightness-levels = <0 6 11 16 32 48 64 96 128
> 192 255>;
> default-brightness-level = <5>;
> };
>
>
> With this period and brightness levels the display goes from
> completely off to full brightness in visually more or less equal steps
> (at least on my hardware).
>
>
> I also found out what causes the console scrolling problems in
> (hacked) framebuffer driver - it's the copyarea/fillrect hardware
> acceleration from wmt_ge_rops. Apparently that doesn't work quite as
> it should, either. When I disabled harware panning acceleration and
> replaced wmt_ge_fillrect with sys_fillrect and wmt_ge_copyarea with
> sys_copyarea, scrolling now works flawlessly. I'll have to verify if
> both functions need this fallback - it would seem wmt_ge_copyarea was
> actually working, only fillrect didn't clear the bottom line.
> I have tried to play with graphics registers a bit, apparently we're
> missing something. When I dumped the whole 64k @ 0xd8050000 with
> vendor kernel running, there have been a lot of values all over the
> place (in VPU registers, but also GOVM, GE1, GE2, GE3, both GOVR, DISP
> and SCL bases and LVDS - see arch/arm/mach-wmt/include/mach/wmt_mmap.h
> in apc-8750 sources). With our kernel there are mostly zeroes
> everywhere, except very few places in SCL base2, both GOVR bases, VPP
> and LVDS. Something somewhere is resetting the whole graphics
> subsystem (perhaps clocks reset?), and I'm afraid it's gonna be a lot
> more work to get it running again.
> BR,
> Peter
>
I think you'll find the difference is that the vendor kernel fb driver
is initializing more than we do because it supports more than we do :)
Our driver only supports LCD which is run from GOVR.

It would be interesting if you booted up our kernel without the
fb/ge_rop drivers, and then dumped the 0xd8050000 block. This would give
the registers that uboot configured.

Also, your result is interesting in itself. I remember dumping the
registers using the method I just described and (from memory) only a few
sub-systems were initialized. Attached is my dump from whenever I did it
- It shows the register values after uboot configures them but nothing
else has touched them, without HDMI attached.

Regards
Tony P

[Alexey Charkov]

Note that you can also dump registers using u-boot commands via serial console (from what I remember, 'md' displays and 'md' writes memory contents).

Best,
Alexey

[Tony Prisk]

On Tue, 2012-11-20 at 12:34 -0800, peter...@gmail.com wrote:
> Yup, precisely my idea :-) Here are the dumps. Most uboot dumps were
> made directly after entering command line, so only basic
> initialisation has been done (display was already showing standard
> boot logo). The d811-after-mmcinit is the only one done after calling
> "mmcinit 0" (I want to check the changes to GPIO configuration). There
> are also PMC register dumps from both uboot and vendor kernel.
> BR,
> Peter

One thing that looks interesting is the 'extended' graphics space. I
never thought about dumping beyond d8051FFF.

Down around d8051700..d80518ff it appears to be another configuration
space similar to the GOVRH registers at d8050800..d80509FF.

I can't see any source reference to what this could be but it seems to
be almost register-perfect with GOVRH_BASE(1/2).

Peter, as a test, could you try writing 0's to that memory (d8051700...)
and see if it has any effect on the LCD.

Regards
Tony P

[Tony Prisk]

confirmed working :)
The existing driver works fine if you change the dts address to 0xd8051700.

        fb@d8051700 {
            compatible = "wm,wm8505-fb";
            reg = <0xd8051700 0x200>;
            display = <&display>;
            default-mode = <&mode0>;
        };

        ge_rops@d8050400 {
            compatible = "wm,prizm-ge-rops";
            reg = <0xd8050400 0x100>;
        };

I guess the WM8850 has two GOVRH modules or something :)
Thanks for the dump Peter, you found the missing piece of the puzzle.

Regards
Tony P

[Alexey Charkov]

2013/3/31 <the.rea...@googlemail.com>:
> Hello, i have recently followed your conversation. Did you manage to build
> an working Image for the WM8850? And if yes could you upload a ZIP to
> prepare a SD-Card or how do you boot it and test?

You may find this wiki page useful:

http://sourceforge.net/p/linuxwmt/wiki/Build/

It is a bit outdated, because the most recent code is currently in
mainline Linus' kernel, plus some bleeding edge testing stuff that is
available directly from Tony's own server. If anything here appears to
be radically wrong, please let us know (updating the documentation is
probably a good idea too).

Best,
Alexey