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.
Showing posts with label linux. Show all posts
Showing posts with label linux. Show all posts
Friday, April 25, 2014
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:
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:
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:
Now build the kernel (add -j2 or more if you have a SMP system to speed up the compilation):
The kernel should build successfully, and you should have a kernel image in
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- menuconfigFor 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.
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.
Subscribe to:
Posts (Atom)