Showing posts with label linux. Show all posts
Showing posts with label linux. Show all posts

Friday, April 25, 2014

Getting on the CAN bus

I co-worker from waaay back (199?) contacted me a while ago about helping out with some issues he had with a linux system that talks with a CAN bus. A very interesting system. But I won't go into specifics here on that point.

Anyway, CAN bus. Most will probably think OBD-II, cars and ELM327, understandable as that is what it was designed for. And that was just about all I did know about it myself too. Researching into it some more was very enlightening and I got some cool ideas on how to use CAN for one of my own little forever projects.

Now, CAN bus is quite simple, two wires, differential. All you need is a transceiver, a controller and something to tie that into your computer, USB, RS232, PCI, etc. Some Linux friendly and cheap boards even have CAN bus integrated in their SoC. And there are some easy to interface SPI controllers that you can use with your favourite microcontroller.

What makes it really interesting is that most of the low-level stuff is handled on-chip. Software does not need to care about timings, arbitration, bit-stuffing, CRC and all that. It is all on the chip. And you have a wide choice of bandwidth/length options. Need to connect that sensor a 100 meters away ? No problem. And thanks to being designed for hostile environments it should work over just about any two wires, or so I've heard.

There are some limits of course. Maximum data packet size is a whooping 8 bytes. And messages have only have a message ID, no sender or receiver ID. So the network is a 1:N broadcast network. But still, that is quite OK for a sensor network.

I ordered a couple of MCP2515 and MCP2551 chips and I hope I have some time do play with them soon.

Wednesday, December 05, 2012

Pioneer BDP-150 Blu-ray player, Linux Inside

I finally gave in and got myself a Blu-ray player. After much googling and comparing I decided on a Pioneer BDP-150 Player. Luckily I was tired and didn't go to the store directly and so got it even cheaper as they had it on sale, 99€ only.

One of the biggest plus in my book was that the device ARMv6 (mediatek) based, running Linux  2.6.27 kernel with a DirectFB and Qt. Firmware to play with here and available sources here.

binwalk:ing the firmware data file gives:

DECIMAL    HEX        DESCRIPTION
-------------------------------------------------------------------------------------------------------
67512      0x107B8    Mediatek bootloader
67897      0x10939    LZMA compressed data, properties: 0x80, dictionary size: 1073741824 bytes, uncompressed size: 196608 bytes
114580     0x1BF94    Mediatek bootloader
300220     0x494BC    JFFS2 filesystem data little endian, JFFS node length: 8195
417804     0x6600C    LZMA compressed data, properties: 0x90, dictionary size: 738197504 bytes, uncompressed size: 754973620 bytes
430796     0x692CC    JFFS2 filesystem (old) data little endian, JFFS node length: 344
441485     0x6BC8D    LZMA compressed data, properties: 0x5D, dictionary size: 1036255232 bytes, uncompressed size: 327678 bytes
447129     0x6D299    LZMA compressed data, properties: 0x02, dictionary size: 8388608 bytes, uncompressed size: 1073741824 bytes
447153     0x6D2B1    LZMA compressed data, properties: 0x02, dictionary size: 8388608 bytes, uncompressed size: 1073741824 bytes
447177     0x6D2C9    LZMA compressed data, properties: 0x02, dictionary size: 8388608 bytes, uncompressed size: 1073741824 bytes
450404     0x6DF64    LZMA compressed data, properties: 0x80, dictionary size: 1660944384 bytes, uncompressed size: 521134 bytes
461744     0x70BB0    uImage header, header size: 64 bytes, header CRC: 0x775F4C1C, created: Wed Oct 24 10:43:23 2012, image size: 1573204 bytes, Data Address: 0xDA00000, Entry Point: 0xDA00000, data CRC: 0x782925E7, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: none, image name: 
479272     0x75028    gzip compressed data, from Unix, last modified: Wed Oct 24 10:38:55 2012, max compression
2574912    0x274A40   Squashfs filesystem, little endian, version 3.1, size: 59779047 bytes, 471 inodes, blocksize: 131072 bytes, created: Wed Oct 24 10:51:11 2012
33020448   0x1F7DA20  JFFS2 filesystem data big endian, JFFS node length: 503796
35336806   0x21B3266  PNG image, 91 x 88, 8-bit/color RGBA, non-interlaced
35439823   0x21CC4CF  PNG image, 97 x 88, 8-bit/color RGBA, non-interlaced
35516856   0x21DF1B8  PNG image, 168 x 161, 8-bit/color RGBA, non-interlaced
52281361   0x31DC011  gzip compressed data, has CRC, was "\031\202\273\253M\021\334\335\276\207\340\356\1771\014@\356\376\013{\023r\367}t\027\271;\005k\026\271\273\027R\034r\367\351\011\202\273\237`\211\221\273\267`\035#w7B\227\220\273\327\025\027\334}\003", last modified: Thu Sep  6 02:46:23 2029
62487104   0x3B97A40  PNG image, 1920 x 1080, 8-bit/color RGB, non-interlaced

Friday, February 17, 2012

Kernel for S/390 and hercules

So now you have a cross-compiler, now to get a kernel for your mainframe!

Download kernel source, unpack and configure:
wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.2.6.tar.bz2
tar jxf linux-3.2.6.tar.bz2
cd linux-3.2.6
make ARCH=s390 CROSS_COMPILE=/opt/s390/bin/s390-ibm-linux- defconfig

Now you have your kernel source setup for building a S/390 kernel with the default kernel configuration. You can now customize the configuration by running:
make ARCH=s390 CROSS_COMPILE=/opt/s390/bin/s390-ibm-linux- menuconfig
For example, some drivers defaults to being built as modules, that you might like to have in your kernel image instead.

Now build the kernel (add -j2 or more if you have a SMP system to speed up the compilation):
make ARCH=s390 CROSS_COMPILE=/opt/s390/bin/s390-ibm-linux- 

The kernel should build successfully, and you should have a kernel image in
arch/s390/boot/image ready for IPL on your mainframe.

Thursday, April 16, 2009

Working around buggy ALi IDE on ultrasparc hardware

The Linux ALi IDE driver (at least 2.6.23) does not have a proper workaround for a hardware bug that makes DMA transfers sometimes produce garbage. The simple workaround to get these sparc up and running has been to boot with the "ide=nodma" kernel parameter. That is fine, but performance will really suck.
Anyway, I run my personal production mail, proxy, tunnel, build server on a Netra-AX and it has the buggy ALi IDE chipset. My first workaround was to just have the basic root system on a small IDE disk on the primary channel and all data disks on a SATA controller. This was alright for a while but on some heavy compilations and swapping made the system crawl. I had made the stupid mistake to put my swap on the no-dma disk, plus loading binaries and libraries from the nodma disk was slow. But what to do then ? The PROM will only boot from the internal IDE and I didn't like to move the system to another disk. Digging in my hardware stash I found a nice IDE-to-CF converter that can be plugged directly into the motherboard, plus a 32Mb CF card, just enough for a kernel or two. And the CF card is PIO only so the kernel handles it alright. So now I boot the system from the CF card and have the disk plugged into the external PCI IDE card.