Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

We have had customers successfully integrate both an KSZ8893MBL switch and the KSZ8895MAI switch with the MityDSP-L138.

Are you not able to send/receive packets from the OMAP-L138 to the switch?

Typically, these switches power up with the MII port disabled or in an isolated state. In both these cases, you have to issue a register write command via the SPI or MDIO to bring the port up following a power on condition. You may also need to set up the clock speed and MII more (e.g., MII vs. RMII, etc.). In particular the SPI port (SPIC/SPID/SPIS-N/SPIQ) was used to enable the ports (I don't remember the specific register off hand). Do you have the control interface hooked up?

-Mike

Mike

I am the customer who submitted this post. I had a problem with logging on which is why Tom posted this for me. Hopfully, I have now sorted this out.

I am new to Linux, so if the questions sound naive, then that is because I am very much a newbie to Linux.

We, that is, our company, have decide to look at using linux to free us from some of the work of implementing the communication functions so as to allow us to concentrate on the application.

We are developing an electrical protection unit (normally called a relay) and are planning to use ethernet to comunicate with adjacent and other remote units, hence the switch.

We have designed a dev board with a MityDSP_L138 module which has a KSZ8995 fitted, which is implemented in the latest kernel. The switch has the MII, MDIO and SPI interfaces connected, although I am only familiar with the SPI.

Since I e-mailed Tom, I have learned a good deal more about the various flavours of the kernel and now appreciate more of what features are available in the differnt versions.

My plan was to get hold of the appropriate kernel and modify it to suit our new board.

I have, perhaps naively, expected that this would be a matter of downloading the latest kernel, enabling the KSZ8995 and everything would work fine. I realise that the davinci version that is currently available from "git://support.criticallink.com/home/git/linux-davinci.git linux-davinci" does not include the KS8995 support, so I have tried other sources, but now I realise that these are not compatible.

What I have done so far is to download a kernel version 3.3.4 from the normal kernel archive, included the KS8995, recompile, programmed to flash and run. Needless to say this did not enable the switch, nor did it access the sd card.

I would like to feel that it is possible to get this switch to work, but now I know that it is,at the moment, beyond my understanding of Linux to do this.

Therefore, before I do much more work on it, would appreciate your advice to help me to decide what to do.

If I use the correct version of the kernel and configure it correctly, should this switch allow me to communicate with an external network or is there other work to be done to implement this? If yes, any help in implementing this would be appreciated.

If not, would it be simpler to implement this outside of Linux?

Is there any other documentation that you have come across that would help me to decide which way to go?

Any help would be greatly appreciated.

Charlie

Hi Charlie,

I guess the first question is, "what do you want to do with the switch?". As I mentioned before, we have successfully implemented the KSZ8995 into at least one design here, and if you have all the ports mentioned above connected, you should be able to use the part. If you just need to enable it as a "dumb switch" (i.e., don't require VLAN capability or any special port management features), I think you need to write a handful of commands to the SPI port to bring up the port. I haven't looked at the KSZ8995 PHY drivers in the later versions of the kernel, my guess is that they may be able to do this for you but you likely need to write up a board file that configures the driver with the appropriate SPI information so it knows how to access the part.

The linux-davinci tree on our site has a couple of branches. The "master" branch is actually a 2.6.34 branch. There is also a 3.2 port that might include the KSZ8995 PHY port as a separate branch there. If you need help with the git command to grab the other branch, let me know.

For custom boards, you will need to modify the kernel to configure the pin-mux settings and drivers that are different from the Industrial I/O devkit board. That involves copying the arch/arm/mach-davinci/baseboard-industrialio.c to arch/arm/mach-davinci/baseboard-yourfile.c and modifying the file to configure the pinmux settings for the OMAP-L138 as well as initialize the specific device drivers needed for your board (e.g., the SPI control port for the KSZ8995, etc.). You also need to update the Makefile and the KConfig file in the same directory to build that file into your kernel. Sounds complicated, but it's really not too difficult, and probably still easier than rolling your own network / SPI /MDIO stack outside of linux.

If you're interested, we could help you build a kernel / BSP for your custom board that enables the features. My guess is that it would not be too complicated a task (we'd need to see your baseboard schematics to get a better idea).

Hope this helps.

-Mike

Mike

Thank you for your assistance. I would like to look at the version 3.2, so if you could let me know how to access it I would be obliged.

The switch on the dev board will be used initially to allow me to connect to our local network, but ultimately it will be used to connect with adjacent units within a DC switchgear panel, including an HMI and other protection and I/O devices while allowing remote connection to some or all units.

I may very well take you up on the offer to help build a kernel/BSP and if i do I will try to provide a diagram of the general arrangement of such a panel.

If I do decide to take up you offer I will try to get the info together sometime next week.

regards

Charlie

Mike

I have found a branch 'mitydsp-linux-v3.2', which I assume is the one you referred to, which I am downloading now. I will let you know how I get on with it.

regards

Charlie

Mike

I have downloaded the branch as above but when i compile i get the following:-

Image Name: Linux-2.6.34-rc1-00098-ga450029-
Created: Fri May 18 09:17:20 2012
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2174812 Bytes = 2123.84 kB = 2.07 MB
Load Address: 0xC0008000
Entry Point: 0xC0008000
Image arch/arm/boot/uImage is ready

When i load and run it with my MDK-2012 sd card it fails with:-

kjournald starting. Commit interval 5 seconds
EXT3-fs (mmcblk0p1): using internal journal
EXT3-fs (mmcblk0p1): recovery complete
EXT3-fs (mmcblk0p1): mounted filesystem with writeback data mode
VFS: Mounted root (ext3 filesystem) on device 179:1.
Freeing init memory: 132K
Failed to open /dev/kmsg for logging: No such file or directory
modprobe: FATAL: Could not load /lib/modules/2.6.34-rc1-00098-ga450029-dirty/modules.dep: No such file or directory

Failed to mount /dev: No such device

Have i done somthing wrong with the download?

I used the following to download:-

git clone git://support.criticallink.com/home/git/linux-davinci.git mitydsp-linux-v3.2

regards

Charlie

I don't think your compiled correctly or uploaded the correct uImage to the machine.

The "Image Name: Linux-2.6.34-rc1-00098-ga450029-" suggests that your are still building off the master branch, and not the mitydsp-linux-v3.2 branch.

You should be doing commands something like (and forgive typos please):

git checkout -b mitydsp-linux-v3.2 origin/mitydsp-linux-v3.2
make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- industrialio_defconfig
make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- uImage

-Mike

Mike

Thanks, that did the job.

The bad news is that 3.2.0 does not have KS8995 support. It seems that this only starts in 3.3.0

regards

Charlie

Mike

I have been working on getting linux kernel version 3.3.0+, which I downloaded from linux-davinci, working on the MiyDSP-l138 board, both when mounted on the industrialio board and on our development board, on our board principally for the KSZ8995MA switch.

I have managed to get it working on the industrialio board, using the single ethernet port, but I can't get our board to work with the switch. The linux works and it seems to recognise the switch but I can't ping anything other than the loopback.

I would still like to do the work myself, since I think you learn more that way, but I need some help in recognising what is not working and in which direction I should go to solve the problems. At the moment I have not diasbled any of the features for the industrialio board when running the MityDSP-L138 board in our dev board.

I have attached 3 files(zipped) which are the schematic, the information about what I have tried and the current state of the debug port output on our dev board.

Please could you, when you have time, have a look at these and see if you can identify the problem. I may ultimately give up and ask you to give me exact instructions but for now I would just like help in solving this problem

I have modified the schematic which I have sent to you to correct a problem with the switch hardware config pins, SCONF0-SCONF2. I had intended to connect thes to i/o pins to allow me to change them but forgot to put this on the schematic and therefore on the PCB. I have therefore manually set these to give a value 0f 0b110, which I belive will set the KSZ8995MA to have the switch MAC connected to the MII switch port and the PHY5 connected to the MII PHY port. You will see from the schematics that I have put jumpers on the dev board to allow me to change this port.

Regards

Charlie

Charlie,

A quick thing that could be a problem are these messages:

No entry for the specified index
No entry for the specified index

This means that there are pin-mux definitions that aren't included in the da850_pins[] array in the da850.c file. That's bad, because the current pinmux code bails on the first undefined pin, so you could have missed assigning a bunch of pins in the pinmux array. You should fix that first so these error messages go away.

For moving forward to 3.3, you might be able to fetch a clean 3.3 linux from linus' repository and simply do a "git merge" to roll the port forward. The conflicts should be minimal (if any).

-Mike

Mike

I can't find what is causing these two error messages. Any help would be appreciated.

Also, I am no expert on the git system. I have download a new version of the kernel version 3.3.7.

If I use "git merge ../linux-3.3.7 master", I get the message "fatal: '../linux-3.3.7' does not point to a commit". I assume that the "master" in the previous example is the branch.

If I try to "git merge ../linux-3.3.7" it again tells me that the ../linux-3-3-7 folder, where the new version exists, does not point to a commit.

I did try to use 'git pull', "git pull ../linux-3.3.7 master", which produced different results, but indicated a whole raft of removals and a few conflicts. This one does, however, update the version to 3.4.0 (not 3.3.7) when I use menuconfig. Does this mean this has worked?

Again, I will need help to try this one out.

regards

Charlie

Mike

I have successfully merged the version 3.4.0+ with the mitydsp-linux-3.2, but i stil can't get the KSZ8995MA chip to work. It seemd to be recognised but i can't ping anything. The two error messages have now gone. Please could you look at the attached boot debug messages and advise?

If I use the mii-tool I get the following response:-

root@mityomapl138:~# /mii-tool
eth0: no autonegotiation, 100baseTx-FD, link ok

But only on port 1.

regards

Charlie

OK Charlie,

Three things:

1) In the board file, I think you need to configure the emac_pdata->phy_id to "". This means that the kernel should assume the PHY is always connected (which it is).

2) Not sure how the strapping works for this part, but keep in mind that, most likely, any lines connected to the OMAP-L138 will see pull-ups (the OMAP-L138 uses internal pull ups on power-up reset for nearly all the I/Os). This has caused us a lot of grief on various board designs. It may be possible that you aren't getting good strapping setup (which is why software control is desirable).

3) Looking at the (new) spi driver for this part, it looks like the driver doesn't do a whole lot except create a couple of sysfs files that will allow access (via userspace software) to modify the registers. The driver doesn't to much to update the registers on the chip for you. You still need to configure the chip for your operation (enable ports, disable port, etc).

It looks like the driver creates a file under /sys/devices/platform/spi.../ks8995/registers (not sure the exact name without building it). This file will behave like a register map. To modify a register you need to write at a word offset (1 byte) of the register a 1 byte value. Same for a read.

(I am just reading the driver, haven't tried this, so your mileage may vary).

To read a register, say the chip ID0, you could try:

dd if=/sys/devices/path/to/registers count=1 bs=1 skip=0 | od -x

to read the second register:

dd if=/sys/devices/path/to/registers count=1 bs=1 skip=1 | od -x

I think you need to write a small application that opens this file, does a series of seek() calls and reads/writes the necessary registers using read() or write() with lengths of 1 byte to configure the device the way you need it (VLANs, port management, etc.). We wrote scripts to that, but I think we used the MDIO interface and used the mii utilities to poke at the same registers as we haven't integrated the SPI stuff (or, we may have written a custom SPI userspace peek/poke utility, I need to circle back with the lead developer on that job, who was on vacation last week).

-Mike

Mike

Thanks for the suggestions.

1) The line you mention is the line I had to remark out to get the unit to run. I have now changed it as per your suggestion and linux now runs correctly, but still not the switch.

2) I am not sure what you mean by strapping, but on the assumption that you mean the resetting of the chip, I have checked out the boot up and it seems clean. When the chip boots up it flashes each of the leds twice. I don't know if this is normal but it seems consistant. After that the leds come on normally for the ports which are connected and the switch works correctly as a 5 port switch.

3) The driver file it uses is ./drivers/net/phy/spi_ks8995.c. My understanding of linux drivers is limited, but I can see it has a function, "ks8995_init" which runs and prints a message at boot up. This also calls a function, "spi_register_driver", to which is passed a *struct. This is where I get lost. I am not sure if it should call ks8995_probe or not, but this function is NOT called. I have added a couple of 'printfk' messages at the start but they do not get printed.

I can not find the driver '/sys/devices/platform/...../ks8995/registers' that you mentioned. I am not sure if it is being created. This is the only reference to registers. "./sys/kernel/debug/regmap/spi1.2/registers"

One thing that struck me, was that the chip select line is not driven. I am using GPO_15(pin 20 on the SODIMM connector) to drive this. I have added a few lines to initialise the CS in the baseboard-industrialio.c file, function 'baseboard_setup_spi()' in the same way as the CAN controller, but I have not added anything to spi_ks8995.c, nor do I know how to add anything, without it possibly conflicting with the other spi devices.

On my board, I do not have the CAN controller or the DSD1791 but there is another CS called SPI_INTERN_CS which may be the on board nor flash. Do I need to use a special CS pin to prevent a clash? Also, where would the CS control be implemented? Maybe I can look though the CAN controller for an example.

Does this make sense and if so, what can I do to fix it?

regards

Charlie

Hi Charlie,

I will try to respond tomorrow with details. Ran out of time today. Sorry for the delay.

-Mike

Hi Charlie,

I went back and reviewed your hardware design.

It looks like you have PS1 and PS0 floating on your design. This will result in the Serial Bus configuration to become "I2C Master Mode for EEPROM" and will set the personality of the SCL/SPIC and SDA/SPID pins to SCL/SDA (respectively). The SPI mode will not be enabled on the KS8995MA for control, which may explain why the device isn't coming up correctly. Are the default settings (when no EEPROM is available) for the MII ports correct for your board design?

-Mike

Answers to numbered items above:

1) OK.

2) By strapping I mean the power on reset state of the KS8995MA. Often, PHYS strap boot options on pins that are shared between the processor and the PHY. If the processor is pulling stuff up or down it can mess up the boot strap sequencing. I don't think that concern applies with the KS8995MA as the configuration pins are separate from the MII interface pins hooked to the OMAP-L138.

3) The linux driver SPI framework has a couple of pieces: The SPI bus driver (spi_davinci.c), the SPI chip driver (spi_ks8995.c) and the SPI instance / configuration (stuff in your platform file). The platform file tells the kernel what SPI busses are present and could be configured, and it tells the SPI bus driver about what chips (and their respective chip select lines and SPI modes) are on each bus. The SPI chip driver is abstracted from the SPI bus driver so that it may work connected to any SPI bus interface (so you can use an OMAP-L138 SPI bus, or a PowerPC SPI bus, etc.).

The sequence of events sort of looks like this:

For each SPI Device:
1) Platform Initialization (baseboard-xxxx.c) sets up pin-muxing for each SPI port (chip selects, clock and data lines).
2) Platform Initialization describes each SPI bus configuration via a da8xx_register_spi():
- number of chip selects
- SPI bus driver to use (spi_davinci.c)
for each chip select:
- device that is connected (spi_ks8995.c)
- chip select configuration (what GPIO or "internal" chip select pin)
- SPI Mode
- max bus speed
- etc.

Once that is done, at some point the kernel device framework comes along and starts matching devices to device driver code.

For each SPI device:

1) The kernel searches for a driver that's name matches the one in the registration data ("spi_davinci"). This results in a call to the spi-davinci.c davinci_spi_probe() call.
2) The devince SPI bus driver sets itself up, and if all is OK, the SPI framework then hunts for chip drivers on each SPI bus.
3) The spi_ks8995.c routine (registered in the _init call you mentioned above) shows up, and the _probe() call for that device is run.

If the _probe() routine in the spi_ks8995.c is not getting run, then something didn't work along the way.

Based on your comments I think it is getting run, but it is failing because it's trying to do a transaction to confirm the device is there, but the KS8995 is not talking SPI, it's talking I2C. So the probe routine fails, and the device is not getting set up.

On our implementation, we have to set bit 0 of the start Chip ID1 / Start Switch register because we are configuring the unit to run in SPI mode.

Mike

Yes, I have only spotted that today, but when I changed the inputs to 0b10, with some difficulty since they are tiny pins, the unit still does not work. I have missed a few bits out but I suppose that is why we do dev boards.

However, the info you have just given me looks to be very useful. I realise now that I have to do more editing to the baseboard-industrialio.c file. I have not added to the "baseboard_spi1_info" struct, which I think I need, so i guess it will not be driving the CS pin anyway. I will have to do a good deal of work to understand fully how this all hangs togther. This struct also points to other struct's, so I will have to understand what they do. There may be other parts that I have missed.

I will get back to you when I have tried this out, hopefully with good news.

Once again, thanks for your help.

regards

Charlie

Mike

I am back on this project after being called to sort some problems out.

I have sorted out the hardware issues and I belive that this is now correct.

I have edited/added to the baseboard file, (see attached) but with no success. The chip select line is not being toggled. I can drive it directly from the 'baseboard_setup_spi()' function and this works fine, but it does not get driven by the linux setup. I presume that I have missed something, but I can't see what that is.

Could you have a look at the attached file and see if there is anything? Are there any other files that I should edit?

I have changed the definition "#define SPI_MAX_CHIPSELECT 2" to a value of 3 in file spi-davinci.c with no results.

Any help will be appreciated.

regards

Charlie

Hi Carlie,

Can you attach your .config file and the dmesg outputs? The SPI_MAX_CHIPSELECT is a good catch. That needs to be fixed upstream, sometimes those guys get a little nuts trying to save a couple of bytes. The davinci spi can handle a lot more than 2 chip selects...

(I don't see anything obvious yet).

-Mike

Mike

I have attached the .config and a copy of the dmesg with the L138 SOM board plugged into our dev board and also with it plugged into the industrialio board.

I am not sure what you mean about SPI_MAX_CHIPSELECT. Do I have to increase this number further?

If there is anything else that might help please let me know.

regards

Charlie

Ok Charlie,

You need to do a little more work on your baseboard file. You need to make sure you strip out all of the stuff that isn't on your host board.

The culprit, I think, is that you are still calling baseboard_setup_mcasp(), which calls davinci_cfg_reg_list(baseboard_mcasp_pins) and includes a MUX setting for DA850_ACLKR. This is the same pin are GP0¹⁵ (your chip select line). So you are whacking the pin mux config for the GP0¹⁵ pin.

You need to remove all the device initialization from the Industrial I/O board reference file for the devices that aren't on your board or you are going to have problems.

Based on your schematic, you should be removing:

1. baseboard_setup_mcasp() and all of it's support structures including spi_dsd1791_config - you have no audio devices on your board.
2. baseboard_setup_lcd(const char *panel) and all of it's support structures - you have no display devices on your board.
3. spi_mcp2515_config structure and chip select entry - you don't have this chip on your board

After this, your chip select array should only be of length 2 (one for the on-module NOR, one for your switch):

static u8 spi1_cs[] = {
        SPI_INTERN_CS,
        KS8995_CS,
};

You board file should be a lot smaller and much simpler, and most importantly, you won't be overwriting your mux settings for the CS GPIO pin you need.

-Mike

Mike

Thanks for that. Now the spi interface works (but not the switch). I now get the following at boot up.

Micrel KS8995 Ethernet switch SPI driver version 0.1.1
Micrel KS8995 Ethernet switch SPI driver KS8995MA Probe Entered
Micrel KS8995 Ethernet switch SPI driver KS8995MA Probe
spi-ks8995 spi1.1: KS8995 device found, Chip ID:0, Revision:4

I selected a pin labeled OMAP_GPI0_xx because i thought that the "OMAP_GPx_xx" indicated an un-used pin. I still can't find were it is used, but no matter, now it works.

Now I just have to figure out how to setup the MII interface to make the ports work. If you have any example code for this I would appreciate something to learn from and/or refer to.

thanks

Charlie

Mike

I am using mii-tool to test that mii interface. I have used ths before with no problem, but now I get a linux error status as per the attached file. Any ideas what I have set wrong?

regards

Charlie

Mike

I have finally got the switch to work. The last problem was that I had set the CONF0-CONF2 bits to 0x110, which sets MAC 5 to MAC operation. I have now set it to PHY (0b101) and I can now connect to the network.

Thanks for all you help.

regards

Charlie

Charlie -

Thanks for the update, great news!

Tom