after buying a few thin clients off ebay this Chip PC LXD8941 came up in the ebay recommendations. Since it was only £10 + £2.50 shipping and the specs are very similar to the Dell Wyse T50 and the HP T5335Z I couldn't resist. It is a nice compact unit with 1 Gbps ethernet, 6 USB ports, micro SD card slot, DVI connector, power and reset button. I'm not sure how common these are but since it is so similar to the other two units I already own I have good hope to get Debian working (with a bit of help from the experts on the forum).

Inside there is both a 4 pin and a 6 pin header. The 4 pin is the UART connection. With the power button towards you and the DVI connection away from you the connections are as follows: GND, TX, RX, VCC (from left to right).

Basically the same u-boot envs can set up to boot Debian USB rootfs. The DTS will be based on the same reference Dove dts, but slightly different, though. They might or might not use the same kernel GPL as the T5535 and Wyse T50/T10.

Stock OS doesn't offer a terminal or anything useful to explore the system with. So I've taken the USB stick from the T50 and used the following commands from the HP T5335 topic. It starts loading the kernel but hangs.

I've tried the same thing with the USB stick from the T5335Z but that (unbranded) USB stick is not recognized. I guess I should create a new USB stick with the default dove.dtb appended and start with that.

Ok I need to reshuffle some USB sticks so won't be able to try booting Debian until tomorrow. Below are the numbers of the larger chips that I can decipher. I'll also email the people at Chip PC Technologies to see if they can point me to GPL sources etc.

Koen Wrote:
-------------------------------------------------------
> Stock OS doesn't offer a terminal or anything
> useful to explore the system with. So I've taken
> the USB stick from the T50 and used the following
> commands from the HP T5335 topic. It starts
> loading the kernel but hangs.
>
>

>
> I've tried the same thing with the USB stick from
> the T5335Z but that (unbranded) USB stick is not
> recognized. I guess I should create a new USB
> stick with the default dove.dtb appended and start
> with that.
>

Unfortunately none of the dove.dtb files get any further than the Uncompressing Linux stage. So the dtb file will need a bit more work than expected. I've also noted an error in one of my previous post. The Sandisk SDIN5D2-2G chip is the internal memory and has nothing to do with the card reader.

I didn't have a cable plugged in and also the dove-dove-db.dtb file has ethernet set to disabled. It's getting late here but tomorrow I'll start to enable different sections in the dtb file to see if it changes things. Thanks for your help as always.

Ok let's summarize things so far. Serial connection allows access to uboot and makes it possible to boot debian from a USB stick. USB and ethernet are working. Micro SD card reader, audio and graphics are not working yet.

Power off doesn't work properly either but I assume that requires some GPIO info from GPL sources if Chip PC ever releases them.

The following section in dmesg is not correct but the system does find a clock source and does not seem to mind.

In uboot there are quite a few commands to test or read different parts of the system. For example when I run audioTest in uboot I hear a beep on the plugged in speaker. Can some of these commands in uboot be used to probe the registers of the device and help with improving the dtb file?

The Audio issue is definitely because we don't have it defined enough in DTS (i2s is not defined yet).

The PMU problem is important and it is reminding me to do some more close reading of the kernel patches. The current DTSI (that we derived from) has an old style binding, so it is not apparent yet to me how we can solve this.

I've seen and consulted these documentation countless times while trying to find info in Linux kernel. They are very useful, but usually don't have specific implmentation for a box (we could get lucky and see some real examples).

Basically, what dove-pinctrl.txt describes what this SoC does, how it layouts the MPPs (this table is in the Marvell Functional and/or Hardware Reference Manual). The manufacters can then use these pins to drive things. But except for a few pins that must be used as such, the GPIOs are multiplexed and can have several possible meanings (usually 4 or 5), depending how they are connected in the board.

In any case, looks like the pinctrl message we've seen in the log was just a warning, not real error. However, I am still a little unclear why it behaves differently from the HP T5325 regarding the sound module loading during boot.

In the stock dmesg there is this line which seems to be a signal to activate the LCD / screen. However if I understand it correctly we can't just apply that to the HP t5336z or T50 since manufacturers are free to choose which ever pinctrl they want.

Please, enter the code that you see below in the input field.
This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right.
If you enter the wrong code, a new image is created and you get
another chance to enter it right.