un.codiert.org

Today I want to use the attached DDR2 Ram on the ml50x (XUPV5) board. Xilinx provides a Memory Interface Generation (MIG) IP core which could be used to generate a design which drives all ddr2 lines and provides an interface for user logic. It is extremely sadly that xilinx doesn’t provide directly the needed ucf-files for all boards they sale. Everybody who wants to use the MIG has to create the ucf by himself or looking for reference designs where this file is included. Fortunately the ucf exists for the xupv5 board. So I only have to care about the user logic which writes or reads from the memory. The user interface is well documented in the user guide (ug086) and could be driven with some lines of code. Keep reading, now it is time to combine some already written logic with the mig.

Since Fedora 9, the init process is managed by upstart. To get a serial console with a login prompt the old method doesn’t work anymore. The old method is to add the following line into /etc/inittab:

s0:3:respawn:/sbin/agetty -L 115200 ttyS0 vt100

This spawns a agetty for the ttyS0 in runlevel 3. The new method is event based where all event description files are inside /etc/event.d/. For a normal Fedora installation the file “serial” will be called from a udev event. If udev is not running and doesn’t generate events the following method will work. The spawned agetty should be for a ttyS0 so we name the file ttyS0. The content for the same behaviour as above looks like:

# ttyS0 - agetty
start on stopped rc3

respawn
exec /sbin/agetty -L 115200 ttyS0 vt100

UPDATE: fedora 17 including grub2

edit /etc/sysconfig/grub:
 GRUB_TERMINAL="serial console"
 GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1"
 GRUB_CMDLINE_LINUX="... console=ttyS0,115200"
generate grub-config
 grub2-mkconfig -o /etc/grub2.cfg

Silvio said to me that he gets tons of spam. I couldn’t imagine that only he gets the spam and all of my addresses and domain mail users didn’t get spam. But today I saw the bug in the amavisd.conf. The variable “@local_domains_maps” in the configuration only has my domain. This brings the failure that amavis checks the mail but doesn’t write the result or doesn’t act as described in the configuration. The bad thing is that the maillog doesn’t show this behaviour, the log shows that the mail is detected as SPAM and will be blocked. The first solution to protect Silvio against SPAM is to at his domain to the local_domains_maps. But this doesn’t help all the other hosted domain users. Amavis provides a MySql interface to query a database for the domains. The following lines have to be configured:

@lookup_sql_dsn = ( ['DBI:mysql:database=database;host=127.0.0.1;
                    port=3306', 'user', 'secret'] );
$sql_select_policy = 'SELECT "Y" as local FROM alias WHERE address IN (%k)';

This instruct amavis to lookup the domain for each mail which is hosted and should be checked. Happy Mailing…

Ok, now the second part of this cypress story. The source which is provided by cypress contains some demo projects, for my test design which should put the board into a peripheral mode, the demo “de2″ is a good starting point. After some browsing through the code I saw that this demo puts SIE1 (Serial Interface Engine) into a simple loopback/FIFO mode where the usb driver could write some data with a bulk transfer into a buffer and read it back. This is a good starting point to implement a simple driver under Linux with libusb. But this needs some easy modification to the code, because the ml50x board has the peripheral port connected to the SIE2. After mapping SIE1 functionality to SIE2 and remove some unused code the driver implementation can be started. The driver just write some data into the cypress chip and reads it back.

Now the next step. This step includes includes the communication with the fpga. The fpga is connected with 16 data, 2 address and some control signals to the cypress chip. To transfer data to/from the fpga just use a simple protocol with a   and write/read enable signals. For this implementation the original SIE2 implementation of the demo program is our friend. Again remove some unused/not needed code from the implementation and add app_task implementation. This application task function will be called from the main loop. This function have to compare the control entries of the bulk transfer endpoints and execute the needed functionality like writing or reading to/from the fpga. The lsusb print out looks like:

Bus 004 Device 003: ID 04b4:4224 Cypress Semiconductor Corp.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass         0
  bDeviceProtocol       255
  bMaxPacketSize0         8
  idVendor           0x04b4 Cypress Semiconductor Corp.
  idProduct          0x4224
  bcdDevice            0.04
  iManufacturer           1 codiert.org
  iProduct                2 FPGA - ML505 control
  iSerial                 3 42-24
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           46
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xc0
      Self Powered
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol    255
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0

After scanning the USB bus and opening the device it can be written/read by the following codes:

usb_bulk_write(hd, 2, &buf[0], 2, 10000);
usb_bulk_read(hd, 1, &rec[0], 2, 10000);

Code can be requested by mail — cheers

The day is there, a new coffee machine is my own. It has a lot of features and configuration possibilities, but the important thing the coffee taste very good. With the attached “Easy-Cappuccino-Düse” it is a breeze to make wonderful milk froth. Further you can choose how strong your coffee or espresso should be scald and how much water should be used for the cup. But pictures says more than thousand words.

Time to play with the next part of the ML505 board. The soldered USB chip is provided by Cypress and can be configured as a host and peripheral device. It contains a 16-Bit Risc Core, two serial interface engines (4 USB Ports) and a lot of other useful things (UART, SPI, IDE interface). To provide the bios/program xilinx connected a I2C EEPROM to the cypress chip.

To get started a toolchain for the risc core and tools to program the eeprom are needed. Cypress provides a CD image for the CY3663 Development Board which includes the toolchain, utilities and a framework/sample code to create a BIOS. The sample code provides an ideal starting point for the first testings, but this will come in the second post to this topic. However, after compiling the sample bios the make files provide a .bin file. This bin files needs a wrapper which can be created with:

scanwrap compile_in.bin wrapped_out.bin 0x2100

In this case hex 2100 is the entry point of the bios which is specified inside the bios linker script. To program the wrapped binary the following command is needed:

qtui2c wrapped_out.bin f1

The second parameter depends on the i2c part which is connected to the chip. In the case of the ml505 “f1″ is a good choice.

That’s all so far — stay tuned!

There are a lot of possibilties to manage the qemu kvm monitor and serial ports. Here is one solution to provide these two ports for a user which only has a chroot home with a small busybox (with microcom). First of all qemu-kvm has to know how the interfaces should be exported. This solution uses the ‘pty’ (pseudo terminal) interfaces/devices (“-monitor pty -seriak pty”). The qemu-kvm instance creates to ptys which will be show up in /dev/pts. To provide this devices to the chroot user, just create the same character devices inside the chroot. Now the user can use microcom to connect to both ports. To automate this process the following script does the magic:

#!/bin/bash
manage_home=/home/chroot/kvm
HN=disk
KVM_USER=XYZ
nohup qemu-kvm -daemonize -no-acpi-nographic -m 378 -localtime \
  -hda ${HN}.img -monitor pty -serial pty

pty_mon=`head -1 nohup.out | awk '{ print $5; }'`
pty_ser=`tail -1 nohup.out | awk '{ print $5; }'`

rm -f $manage_home/$KVM_USER/${HN}_mon
rm -f $manage_home/$KVM_USER/${HN}_ser
mknod $manage_home/$KVM_USER/${HN}_ser c 136 ${pty_ser##*/}
mknod $manage_home/$KVM_USER/${HN}_mon c 136 ${pty_mon##*/}
chown $KVM_USER $manage_home/$KVM_USER/${HN}_mon $manage_home/$KVM_USER/${HN}_ser
chmod 600 $manage_home/$KVM_USER/${HN}_mon $manage_home/$KVM_USER/${HN}_ser
rm -f nohup.out

Starting situation is an installation of Windows XP and Fedora 9 on the hard drive. The goal is to start Windows from Linux with the KVM virtualization solution. First step is to create a second hardware profile inside windows, this is necessary because windows should be bootable from the virtual machine and native hardware. Then it is time to try the first boot with the command line:

qemu-kvm -std-vga -m 512 -hda /dev/sda

This ends in the error message:

A disk read error occurred
Press Ctrl+Alt+Del to restart

The message is printed by windows boot loader which is installed inside the boot sector section of the windows partition. This error gives the suggestion that there is something wrong with the boot loader. There exists a project which provides a CD to fix the NT bootloader and to boot into installed windows versions without the bootloader on the disk. With the following command line it is now possible to boot windows:

qemu-kvm -std-vga -m 512 -hda /dev/sda -cdrom fixntldr.iso -boot d

This solution works without changing the windows boot loader and doesn’t destroy the native boot.

Today it was time to write some VHDL code for the new board. The result are some lines to drive the LCD (ks0066u chipset 4-Bit interface). It is quite easy to talk with such devices, they have only a 4 bit data bus, 1 RS (Register Select), 1 R/W (Read/Write) and 1 E (Read/Write Enable) Signal.

The first module is a low level module with a wishbone compliant interface, it is responsible for the generation of the right signal combinations to talk with the LCD. The second one consists of a loop to write the initialization sequence and characters to the LCD.

That’s all.

BTW.: If someone wants the code example, just write me an email.