Wm8880 Dual-CortexA9

[Tony Prisk]

I got one of these tablets today - unfortunately on disassembling it, I can't see a serial port/uart connection.
Slightly disappointing.

I will drop the board out and photograph it so I can get a better look - There are a few GPIO pads exposed, and a lot of testpoints for voltages.

Regards
Tony P

[Tony Prisk]

Not having a lot of luck - Had a play with the tablet on vendor firmware and it doesn't seem too bad (although 512MB memory is definitely a limiting factor).
One thing that doesn't seem to be working is the USB. If I connect it to my PC, it refuses to accept an address and fails. If I used HOST mode, it doesn't seem to detect the USB Flash Disk that is attached.

Still haven't located a uart header, although there is a 7 or 8 pin header (well, pads) on the back of the board which could be a possibility (several pins all routed back to the WM8880 in a bus-like fashion).

Looks like it now has a GIC (interrupt controller). I have done some quick updates on the WIKI to show what I've found.

Regards
Tony P

[Tony Prisk]

Still no luck finding the UART output...

I have confirmed that the vendor kernel has support for UART0..3 - found the memory space and irq's for them.
GPIO memory space doesn't seem to have changed (0xD8110000)
Serial Flash, EHCI, UHCI, NAND Flash, SD/MMC Controller, PWM, SPI 0 and I2C all seem to be located in the same IO space as well.

There is a new I2C3 (@ 0xD83B0000) and I2C4 (disabled on my board so I don't know where it is yet).

Finding the GIC has proven difficult as well - without it, getting even serial console working will be difficult.

Also, it appears there are some clock tricks going on again (or still).
Checking the PLL's, I see the kernel reading PLLB=700Mhz.

Testing this against the WM8850 PLL formula gives the expected results - A 24Mhz source clock.

When my tablet is idle, I get a PLLA=600Mhz (which is the lowest cpufreq frequency).
When running Antutu CPU benchmark though, it only jumps up to PLLA=800Mhz.

I also noticed that my result from Antutu is ~9000, whereas the screenshots posted on 1pad.cn show ~11000. When I compared them, it appears the only difference is in the 3D performance. Looking through dmesg I see an error for "please add mbsize=73M to kernel commandline". Guess someone didn't test it very well ;) Something to fix when I get uboot access.

Regards
Tony P

[Tony Prisk]

Found the UART pins finally - looks like the 8 pin pads on the bottom of the board are a sort of multifunctional input.
With a bit of board tracing, the first two pins are the UART tx/rx.
The other pins are other functions, one of which appears to be for for rewriting the serial flash.
Annoyingly, they are high density so I will need to get some enamel wire before I can put a header on them - Then I'll be able to finally see why the kernel isn't booting :)

Regards
Tony P

[Marius Cirsta]

I wonder what you mean by high density. I've seen some which weren't
to far spaced but maybe this is even worse. I also need to practice my
soldering skills and probably get a finer tip for my soldering iron.

This is a very interesting SOC by Via (Wondermedia) though and it
appears to have some pretty decent performance for the price.

I'm curious as to what you find has changed. A netbook powered by
this SOC should be actually useful with 1GB of RAM, maybe even with
512.

> Regards
> Tony P
>
> --
> You received this message because you are subscribed to the Google Groups
> "VT8500/WM8505 Linux Kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vt8500-wm8505-linux...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Tony Prisk]

The pins are 0.5mm spaced. I soldered some 0.25mm enamelled wire on them and confirmed they work - Being a bit stupid, I didn't glue the wires and after half an hour or so I managed to pull the pad off the board so that pretty much ends any debugging I can do on the WM8880.

Regards
Tony P

[J T Dsouza]

I normally loop such wires thru a hole on the board.

I normally loop such wires thru a hole on the board.
 

[Marius Cirsta]

Sorry to hear that. I meant to tell you I normally use a hot glue gun
to secure everything in place but for some reason I didn't. I learned
my lesson the hard way too so don't worry too much about it. I'm
waiting for netbooks based on the WM8880 to appear and I'll grab one
then. Those tend to have proper through holes for UART.

[Tony Prisk]

>> email to vt8500-wm8505-linux-kernel+unsub...@googlegroups.com.

>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "VT8500/WM8505 Linux Kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to vt8500-wm8505-linux-kernel+unsub...@googlegroups.com.

> For more options, visit https://groups.google.com/groups/opt_out.
>
>

The one thing I wasn't able to locate was the timer's.
The existing timer appears to still be there, but I couldn't find the interrupt (or the GIC isn't setup correct in my tests).
The local timers required for SMP I was completely unable to identify. The TWD driver requires a PPI interrupt, but the vendor kernel appears to assign IRQ 29 to the TWD (which is outside the PPI range).

Both these are required to get a booting SMP kernel as far as I can tell.

Regards
Tony P

[eeb...@gmail.com]

Hey Tony, Thanks for all the hard work you are putting into unravelling this thing, could you point me to the wiki you mention a few posts down? I want to attempt to catch up before making any daft queries

[Tony Prisk]

It's been a while since I meantioned anything, but I assume it would be the main wiki on github, which you can find here:

https://github.com/linux-wmt/linux-vtwm/wiki

Regards
Tony P

[Afonso Bordado]

I apoligize in advance if this is not an apropriate question for this group, but where are we now with the port to the WM8880? is it bootable? how stable is it? i have experience with sunxi devices and im confortable building kernel for such devices, i assume the WM8880 can boot from SD and it has priority over nand boot, im asking all this because im thinking about buying a wm8880 netbook. Thanks for your help

[Alexey Charkov]

2014-03-23 15:14 GMT+04:00 Afonso Bordado <afonso...@gmail.com>:
> I apoligize in advance if this is not an apropriate question for this group,
> but where are we now with the port to the WM8880? is it bootable? how stable
> is it? i have experience with sunxi devices and im confortable building
> kernel for such devices, i assume the WM8880 can boot from SD and it has
> priority over nand boot, im asking all this because im thinking about buying
> a wm8880 netbook. Thanks for your help

Hi Alfonso,

There is no ready-to-use support for 8880 that I would know about. It
might be as simple as adding a device tree pointing to GIC and all the
WM-specific peripherals, but I'm not sure. Most likely it's not.

I got myself a WM8880 netbook for hacking, but still no time for that...

Best,
Alexey

[Ring Zero]

Any body working on wm8880 ?
I have been trying to compile this kernel for wm8880 netook, but it failed over and over again.
I did not know that this wont work !

[Alexey Charkov]

2014-05-14 16:23 GMT+04:00 Ring Zero <ring...@gmail.com>:
> Any body working on wm8880 ?
> I have been trying to compile this kernel for wm8880 netook, but it failed
> over and over again.
> I did not know that this wont work !

Tony looked into it a while ago and documented some of the hardware
internals in his wiki on Github, but there is no ready to use code for
it. It's a bit tricky without kernel sources, and I haven't seen any
WonderMedia code for wm8880...

On the other hand, the GIC (interrupt controller) is a pretty standard
block with existing support upstream, and Tony has apparently found
its MMIO location, so it might be not that hard in the end.

I've got a WM8880-based netbook collecting dust and waiting for
attention, but so far I was rather concentrated on getting more stuff
working on WM8850 (currently trying to figure out if I can make a
proper DRM/KMS driver for it - this would then allow for proper
dual-head support, hardware-accelerated blending, blitting, scaling,
color space conversions and what not).

Best,
Alexey

[funt...@gmail.com]

I currently own a WM8880 tablet with 512mb ram , I'd like to try and help with this but I don't have the skills and tools to do it. I'm thinking of buying the WM8880 Netbook with 1gb ram when it hits the local shop.

[Alexey Charkov]

2014-06-09 1:13 GMT+04:00 <funt...@gmail.com>:
> I currently own a WM8880 tablet with 512mb ram , I'd like to try and help with this but I don't have the skills and tools to do it. I'm thinking of buying the WM8880 Netbook with 1gb ram when it hits the local shop.

The first steps are to make interrupts work (GIC in this case), and
then get the system timer up and running (as the scheduler relies on
that). Encode all of that into a device tree - and you'll already get
a pretty much functional device, as we already have drivers for USB,
SD/MMC, Ethernet and framebuffer.

Have you got a serial console connection to your device?

Best,
Alexey

[Marius]

Well I have some good news. I've just ordered a WM8880 netbook ( 10 inch , 1 GB RAM and 8 GB flash ) but the really good news is that while looking for the source code I've actually found the code for the Via Rock II which has a WM8880 SOC.
Source are available here :  https://github.com/apc-io/apc-rock-II

I'm not really that experienced in kernel devel but I think this can be a good starting point.

  

[Tony Prisk]

Thanks for this. I don't have time at the moment to integrate it into our source but I have updated the wiki to include/correct the info for WM8880 if someone else wants to have a go.... I expect it should be pretty simple since most of the code is already written - it just needs someone to create a devicetree file and add a build option for the WM8880 since it needs GIC support.

Regards
Tony Prisk

--
You received this message because you are subscribed to the Google Groups "VT8500/WM8505 Linux Kernel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vt8500-wm8505-linux...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alexey Charkov]

On 29 Jun, 2014 1:37 am, "Tony Prisk" <li...@prisktech.co.nz> wrote:
>
> Thanks for this. I don't have time at the moment to integrate it into our source but I have updated the wiki to include/correct the info for WM8880 if someone else wants to have a go.... I expect it should be pretty simple since most of the code is already written - it just needs someone to create a devicetree file and add a build option for the WM8880 since it needs GIC support.

Plus also write a couple of init-time functions to bring up the secondary CPU and let it know its entry point (I guess).

It's pretty great to have the sources, thanks for the heads up!

Best,
Alexey

[Tony Prisk]

--

You received this message because you are subscribed to the Google Groups "VT8500/WM8505 Linux Kernel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vt8500-wm8505-linux...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

I have done a bit of work on getting this up and working with limited results.
The GIC is working - timer interrupts are firing etc.

I'm not bothering with multiprocessor until I can get uP working properly.
At the moment, it seems to hang when it initializes the serial port - I disabled the DT entry for serial port, and it hangs setting the system clock (from the RTC).

I have to go out for the afternoon (family time) but will try to troubleshoot this later tonight, and get something working this week for people to try out.


Regards
Tony P

[Marius]

 Well my WM8880 based netbook has just arrived it's got 1GB RAM and 8GB of flash. 
 Going to play with its Android for a while but I'm willing to test some Linux too.
 I might even take it apart and solder some UART but just not yet, it's new :D

 Let me know.

 

On Sunday, July 13, 2014 1:44:11 AM UTC+3, Tony Prisk wrote:

On 30/06/14 01:51, Alexey Charkov wrote:

On 29 Jun, 2014 1:37 am, "Tony Prisk" <li...@prisktech.co.nz> wrote:
>
> Thanks for this. I don't have time at the moment to integrate it into our source but I have updated the wiki to include/correct the info for WM8880 if someone else wants to have a go.... I expect it should be pretty simple since most of the code is already written - it just needs someone to create a devicetree file and add a build option for the WM8880 since it needs GIC support.

Plus also write a couple of init-time functions to bring up the secondary CPU and let it know its entry point (I guess).

It's pretty great to have the sources, thanks for the heads up!

Best,
Alexey

--
You received this message because you are subscribed to the Google Groups "VT8500/WM8505 Linux Kernel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vt8500-wm8505-linux-kernel+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Alexey Charkov]

Has anyone had chance to clone that repo? I can't find it anymore,
looks like it's been taken down.

Thanks,
Alexey

[Gergely Imreh]

I asked the team, and the repo is coming back online soon. Apparently
they took down to fix a bunch of reported compile errors. It's just
not being used to developing on Github, and using Issues. Asked them
not to take a repo private the next time, because that confuses
everyone.

Cheers,
Greg

[Azmi Raman]

That's a relief, my WM8880 is still here for testing purpose

> --
> You received this message because you are subscribed to a topic in the

> Google Groups "VT8500/WM8505 Linux Kernel" group.

> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/vt8500-wm8505-linux-kernel/yyf6aQaY0MQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> vt8500-wm8505-linux...@googlegroups.com.

[Alexey Charkov]

Hi Tony!

Is there any chance you could share your latest device tree for
WM8880? Mine currently hangs at "Calibrating delay loop", and the TWD
doesn't want to register either (-EINVAL), which makes me think that
I'm doing something wrong with the GIC...

Thanks a lot,
Alexey

[Tony Prisk]

DTS and DTSI files attached for WM8880.

Here is the diff - its pretty simple so you should be able to mod it
without a patch :)
I never bothered with the TWD, and was unable to get any of the
peripheral devices working properly (although I didn't do a lot of
investigating).
I think the attached -forfun.dts is bootable, but not sure :/


diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index adb5ed9..528b136 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -418,7 +418,8 @@ dtb-$(CONFIG_ARCH_VT8500) += vt8500-bv07.dtb \
wm8505-ref.dtb \
wm8650-mid.dtb \
wm8750-apc8750.dtb \
- wm8850-w70v2.dtb
+ wm8850-w70v2.dtb \
+ wm8880-forfun712.dtb
dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \
zynq-zc706.dtb \
zynq-zed.dtb
diff --git a/arch/arm/mach-vt8500/Kconfig b/arch/arm/mach-vt8500/Kconfig
index aaaa24f..056c0ff 100644
--- a/arch/arm/mach-vt8500/Kconfig
+++ b/arch/arm/mach-vt8500/Kconfig
@@ -27,3 +27,12 @@ config ARCH_WM8850
select ARCH_VT8500
help
Support for WonderMedia WM8850 System-on-Chip.
+
+config ARCH_WM8880
+ bool "WonderMedia WM8880"
+ depends on ARCH_MULTI_V7
+ select ARCH_VT8500
+ select ARM_GIC
+ select HAVE_ARM_TWD if SMP
+ help
+ Support for WonderMedia WM8880 System-on-Chip.
diff --git a/arch/arm/mach-vt8500/vt8500.c b/arch/arm/mach-vt8500/vt8500.c
index 4a73464..a713a6a 100644
--- a/arch/arm/mach-vt8500/vt8500.c
+++ b/arch/arm/mach-vt8500/vt8500.c
@@ -168,6 +168,7 @@ static const char * const vt8500_dt_compat[] = {
"wm,wm8505",
"wm,wm8750",
"wm,wm8850",
+ "wm,wm8880",
NULL
};


Regards
Tony P

[Alexey Charkov]

Ok, so physical interrupt numbers are actually 68-32=36, rather than
68 directly... Thanks a lot, that explains much :)

Best,
Alexey

[Alexey Charkov]

Tony, looking at your DTSI, it seems that you set interrupt flags to
IRQ_TYPE_NONE (0) for all peripherals. Was it just a guess, or did you
refer to any specific source for that?

I seem to be able to get a little bit past the RTC initialization with
IRQ_TYPE_LEVEL_HIGH (4), but it hangs right after UART init if I leave
that enabled. And the screen goes bananas at that point, which seems
to imply some hardware issue like clock misconfiguration or similar...

Also tried to replace direct reference to IRQ resource within the
serial driver with a call to platform_get_irq which does more
OF-specific parsing, but that didn't change anything noticeably.

By the way, TWD seems to work (at least it calibrates successfully at
~400 lpj): PPI 13, GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH

Best,
Alexey

[Tony Prisk]

I probably just put a number in the field without checking it - I was
just happy to get it booting past the calibration loop :)
From memory, every device seemed to cause a lockup / freeze when probed
and I never got a chance to look into it - possibly its a clock problem
- you could just as easily // out the clock code so it is called but
doesn't do anything.

Regards
Tony P

[Alexey Charkov]

I've had a look at what the stock kernel puts into GIC registers, and
it sets all SPI interrupts to level-triggered. Maybe that 0 flag
(IRQ_TYPE_NONE) just makes the code skip re-configuration, so it might
work just as well with power-up defaults (but haven't checked that).

> From memory, every device seemed to cause a lockup / freeze when probed and
> I never got a chance to look into it - possibly its a clock problem - you
> could just as easily // out the clock code so it is called but doesn't do
> anything.

Yep, looks like that's the next candidate on the list (can't think of
anything else wrong with interrupts).

When you looked at the vendor's clock code, was there anything fishy?
The wiki table (clock registers) seems to be pretty much the same for
WM8880 as it is for WM8850, but I seem to vaguely remember some
weirdity in WMT timer code at least (it had several clocksources
defined with different tick rates, but then only one was used AFAIR).
So maybe the overall hierarchy changed somehow...

Thanks a lot,
Alexey

[Alexey Charkov]

Got my WM8880 to boot (almost). Current issues:

1. UART dies somewhere during termios setting
2. Again some weirdity with contrast (apparently)
3. Waits forever for the root FS on SD card

But RTC works, USB works, screen shows stuff. Can share current
DTS+DTSI if anyone is interested - otherwise will investigate the SD
issue first.

Best,
Alexey

[Tony Prisk]

Booting both cores?

I wouldn't be surprised if UART died - I think that was the problem I
decided I had when I thought everything was working but there was no
output on console. There has always been that issue with the UART
losing/corrupting data - maybe it is worse with dual core :)

Waiting forever could be a sign that the delay calibration was
inaccurate - what value did it return?
It could also be a sign that the SD card doesn't become ready - I think
there is some code in the SD driver which may never 'fall through' on
errors because the timeout/error never occurred.


Regards
Tony P

[Alexey Charkov]

Not yet. Just one core for now, but in an SMP kernel and with TWD
enabled. I hadn't taken note of the register to put the secondary
core's starting vector before our Chinese friends took down the APC
Rock II sources, and it's kind of tricky to find that by reverse
engineering.

> I wouldn't be surprised if UART died - I think that was the problem I
> decided I had when I thought everything was working but there was no output
> on console. There has always been that issue with the UART losing/corrupting
> data - maybe it is worse with dual core :)

I'm now reasonably assured that that bug is due to a missing spinlock
in the console write function. MSM serial has one there, and our
driver doesn't. Haven't yet had chance to verify / fix that, though.

Don't think it's related to the current issue, though - more likely
there've been some changes to how the FIFO mode is handled. Or maybe
they simply increased FIFO sizes / changed offsets, which would mean
that we put data in a wrong place.

Good thing, though, is that clocks seem to actually work fine (they
would be pretty hard to debug otherwise).

> Waiting forever could be a sign that the delay calibration was inaccurate -
> what value did it return?

The main timer was around 1600 lpj, and the local timer around 400
lpj. Not sure why there's such a difference, but I haven't watched ARM
local timers closely anyway (or at all).

> It could also be a sign that the SD card doesn't become ready - I think
> there is some code in the SD driver which may never 'fall through' on errors
> because the timeout/error never occurred.

Well, given that I boot from the same very SD card, it shouldn't take
a whole lot of time to initialize IMO... WMT blob now spits out some
messages involving SDXC, so it might be the case that the SD
controller got upgraded too (in some incompatible way).

To be fair, it's not waiting "forever" - it waits for 120 seconds,
after which the kernel just kills the thread as unresponsive. During
which time I can fully enjoy typing stuff on the netbook's keyboard
(which is USB connected), and it appears happily on screen :)

Best,
Alexey

[Gergely Imreh]

On 15 August 2014 14:40, Alexey Charkov <alc...@gmail.com> wrote:

2014-08-15 9:05 GMT+04:00 Tony Prisk <li...@prisktech.co.nz>:

>
> On 15/08/14 08:36, Alexey Charkov wrote:

>> Got my WM8880 to boot (almost). Current issues:
>>
>> 1. UART dies somewhere during termios setting
>> 2. Again some weirdity with contrast (apparently)
>> 3. Waits forever for the root FS on SD card
>>
>> But RTC works, USB works, screen shows stuff. Can share current
>> DTS+DTSI if anyone is interested - otherwise will investigate the SD
>> issue first.
>>
>> Best,
>> Alexey
>>
> Booting both cores?

Not yet. Just one core for now, but in an SMP kernel and with TWD
enabled. I hadn't taken note of the register to put the secondary
core's starting vector before our Chinese friends took down the APC
Rock II sources, and it's kind of tricky to find that by reverse
engineering.

Taiwanese but I digress. :)
I bugged the APC team until they made the repository public again ahead of schedule, it's back at https://github.com/apc-io/apc-rock-II I've also made a form of it at https://github.com/viaembedded/apc-rock-II so if they take the original private again for whatever reason, the fork should stay up.

Sorry about the trouble, hope this will be somewhat helpful for the coming weekend. It's exciting to see this much progress made!

 

Best,
Alexey

[Alexey Charkov]

2014-08-15 13:01 GMT+04:00 Gergely Imreh <imr...@gmail.com>:
>
> On 15 August 2014 14:40, Alexey Charkov <alc...@gmail.com> wrote:
>>
>> 2014-08-15 9:05 GMT+04:00 Tony Prisk <li...@prisktech.co.nz>:
>> >
>> > On 15/08/14 08:36, Alexey Charkov wrote:
>> >> Got my WM8880 to boot (almost). Current issues:
>> >>
>> >> 1. UART dies somewhere during termios setting
>> >> 2. Again some weirdity with contrast (apparently)
>> >> 3. Waits forever for the root FS on SD card
>> >>
>> >> But RTC works, USB works, screen shows stuff. Can share current
>> >> DTS+DTSI if anyone is interested - otherwise will investigate the SD
>> >> issue first.
>> >>
>> >> Best,
>> >> Alexey
>> >>
>> > Booting both cores?
>>
>> Not yet. Just one core for now, but in an SMP kernel and with TWD
>> enabled. I hadn't taken note of the register to put the secondary
>> core's starting vector before our Chinese friends took down the APC
>> Rock II sources, and it's kind of tricky to find that by reverse
>> engineering.
>
> Taiwanese but I digress. :)

Note taken ;-)

> I bugged the APC team until they made the repository public again ahead of
> schedule, it's back at https://github.com/apc-io/apc-rock-II I've also made
> a form of it at https://github.com/viaembedded/apc-rock-II so if they take
> the original private again for whatever reason, the fork should stay up.
>
> Sorry about the trouble, hope this will be somewhat helpful for the coming
> weekend. It's exciting to see this much progress made!

Thanks a lot, Greg, much appreciated. This would at least help us
figure out what's been changed in the hardware relative to previous
revisions, as well as find those undiscoverable bits like secondary
CPU boot vector.

To me, those kernel archives are more of an information source rather
than something to build and use anyway (kind of a fallback solution to
hardware documentation). I've personally never dared to try compiling
WMT sources after some miserable failures back in vt8500 days with an
2.6.10 archive :)

Thanks a lot,
Alexey

[Tony Prisk]

Sounds like what I do Alexey :)

I wouldn't know if the WMT sources we have seen have ever compiled - I
prefer to read through them and reverse them into documentation that
everyone else can understand :)

Nice to see the Rock-2 repo back up as well - good work.

[Tony Prisk]

Just did a quick browse of the rock-ii repo and reminded myself that the
WM8880 clocks appear to be (at least bit-wise) compatible with the WM8850.

Per the WMT source code, DF, DR and DQ seem to have the same valid
values and are applied with the same formula as WM8850 which is why I
didn't update anything on the wiki about them. A lot (maybe all?) of the
enable bits are also common.

Also, regarding the UARTS - they run from a fixed clock, and only have
enable/disable - so there is no reason why the clocks would cause them
to stop working during bootup - unless they are being disabled :)

The SMP bootup code looks less than ideal, but at least the necessary
info is there to bring up the secondary processor.

Regards
Tony P

[Alexey Charkov]

As a heads-up: just discovered that not everything is rosy with
interrupts. Almost finished booting into a Fedora image on a USB stick
and got a kernel panic in some per-cpu interrupts from EHCI.

Looks like my TWD attempted to interrupt the secondary CPU, which is
unconfigured. Or maybe it's something totally different...

Will try disabling TWD altogether for now.

Best,
Alexey

[Alexey Charkov]

2014-08-16 14:57 GMT+04:00 Alexey Charkov <alc...@gmail.com>:
> As a heads-up: just discovered that not everything is rosy with
> interrupts. Almost finished booting into a Fedora image on a USB stick
> and got a kernel panic in some per-cpu interrupts from EHCI.

I've somehow managed to boot my WM8880 netbook properly into a Fedora
20 root fs (without really fixing anything that could have caused the
panic before - just updated the kernel).

Fun fact: my device has a Realtek 8152 USB to Ethernet adapter onboard
instead of on-chip Rhine or Velocity (a driver is available upstream,
though). Sad fact: it's actually less reliable than the good old parts
:)

Another fun fact: it seems that built-in WiFi is no longer
USB-connected. Must be SDIO instead.

Sounds like it's going to be lots of fun in the end...

Best,
Alexey

[thebatma...@gmail.com]

I just want to ask, as of now, what is working in this latest build? And what do you know doesn't work. I'm considering to get one of these devices to tinker with, but I want to get something that is barely supported and can only sit on my desk wasting power. Nice work getting it booting, though.

[Alexey Charkov]

2014-08-20 17:05 GMT+04:00 <thebatma...@gmail.com>:
> I just want to ask, as of now, what is working in this latest build? And what do you know doesn't work. I'm considering to get one of these devices to tinker with, but I want to get something that is barely supported and can only sit on my desk wasting power. Nice work getting it booting, though.

I've just figured out booting the second CPU core yesterday, but
haven't tested it thoroughly (beyond it just booting and showing both
CPU's). The latest code is available on Github, "testing-smp" branch.

USB works (including keyboard, touchpad and onboard USB Ethernet
adapter), framebuffer-based graphics works for the internal display.

SD/MMC doesn't work yet. WiFi doesn't work yet, as it seems to be
SDIO-based in my netbook (thus requires SD/MMC controller to work).
Built-in UART ports don't yet work other than for the "early console".
I also used to get kernel panics due to failing per-cpu interrupts
from EHCI, but my theory is that those were due to missing secondary
CPU (which is no longer missing).

Plus the common stuff that is still missing for all WonderMedia's:
sound, graphics/video acceleration, NAND flash, suspend/resume
support, battery level indication and other minor things.

So in case you have an SD card (for scriptcmd+uImage) AND a USB stick
(for root fs), you can definitely start tinkering with WM8880 :)

Best,
Alexey

[Azmi Raman]

I wonder if it will work on a WM8880 tablet, I have a spare wm8880 tablet for testing.

--
You received this message because you are subscribed to a topic in the Google Groups "VT8500/WM8505 Linux Kernel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vt8500-wm8505-linux-kernel/yyf6aQaY0MQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vt8500-wm8505-linux...@googlegroups.com.

[Alexey Charkov]

Why not. I'm just not sure about the touchscreen, unless it's also
USB-connected.

> You received this message because you are subscribed to the Google Groups
> "VT8500/WM8505 Linux Kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an

[Cray Ze]

Nice progress, I've got a nice new netbook waiting for linux.
I'll see if I can get a Gentoo userspace up and running, might look at some of these missing peripherals as well.

The netbook I bought is one of the 13.3" MacBook Air clones that have recently started to show up on alliexpress and similar sites.

Serial port is clearly marked on the circuit board, which is nice. I took a couple pictures of the board for anyone that's contemplating one of these for development.
http://aciai.me/PEW
http://aciai.me/PEs

[Alexey Charkov]

2014-08-20 21:39 GMT+04:00 Cray Ze <cray....@gmail.com>:
> Nice progress, I've got a nice new netbook waiting for linux.
> I'll see if I can get a Gentoo userspace up and running, might look at some
> of these missing peripherals as well.

Did some more hands-on testing - it still crashes like crazy. Can't
read the full backtrace on screen, so will need to fix UART first of
all to get full console output...

Best,
Alexey

[Cray Ze]

The best I can get is a black screen when I try to boot from SDcard, I'll have to look at it again after some sleep.

Netconsole might get you around the broken UART for now.

Enable netconsole in the kernel as a built-in: Device Drivers > Network device support >  Network console logging support

Add to kernel command line in scriptcmd (xxx... = Netbook / yyy... = DevPC):
netconsole=66...@xxx.xxx.xxx.xxx/eth0,66...@yyy.yyy.yyy.yyy/

Run nc on development machine:
nc -l -u -p 6666

[Alexey Charkov]

2014-08-21 2:32 GMT+04:00 Cray Ze <cray....@gmail.com>:
> The best I can get is a black screen when I try to boot from SDcard, I'll
> have to look at it again after some sleep.
>
> Netconsole might get you around the broken UART for now.
>
> Enable netconsole in the kernel as a built-in: Device Drivers > Network
> device support > Network console logging support
>
> Add to kernel command line in scriptcmd (xxx... = Netbook / yyy... = DevPC):
> netconsole=66...@xxx.xxx.xxx.xxx/eth0,66...@yyy.yyy.yyy.yyy/
>
> Run nc on development machine:
> nc -l -u -p 6666

Thanks for the pointer! Didn't think about that.

On a side note, I've now figured out why UART freezes: they've added
another bit in URLCR (bit 11), which now controls software/hardware
RTS/CTS handling. Needs to be set to 1 to let the kernel driver handle
RTS/CTS - otherwise it apparently waits for hardware flow control
lines to toggle before sending anything (without consulting the kernel
driver at all).

Will publish a patch for that once I confirm that it doesn't break
older chips if set unconditionally.

Best,
Alexey

[Tony Prisk]

Alexey,

You should probably add a new compatible string, and use it as a match
for setting that bit - rather than relying on undocumented behaviour to
not break things :)

Since port is already wrapped inside vt8500_port, you could just add a
boolean variable and set it if the dts uses the new compatible string.

Just a thought

Regards
Tony P

[Alexey Charkov]

Makes sense. Could be some "flags" attribute within OF match table data...

By the way, it seems to stop crashing once I disable all the SMP stuff
(CPU1 and TWD). So I'll probably park that for now, until the more
interesting stuff is settled (like SD/MMC, for instance).

Best,
Alexey

[Alexey Charkov]

The patch for UART as mentioned (attached). Requires "wm,wm8880-uart"
as the compatible string instead of "via,vt8500-uart".

Testers welcome :)

Best,
Alexey

[Cray Ze]

I believe I'm stuck, cant make it past "Starting kernel ...", I don't get the decompressing message.

I'm starting with an up to date pull of the testing branch with all files and patches from this thread applied, and following the 'Build-the-source' page on github (selecting WM8880).
Serial console is configured via console=ttyS0,115200n8 on the command line.

Is my tool-chain likely to be a problem? Gentoo crossdev generated (armv7a-hardfloat-linux-gnueabi-). I've used it on Allwinner devices and various router SOCs without any issues at all.

Any advice as to where I should be looking for the problem?

[Alexey Charkov]

On 31 Aug, 2014 1:26 pm, "Cray Ze" <cray....@gmail.com> wrote:
>
>
> I believe I'm stuck, cant make it past "Starting kernel ...", I don't get the decompressing message.
>
> I'm starting with an up to date pull of the testing branch with all files and patches from this thread applied, and following the 'Build-the-source' page on github (selecting WM8880).

Which testing branch is that? Just 'testing' or 'testing-serial' or 'testing-smp'? The former is pretty outdated by now. I'd suggest 'testing-serial' (should somewhat work even without further patches).

> Serial console is configured via console=ttyS0,115200n8 on the command line.

WMT's don't use a standard UART - rather a WMT-specific one. So you should use ttyWMT0 instead of ttyS0. Except with WMT kernels, which pretend that it's a standard one, for no good reason.

Also consider using 'earlyprintk' in conjunction with respective config options under Kernel hacking - this will show you early messages before UART driver gets loaded.

> Is my tool-chain likely to be a problem? Gentoo crossdev generated (armv7a-hardfloat-linux-gnueabi-).

That's what I use too, works perfectly.

> Any advice as to where I should be looking for the problem?

Also check that you've appended the right DTB for your 8880... That's often a problem.

Best,
Alexey

[Cray Ze]

I've had a chance to play about with this, obviously I was never going to get anywhere with ttyS0 :)

The SMP stuff appears to be stable, it's the chip that's broken. A9 r3p0 in my wm8880 SOC.

If you turn SMP back on, along with the following three errata options, you'll have more joy.
[*] ARM errata: possible faulty MMU translations following an ASID switch
[*] ARM errata: Data cache line maintenance operation by MVA may not succeed
[*] ARM errata: A data cache maintenance operation which aborts, might lead to deadlock

Also noticed that second core fails to start if 'Compile the kernel in Thumb-2 mode' is selected.

Cheers

[Alexey Charkov]

On 6 Sep, 2014 2:48 am, "Cray Ze" <cray....@gmail.com> wrote:
>
> I've had a chance to play about with this, obviously I was never going to get anywhere with ttyS0 :)
>
> The SMP stuff appears to be stable, it's the chip that's broken. A9 r3p0 in my wm8880 SOC.
>
> If you turn SMP back on, along with the following three errata options, you'll have more joy.
> [*] ARM errata: possible faulty MMU translations following an ASID switch
> [*] ARM errata: Data cache line maintenance operation by MVA may not succeed
> [*] ARM errata: A data cache maintenance operation which aborts, might lead to deadlock

Do you observe panics in ehci-q:qh_completion due to null pointer to URB? Did those errata improve the situation for you?

I've managed to connect KGDB to my machine (will post patches), but it would take some time before I figure out what's wrong there...

> Also noticed that second core fails to start if 'Compile the kernel in Thumb-2 mode' is selected.

That might be because the 'holding pen' function is written in asm and in ARM mode, and it branches without mode switch into the C entry point.

Will need to check, though.

Thanks a lot,
Alexey

[Cray Ze]

Without the errata enabled I get lots of ehci-q:qh_completion panics. After enabling the three errata fixes covering the cortex A9 r3p0, the panics are gone and I have a usable machine.
Even with SMP disabled, a task (usually the gnu assembler) would occasionally hang, eating %100 CPU. With the errata applied, that issue is also fixed.
I can get the machine to eventually lock-up hard when tortured with huge compile jobs (compiling llvm is a good test for this) but that could be a thermal stress issue.

Cheers.

[Alexey Charkov]

On 6 Sep, 2014 1:20 pm, "Cray Ze" <cray....@gmail.com> wrote:
>
> Without the errata enabled I get lots of ehci-q:qh_completion panics. After enabling the three errata fixes covering the cortex A9 r3p0, the panics are gone and I have a usable machine.
> Even with SMP disabled, a task (usually the gnu assembler) would occasionally hang, eating %100 CPU. With the errata applied, that issue is also fixed.

That sounds awesome, thanks a lot for sharing! Will try.

Cheers,
Alexey

[Cray Ze]

Your welcome. Thanks for setting me straight on the UART name.

[lautriv]

Tony,
i was reading this thread again to see what are the most recent sources
to use on 8880, and re-read your issue with the pads for the UART.
I had a similar issue where it was proper soldered and glued but
unfortunately the glue was conducting (maybe i was to early ).
However i found alternate positions to solder and assume you have
the same board. If you can send a picture from yours
i may show you alternate locations.


Am Mittwoch, 3. Juli 2013 20:41:40 UTC+2 schrieb Tony Prisk:

On Tuesday, July 2, 2013 7:11:46 PM UTC+12, Tony Prisk wrote:

On Sunday, June 30, 2013 6:05:42 PM UTC+12, Tony Prisk wrote:

On Saturday, June 29, 2013 9:52:10 PM UTC+12, Tony Prisk wrote:

On Wednesday, June 26, 2013 5:35:39 PM UTC+12, Tony Prisk wrote:

I got one of these tablets today - unfortunately on disassembling it, I can't see a serial port/uart connection.
Slightly disappointing.

I will drop the board out and photograph it so I can get a better look - There are a few GPIO pads exposed, and a lot of testpoints for voltages.

Regards
Tony P

Not having a lot of luck - Had a play with the tablet on vendor firmware and it doesn't seem too bad (although 512MB memory is definitely a limiting factor).
One thing that doesn't seem to be working is the USB. If I connect it to my PC, it refuses to accept an address and fails. If I used HOST mode, it doesn't seem to detect the USB Flash Disk that is attached.

Still haven't located a uart header, although there is a 7 or 8 pin header (well, pads) on the back of the board which could be a possibility (several pins all routed back to the WM8880 in a bus-like fashion).

Looks like it now has a GIC (interrupt controller). I have done some quick updates on the WIKI to show what I've found.

Regards
Tony P

Still no luck finding the UART output...

I have confirmed that the vendor kernel has support for UART0..3 - found the memory space and irq's for them.
GPIO memory space doesn't seem to have changed (0xD8110000)
Serial Flash, EHCI, UHCI, NAND Flash, SD/MMC Controller, PWM, SPI 0 and I2C all seem to be located in the same IO space as well.

There is a new I2C3 (@ 0xD83B0000) and I2C4 (disabled on my board so I don't know where it is yet).

Finding the GIC has proven difficult as well - without it, getting even serial console working will be difficult.

Also, it appears there are some clock tricks going on again (or still).
Checking the PLL's, I see the kernel reading PLLB=700Mhz.

Testing this against the WM8850 PLL formula gives the expected results - A 24Mhz source clock.

When my tablet is idle, I get a PLLA=600Mhz (which is the lowest cpufreq frequency).
When running Antutu CPU benchmark though, it only jumps up to PLLA=800Mhz.

I also noticed that my result from Antutu is ~9000, whereas the screenshots posted on 1pad.cn show ~11000. When I compared them, it appears the only difference is in the 3D performance. Looking through dmesg I see an error for "please add mbsize=73M to kernel commandline". Guess someone didn't test it very well ;) Something to fix when I get uboot access.

Regards
Tony P

Found the UART pins finally - looks like the 8 pin pads on the bottom of the board are a sort of multifunctional input.
With a bit of board tracing, the first two pins are the UART tx/rx.
The other pins are other functions, one of which appears to be for for rewriting the serial flash.
Annoyingly, they are high density so I will need to get some enamel wire before I can put a header on them - Then I'll be able to finally see why the kernel isn't booting :)

Regards
Tony P

The pins are 0.5mm spaced. I soldered some 0.25mm enamelled wire on them and confirmed they work - Being a bit stupid, I didn't glue the wires and after half an hour or so I managed to pull the pad off the board so that pretty much ends any debugging I can do on the WM8880.

Regards
Tony P

[lautriv]

Is the branch testing-smp up to date or do i need some patch
to build it correctly ?

Actual state is a kernel that loads, blanks my screen and waits forever.

Status : testing-smp from yesterday with erratas enabled.
Machine : PID10-HL-1088 with the same-named dtb

[Alexey Charkov]

I boot it successfully with root fs on USB. Don't think SD works, although I haven't yet tried after enabling errata.

Best,
Alexey

[lautriv]

AH, it's not some kernel-thingie but the SD ...
will redo a rootfs there, i was happy to see that u-boot
can now handle usb ( used to it on tegra ) but former
wondermedias couldn't because of older u-boot.

So the SD-controller differs from 8850, is this because of
a faster one handling XHCI ?

[Alexey Charkov]

2014-09-08 10:24 GMT+04:00 lautriv <lautriv...@gmail.com>:
> AH, it's not some kernel-thingie but the SD ...
> will redo a rootfs there, i was happy to see that u-boot
> can now handle usb ( used to it on tegra ) but former
> wondermedias couldn't because of older u-boot.

My HL-1088 u-boot knows about USB net, but not USB storage, quite
awkwardly. I load the kernel from SD and then get it to mount the root
FS from USB.

> So the SD-controller differs from 8850, is this because of
> a faster one handling XHCI ?

It should now support SDXC, but that might not be the only difference.
WMT driver also does a bunch of 8880-specific initialization, but
that's mostly pinctrl stuff from what I've seen.

Need to check where our current code leaves SD registers and compare
that vs. the expected result of WMT magic. That was a bit tricky to do
while the kernel kept panicking - hope that the errata would make
things better.

Best,
Alexey

[lautriv]

Yes, i failed with "usb storage" on u-boot too, it asked me
if i forgot to "usb start" and said something about
"low-level initialisation failed" maybe another issue with
some GPIO not proper set before.
However i'll try to reproduce your way and see what i find.

[lautriv]

Yes, i meant SDXC not XHCI ( current concentration < 0 ).
However even my old 8650 can work with a 64G SDXC
reporting 41MHz in u-boot but not sure if the part in kernel
improved in the meantime.

Am Montag, 8. September 2014 08:57:28 UTC+2 schrieb Alexey Charkov:

[Cray Ze]

Is there a way to test the TWD?

I changed the device tree entry a bit.
Added an interrupt per core as suggested by the devicetree docs. Also added the twd-watchdog entry.
Switched back to pos_edge triggering for the interrupts, still not sure if we want edge or level here (varies with different vendors).
Attached both to the the peripheral clock.

I no longer have "smp_twd: clock not found -2" displayed by early boot and I can see twd in the interrupts list from linux, but is there a way to test it?


# cat /proc/interrupts
           CPU0       CPU1      
 29:     352625     365540       GIC  29  twd
 33:          0          0       GIC  33  sdmmc
 34:          0          0       GIC  34  sdmmc
 43:          0          0       GIC  43  sdmmc
 44:          0          0       GIC  44  sdmmc
 52:         22          0       GIC  52  sdmmc
 53:          0          0       GIC  53  sdmmc
 58:      11702          0       GIC  58  uhci_hcd:usb1, uhci_hcd:usb2
 68:          0          0       GIC  68  vt8500_timer
 81:          0          0       GIC  81  rtc alarm
IPI0:          0          1  CPU wakeup interrupts
IPI1:          0          0  Timer broadcast interrupts
IPI2:       5996       8667  Rescheduling interrupts
IPI3:          0          0  Function call interrupts
IPI4:          2          4  Single function call interrupts
IPI5:          0          0  CPU stop interrupts
IPI6:          0          0  IRQ work interrupts
IPI7:          0          0  completion interrupts
Err:          0


Device tree nodes:

        twd-timer@d8018600 {
            compatible = "arm,cortex-a9-twd-timer";
            reg = <0xd8018600 0x20>;
            interrupts = <1 13 0xf01>, <1 14 0xf01>;
            clocks = <&clkapb>;
        };


        twd-watchdog@d8018620 {
            compatible = "arm,cortex-a9-twd-wdt";
            reg = <0xd8018620 0x20>;
            interrupts = <1 15 0xf01>, <1 16 0xf01>;
            clocks = <&clkapb>;
        };


On Saturday, August 16, 2014 8:57:03 PM UTC+10, Alexey Charkov wrote:

As a heads-up: just discovered that not everything is rosy with
interrupts. Almost finished booting into a Fedora image on a USB stick
and got a kernel panic in some per-cpu interrupts from EHCI.

Looks like my TWD attempted to interrupt the secondary CPU, which is
unconfigured. Or maybe it's something totally different...

Will try disabling TWD altogether for now.

Best,
Alexey

[Alexey Charkov]

2014-09-21 11:35 GMT+04:00 Cray Ze <cray....@gmail.com>:
> Is there a way to test the TWD?
>
> I changed the device tree entry a bit.
> Added an interrupt per core as suggested by the devicetree docs. Also added
> the twd-watchdog entry.
> Switched back to pos_edge triggering for the interrupts, still not sure if
> we want edge or level here (varies with different vendors).

I believe stock kernel sets everything to level.

> Attached both to the the peripheral clock.

Was it just a guess, or did you have any reference for it? It's good
to know the tick rate in advance, but getting it wrong could be messy,
and I didn't find anything meaningful in Rock-II sources.

> I no longer have "smp_twd: clock not found -2" displayed by early boot and I
> can see twd in the interrupts list from linux, but is there a way to test
> it?

I believe this one was pretty harmless (judging by the code, it just
causes boot-time calibration of TWD clock rate). Not sure about the
testing part, though...

Could you please use macro definitions here instead? Those are much
more readable ;-)

Also, I haven't found any interrupts beyond 13 in vendor sources, so I
haven't included anything like that in my device tree. Is this some
kind of a standard arrangement?

> clocks = <&clkapb>;
> };
>
>
> twd-watchdog@d8018620 {
> compatible = "arm,cortex-a9-twd-wdt";
> reg = <0xd8018620 0x20>;
> interrupts = <1 15 0xf01>, <1 16 0xf01>;
> clocks = <&clkapb>;
> };

Also couldn't think of a way to test whether WDT actually works :)

Thanks,
Alexey

[Cray Ze]

On Monday, September 22, 2014 2:33:02 AM UTC+10, Alexey Charkov wrote:

2014-09-21 11:35 GMT+04:00 Cray Ze <cray....@gmail.com>:
> Is there a way to test the TWD?
>
> I changed the device tree entry a bit.
> Added an interrupt per core as suggested by the devicetree docs. Also added
> the twd-watchdog entry.
> Switched back to pos_edge triggering for the interrupts, still not sure if
> we want edge or level here (varies with different vendors).

I believe stock kernel sets everything to level.

ok, though have seen a number of socs using pos_edge, as does the twd device-tree bindings example.

 

> Attached both to the the peripheral clock.

Was it just a guess, or did you have any reference for it? It's good
to know the tick rate in advance, but getting it wrong could be messy,
and I didn't find anything meaningful in Rock-II sources.

I did see it used elsewhere, then I confirmed it with the ARM documentation.
Cortex-A9 MPCore Technical Reference Manual
4.1. About the private timer and watchdog blocks
The clock for these blocks is PERIPHCLK.

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0407f/CCHCHHDF.html
 

                        interrupts = <GIC_PPI 13
                          (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_EDGE_RISING)>,
                                     <GIC_PPI 13
                          (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_EDGE_RISING)>;

                        clocks = <&clkapb>;
                };


                twd-watchdog@d8018620 {
                        compatible = "arm,cortex-a9-twd-wdt";
                        reg = <0xd8018620 0x20>;

                        interrupts = <GIC_PPI 14
                          (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_EDGE_RISING)>,
                                     <GIC_PPI 14
                          (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_EDGE_RISING)>;
                        clocks = <&clkapb>;
                };


 

Also, I haven't found any interrupts beyond 13 in vendor sources, so I
haven't included anything like that in my device tree. Is this some
kind of a standard arrangement?

Yes my interrupt numbers were wrong, each core has ID's 29 and 30 so I think I have to specify the same interrupt twice (once for each core).
Updated (with macros) the devtree nodes to match this assumption. Still playing with pos_edge though.

13 in device tree is Arm interrupt ID 29
14 in device tree is Arm interrupt ID 30

Some info on how the numbers work (though directed at zynq, it's not zynq specific)
http://billauer.co.il/blog/2012/08/irq-zynq-dts-cortex-a9/


From the Arm docs.

Private timer, PPI(1)

Each Cortex-A9 processor has its own private timers that can generate interrupts, using ID29.

Watchdog timers, PPI(2)

Each Cortex-A9 processor has its own watchdog timers that can generate interrupts, using ID30.

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0407e/CCHDBEBE.html

[ferva...@gmail.com]

hello everyone, please help me to find uart pins in this board. i bricked mi tablet , i need to reflash u-boot to SPI memory via terminal

http://terefrio.tuars.com/images/back.jpg
http://terefrio.tuars.com/images/frontimi.jpg

[Alexey Charkov]

Try that unsoldered header on the front, in the 'internal' corner next to NAND and SPI flash. Most likely it has serial and SPI flash pads - looks very similar to other boards.

--
You received this message because you are subscribed to the Google Groups "VT8500/WM8505 Linux Kernel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vt8500-wm8505-linux...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ferva...@gmail.com]

thanks for your quick response , then maybe the first two pins are the UART tx/rx?

you refereded to this pins, right?

http://terefrio.tuars.com/images/frontedit.jpg

[Marius Cirsta]

Yep, those are almost sure what you're looking for. 4 of them for
UART from what I can tell and the rest are for SPI programming I think
( which is why they're near the SPI chip ). You can just try with a
3.3V TTL cable and the normal UART settings.

[Alexey Charkov]

Exactly. Have a look at prior posts: I think Marius posted a picture of his board with Rx marked, and Tx is the one next to it (either 1 and 2 or 2 and 3 - can't remember for sure). The header seems to be the same on many WM8880 boards.

[ferva...@gmail.com]

sorry for be annoying , but can someone take a look a this photo and see the circuit , and tell me if I'm right?(if only the photo help) .I'm complete noob about this stuff , if I'm wrong ,please tell me what pins i should use (RX TX)

http://terefrio.tuars.com/images/rxtx.jpg

Thank you so much for all your patience and sorry for mi bad english

[lautriv]

I have a complete different layout (1088-HL) but the same connector
and this looks right, next pin is GND.

[Marius Cirsta]

Nobody can tell you exactly what to do unfortunately as we don't have
the exact same board but don't be so scared no one will die if you
connect things the wrong way.
First of all do you have the cable needed to connect to this ? You
need a serial cable with TTL levels, an old nokia cable like CA-42
will do.
Turn on the device and measure the voltages between the ground ( like
the metal USB outer shell ) and each of the pins. A value of 0 or
almost 0 means it's a ground while a fluctuating voltage or aprox 3.3V
means it could be the TX of the device.
During boot the TX of the device will have small voltage
fluctuations. It is also during boot that you need to connect you RX (
if you've got a Nokia cable the pinouts and color codes are avalaible
online ) cable to the TX on the device. If you've found the right pin,
the TX you'll see some messages during the short boot period.
This is not that easy but you can give it a try, you've got nothing
to loose since it's already bricked and useless.

[ferva...@gmail.com]

thanks for your time Marius I'll buy the nokia cable and experiment ,i just wanted to be sure the board has a serial pins
i'm not have electronic knowledge , all i know i learned from forums
i read about people who Debrick the tablet using serial port and terminal commands to flash a firmware or even reflash u-boot ,w-load binaries

[Marius Cirsta]

We all began by not knowing and learned by trying ( and even
sometimes failing ). I spent more than 5 hours maybe even 10 hours
looking for the UART on my WM8880 board. Every board has UART though
and it's very easy to find it if you have a working device.
I'm sure of those 8 pins there 2 are the UART RX and TX. You'll have
to find the TX first and then the RX is right next to it. A CA-42
calbe is at most $3 on ebay but best to get it locally as you don't
have to wait for shipping. You'll need to strip the phone end to get
to the thin wires inside.
Don't be afraid to experiment, but also be careful, the biggest
problem I see is that those pins are really close to one another and
when trying to connect to one of them you might actually make a
connection between them. I don't think this is fatal ( so don't stress
too much ) but it's best to avoid it.

One more thing, tablets usually have a mechanism for firmware
upgrade, can't you try that one ? Don't the vol + - keys and power key
combinations make it boot into recovery ? Or maybe you can place
something on the SD card to make it flash the firmware from there.

Still getting an UART connection is cool and I'd even say fun if you
manage it :)

[ferva...@gmail.com]

Hello guys! It's me again. mi tablet is refused to install the firmware, is stuck on WMT Android 4.2 u ugrading ,nothing happens. anyonne had this problem? i think i fuck up the flash manager o or whatever its call

sorry the bad english

http://terefrio.tuars.com/images/img2014102.jpg

[Alexey Charkov]

At least it shows something, so your u-boot is alive. Thus you can potentially use scriptcmd to reflash the bootloader environment and OS.

Can't say anything further, as you haven't provided any details on your flashing script/environment.

Please start a new topic if you'd like to discuss anything further on this - this one is a bit too long and divergent already...

Thanks,
Alexey

[mhik...@gmail.com]

i found some boot files that boots the wm8880, thought it would help.

[jeremy...@gmail.com]

I recently got an Elovo X6-13V21 laptop with a WM8880, planned to install Linux on it natively. I wanted something a little more powerful and portable than a Raspberry Pi. It's been a real pain, though. No one on any forum has been able to help me, and looking through this thread I'm starting to see why. It took me forever to find out the manufacturer. It turned out not to be useful information after all, though.

I've been looking for anyone that might know something about this device, and you guys seem to fit the bill. I've never played around with U-boot much, but I was able to dump/extract the U-boot image from a rooted installation of Android on the laptop. I figured out that I could make the device cycle its power until I removed the SD card by putting a compiled mkImage script with "poweroff" in either FirmwareInstall/autorun.1.wmt on an SD card, or FirmwareInstall/autorun.u.wmt on a USB device. I can't see what U-boot is doing, though, and I have no experience working with it.

I'm a first-year Computer Science student that's played around with Linux for about 10 years already... and I'm stumped as to how to get a Debian installer running on this thing even though I've been researching for weeks. Everyone told me Debian was the best distribution for ARM, but even the Debian people haven't been able to tell me much.

This is my first experience with ARM processors, and it makes me wish I'd gone with Atom instead. I can do almost anything to a PC or a Nintendo Wii, but I'm not l33t enough to bust open a thin, fragile computer with a lot of glue and attach stuff to pins just to see a console. I just wanted to thank you guys for trying to get this thing working, not many people out there could do what you do.

[Azmi Raman]

I think the newer Raspberry Pi 2 is faster, the gpu is faster too

--
You received this message because you are subscribed to a topic in the Google Groups "VT8500/WM8505 Linux Kernel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vt8500-wm8505-linux-kernel/yyf6aQaY0MQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vt8500-wm8505-linux...@googlegroups.com.

[Alexey Charkov]

On 15 Dec 2015 15:46, <jeremy...@gmail.com> wrote:
>
> I recently got an Elovo X6-13V21 laptop with a WM8880, planned to install Linux on it natively. I wanted something a little more powerful and portable than a Raspberry Pi. It's been a real pain, though. No one on any forum has been able to help me, and looking through this thread I'm starting to see why. It took me forever to find out the manufacturer. It turned out not to be useful information after all, though.
>
> I've been looking for anyone that might know something about this device, and you guys seem to fit the bill. I've never played around with U-boot much, but I was able to dump/extract the U-boot image from a rooted installation of Android on the laptop. I figured out that I could make the device cycle its power until I removed the SD card by putting a compiled mkImage script with "poweroff" in either FirmwareInstall/autorun.1.wmt on an SD card, or FirmwareInstall/autorun.u.wmt on a USB device. I can't see what U-boot is doing, though, and I have no experience working with it.

It should be relatively easy to install Debian using the stock kernel - or, for that matter, using one compiled from APC Rock II sources (though I haven't really tried for the lack of time).

You just create a root filesystem using debootstrap and make your scriptcmd load the stock kernel from NAND (if necessary, with a custom initramfs).

Debian's official docs describe debootstrap usage quite well - just keep in mind that you won't be able to chroot into your freshly made root fs (so you'll need to e.g. set the root password via other means, like booting directly into the shell as init first). Also skip anything bootloader related.

If you have a rooted Android system, you can easily use that to dump the u-boot config partition to see what it does in the stock boot sequence (may be a good idea to replicate most of that, except the kernel command line and initramfs).

Happy to help you out with this if you promise to document the whole process in a wiki article on some relevant site ;)

Cheers,
Alexey

[corneliu...@gmail.com]

Hi there!
I have some issues with one netbook, wm8880 cpu based. it is called M1019B (on the back label), has a 10'' screen.
After a wrong flash (selected wrong file in the "config folder") the netbook powers up but nothing is showing on the screen.
Can someone guide me to revive the thing?

Thanks in advance!

[Alexey Charkov]

Hi Cornelius,

Please start a new thread for this discussion - this one is quite messy already.

There are many ways how it could go wrong, so some extra detail will
be needed. Have you got / can you get a serial console connection to
the machine? Do you have a backup of your serial (SPI) flash prior to
reimaging? Have you got any means of replacing SPI chip contents (e.g.
external programmer and soldering skills, in-circuit programmer and a
test clip, external SPI emulator and unsoldering CS from the chip,
etc.)?

Best,
Alexey

> --

> You received this message because you are subscribed to the Google Groups "VT8500/WM8505 Linux Kernel" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to vt8500-wm8505-linux...@googlegroups.com.