• Home
  • Help
  • Search
  • Login
  • Register
  Show Posts
Pages: 1 [2] 3
16  Hardware and U-Boot firmware / Hardware / Re: Probing gpio pins from userspace using /dev/mem on: April 19, 2009, 12:31:54 AM
Today I took apart a microSD -> SD adapter card and soldered wires onto each pin.

I used an old floppy-disk cable for the wires, and as a bonus, it has a built-in breadboard (the FD connector Wink

I've tested each pad, and they all work. Now i can start playing around with the GPIO stuff in earnest.

I'll post pictures and more steps tomorrow night.

-tmk
17  Hardware and U-Boot firmware / Hardware / Re: Probing gpio pins from userspace using /dev/mem on: April 17, 2009, 11:46:21 PM
WARNING WARNING

If you change the wrong bits, Very Bad Things can happen. I changed GPP pins 12-19 instead of 12-17, and 18/19 are involved in the NAND flash interface. Needless to say, i was reflashing my filesystem shortly thereafter.

Use these instructions at your own risk.

WARNING WARNING


I've gotten writes to work as well, and confirmed that my pins are correct:

Now that i've found the pins i think control SDIO/GPP for GPIO pins 12-17, i want to change their function from SDIO to GPP.

First, find where pins 12-17 start:

Code:
This is 8-15
root@charger:~# ./devmem2 0xf1010004 w
/dev/mem opened.
Memory mapped at address 0x4001f000.
Value at address 0xF1010004 (0x4001f004): 0x11113322

Slide up 2 bytes from ...4 to ...6 and you get 12-19:

root@charger:~# ./devmem2 0xf1010006 w
/dev/mem opened.
Memory mapped at address 0x4001f000.
Value at address 0xF1010006 (0x4001f006): 0x11111111

Ok, now we've found 12-19. Let's flip 12-17 to 0 (leave 18,19 alone!!!) to set them to GPIO pins.

Code:
root@charger:~# ./devmem2 0xf1010006 w 0x11000000
/dev/mem opened.
Memory mapped at address 0x4001f000.
Value at address 0xF1010006 (0x4001f006): 0x11111111
Written 0x11000000; readback 0x11000000

Let's test it.

I know my 2gb SD card works, as i've mounted it before. So i plug it in..

Code:
root@charger:~# tail /var/log/kern.log
...
Apr 18 06:33:34 charger kernel: fat: exports duplicate symbol fat_add_entries (owned by kernel)

Hmm, nothing is logged. I know for sure that it worked before...

So, let's flip it back:

Code:
root@charger:~# ./devmem2 0xf1010006 w 0x11111111
/dev/mem opened.
Memory mapped at address 0x4001f000.
Value at address 0xF1010006 (0x4001f006): 0x11000000
Written 0x11111111; readback 0x11111111

and let's see if anything happened..

Code:
root@charger:~# tail /var/log/kern.log
...
Apr 18 06:33:34 charger kernel: fat: exports duplicate symbol fat_add_entries (owned by kernel)
Apr 18 06:37:13 charger kernel: mmc0: host does not support reading read-only switch. assuming write-enable.
Apr 18 06:37:13 charger kernel: mmc0: new high speed SD card at address 1234
Apr 18 06:37:13 charger kernel: mmcblk0: mmc0:1234 SA02G 1927168KiB
Apr 18 06:37:13 charger kernel:  mmcblk0: unknown partition table

Now there's an SD card detected! No doubt that flipping these bits takes immediate effect.

-tmk
18  Linux Stuff / Kernel / Re: Problems reflashing UImage, bad blocks on: April 17, 2009, 11:28:39 PM
note to those who may follow the instructions in this thread. I'm not sure that "nandwrite -p" is the right thing.

I accidentally fried my filesystem and needed to reflash the jffs2 image.


nandwrite -p did NOT work and in fact horked up the filesystem when flashing to /dev/mtd2. I rebooted and tried again without the -p flag. worked great.

-tmk
19  Hardware and U-Boot firmware / Hardware / Probing gpio pins from userspace using /dev/mem on: April 17, 2009, 10:23:20 PM
For those who (like me) didn't realize it existed, I found a handy way to probe random memory addresses from userspace: /dev/mem.

This lets you directly read kernel and/or device memory! very useful.

A program to access it is here (not written by me): http://ftp://ftp.buici.com/pub/arm/devmem/devmem2.c

I should mention that i modified the original program to pad the output to the size of the request, or else it leaves off/truncates leading 0's. patch is here:
Code:
--- devmem2.c.orig 2009-04-17 22:20:05.226440750 -0700
+++ devmem2.c 2009-04-17 22:09:21.483230909 -0700
@@ -90,18 +90,20 @@
     switch(access_type) {
  case 'b':
  read_result = *((unsigned char *) virt_addr);
+                        printf("Value at address 0x%X (%p): 0x%02X\n", target, virt_addr, read_result, read_result);
  break;
  case 'h':
  read_result = *((unsigned short *) virt_addr);
+                        printf("Value at address 0x%X (%p): 0x%04X\n", target, virt_addr, read_result, read_result);
  break;
  case 'w':
  read_result = *((unsigned long *) virt_addr);
+                        printf("Value at address 0x%X (%p): 0x%08X\n", target, virt_addr, read_result, read_result);
  break;
  default:
  fprintf(stderr, "Illegal data type '%c'.\n", access_type);
  exit(2);
  }
-    printf("Value at address 0x%X (%p): 0x%X\n", target, virt_addr, read_result);
     fflush(stdout);
 
  if(argc > 3) {

To build, i used the GCC included in the linux host package.

Code:
gcc/bin/arm-none-linux-gnueabi-gcc devmem2.c -o devmem2

scp devmem2 user@sheevaplug:

For example, say you want to figure out how the GPIO pins are programmed.

For the HW offsets, we consult the marvell docs  MV-S104860-U0 (p773) and MV-S104859-U0 (page 53).

I am interested in the GPIO pins, 12-17, as these are shared with the SDIO. I am willing to break the SD card access if i can use those pins for GPIO.

Consulting page 774, i see that the memory offset for the register function controls is 0x10000. Based on the mmc module init message (mvsdmmc: irq =28 start f1090000) , i know that the base is 0xf1000000.

So let's query 0xf1010000 through 0xf1010008, to see how the pins are currently programmed:

Code:
root@charger:~# ./devmem2 0xf1010000 w
/dev/mem opened.
Memory mapped at address 0x4001f000.
Value at address 0xF1010000 (0x4001f000): 0x01111111

root@charger:~# ./devmem2 0xf1010004 w
/dev/mem opened.
Memory mapped at address 0x4001f000.
Value at address 0xF1010004 (0x4001f004): 0x11113322

root@charger:~# ./devmem2 0xf1010008 w
/dev/mem opened.
Memory mapped at address 0x4001f000.
Value at address 0xF1010008 (0x4001f008): 0x00001111

The right-most bits represent the lower #'d pins. So GPP pins are set as follows:
Code:

Value at address 0xF1010000: 0x01111111
 0-6 are all set to 1
 7 is set to 0

Value at address 0xF1010004: 0x11113322
 8,9 are set to 2
 10,11 are set to 3
 12-15 are set to 1

Value at address 0xF1010008: 0x00001111
 16-19 are set to 1
 20-23 are set to 0

I'm interested in 12-17. All are set to '1'. Checking page 53 of the Hardware spec, i see that this indicates they are currently set as SDIO pins. This jives with what i expect. As a sanity check, 8,9 are 2, and 10,11 are 3. These group together to form 4 pins for serial port UA0. Bingo!

I have not tried using /dev/mem to make changes to the settings, but i plan to soon. Stay tuned.

-tmk
20  General Category / General Discussion / Re: Instructions: Getting the serial console to work on a MAC on: April 16, 2009, 08:27:12 PM
Sorry for the noobness, but how do I patch that Info.plist file? do I create a patch with diff, or what?
Thanks for the directions either way

usually you just run

Code:
patch -p0 < patchfile

-tmk
21  Hardware and U-Boot firmware / Hardware / Re: i2c and/or GPIO? on: April 16, 2009, 12:11:48 AM
I found where the GPIO functions are first called out by the kernel:

Code:
arch/arm/plat-feroceon/mv_hal/gpp

Should be a good starting place for poking around.

-tmk
22  Linux Stuff / General Linux questions / Re: HOWTO mount JFFS2 image on Linux host without NAND flash on: April 15, 2009, 11:43:46 PM
argh. broken from the website.

I even downloaded it again, thinking it might have gotten corrupt in the transfer

Ah well, i'll try with a known-good one next time, thanks.

-tmk
23  General Category / General Discussion / Re: Instructions: Getting the serial console to work on a MAC on: April 15, 2009, 11:01:17 PM
Watch out - that FTDI driver seems to have a fairly common USB ACM bug that causes a panic if the client device shuts down.   Best to unplug the serial cable if you need to power off the SheevaPlug...

:<

I hit this today. I unplugged the USB cable with the plug still running (screen still attached to it) and the machine died. It was kind enough to tell me i needed to reboot in 3 or 4 languages though :)

I think the bug may be related to having an open process reading the serial port at the time it disconnects.

-tmk
24  General Category / Success stories / Re: USB GPIO on: April 15, 2009, 10:58:40 PM
Hi,  Thanks for sharing the info!

I am interested in using my plug for a very similar purpose..

Once i get my filesystem/kernel in order, the first think i'll work on is getting the GPIO pins from the plug linked up with the kernel driver for dallas 1-wire (or i2c). That should let me do everything without any extra hardware, which is the reason i bought the plug to begin with Smiley

-tmk
25  Linux Stuff / General Linux questions / Re: HOWTO mount JFFS2 image on Linux host without NAND flash on: April 15, 2009, 10:40:37 PM
I gave this a try, and the file mounts OK, but it doesn't contain any files. Additionally, my dmesg is filled with this stuff:

Code:
[137378.064209] jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00068e0c: 0xecf3 instead
[137378.064211] jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00068e10: 0xc02d instead
[137378.064214] jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00068e14: 0x6c7a instead
[137378.064216] jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00068e18: 0x77c7 instead
[137378.064219] jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00068e1c: 0x3116 instead
[137378.064221] jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00068e20: 0x703d instead
[137378.064223] jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00068e24: 0x351e instead
[137378.064226] jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00068e28: 0x974c instead
[137378.064228] jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00068e2c: 0x1b95 instead
[137378.064231] jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00068e30: 0x5c6f instead
[137378.064233] Further such events for this erase block will not be printed

What i get at the end is a bunch of directories (/etc, /home/ etc..) but no files in them.

Suspecting an incorrect erase-size, I have also tried specifying some module options to block2mtd module:
Code:
     modprobe ${BLKMTD} block2mtd=${LOOP},256|| exit 1

No luck there either.

Any ideas?

-tmk
26  Linux Stuff / Linux distributions / Re: Clock working? on: April 15, 2009, 10:11:49 PM
works for me, using stock filesystem/distribution:

Code:
root@charger:~# hwclock --show
Wed Apr 15 22:11:00 2009  -0.679639 seconds

-tmk
27  Linux Stuff / Kernel / Re: Problems reflashing UImage, bad blocks on: April 15, 2009, 10:10:31 PM
bunch of bad blocks here as well.

Code:
Scanning device for bad blocks
Bad eraseblock 2050 at 0x10040000
Bad eraseblock 2051 at 0x10060000
Bad eraseblock 2061 at 0x101a0000
Bad eraseblock 2064 at 0x10200000
Bad eraseblock 2067 at 0x10260000
Bad eraseblock 2102 at 0x106c0000
Bad eraseblock 2151 at 0x10ce0000
Bad eraseblock 2202 at 0x11340000
Bad eraseblock 2726 at 0x154c0000

It seems to pause on boot, just after initalizing eth0. It seems like it's scanning the flash or something. Is this normal?

Code:
md: autorun ...
md: ... autorun DONE.
eth0: link up, full duplex, speed 100 Mbps
..... pause ~ 60 seconds .....
Empty flash at 0x0e2b2080 ends at 0x0e2b2800
VFS: Mounted root (jffs2 filesystem).
...

-tmk
28  Linux Stuff / Linux distributions / custom kernel, nfs boot working! (quick howto) on: April 15, 2009, 10:03:17 PM
Got my plug to boot up using a custom kernel and NFS today.

Some notes:

ubuntu's default tftpboot directory is '/srv/tftp' and NOT '/tftpboot'. This can cause problems.

the instructions in the file 'Procedure to configure the kernel with 4.2.7 LSP for KW(A0)based device v4.1.pdf' assume you use /home/SheevaPlug for your filesystem (from linux host package, file Linux Host Filesystem - rootfs.tar.bz2). Untarring the way they specify creates an extra directory though, and you have to move all the files out of it later.

Untar and move the files as root, or else permissions may get broken.


The instructions also say you should export your /tftpboot directory (or /srv/tftp).. I see no reason to do this

Docs say to export /home .. that is also not necessary; it just needs the SheevaPlug directory Here's my /etc/exports:

Code:
/home/SheevaPlug *(rw,sync,no_root_squash,no_subtree_check)

general kernel compile steps (feel free to add this to a wiki)

Files can be found at http://www.marvell.com/products/embedded_processors/developer/kirkwood/sheevaplug.jsp, or on your cd, etc.

You'll need 3 packages:
Download linux 'host software support package - contains the compiler+toolchain, and base jffs2 (which we don't really need)

Download the "Linux support package" -  this contains the kernel source, and a stock kernel uImage.

Download the U-boot package - this contains the mkimage binary.


unzip these container .zip files, we'll deal with the contents later.

Code:
# make a new dir to hold all your work
mkdir /home/plugstuff
cd /home/plugstuff

# extract the stuff (takes a while)
tar jxvf {path-to}/LinuxHost/gcc.tar.bz2
tar jxvf {path-to}/Sources/linux-2.6.22.18.tar.bz2

# copy the mkimage binary to the gcc/bin dir (or anywhere else in your path)
cp {path-to}/SheevaPlug_U-Boot/mkimage gcc/bin/
# make it executable.. lame packaging :)
chmod a+x gcc/bin/mkimage

# add the gcc binary location to the path (assuming bash)
export PATH=/home/plugstuff/gcc/bin:$PATH


# build kernel
cd linux-2.6.22.18
make mv88f6281_defconfig
make
{wait while it compiles}
make uImage
At this point your uimage will be in arch/arm/boot/uImage . Copy it to your tftpboot dir if you want to netboot it.

Assuming you are using NFS for your plug, and already have a working NFS filesystem in /home/plugstuff/root/

Code:
# install the modules
make INSTALL_MOD_PATH=/home/plugstuff/root/ modules_install
29  General Category / General Discussion / Re: Problems getting NFS to work on: April 15, 2009, 08:01:46 AM
Not sure if its been mentioned, but i think the u-boot image is obtained via tftp, not NFS, then the root filesystem is mounted once NFS is up.

Can anyone confirm or deny this? If so, you'll need to set up a tftp server as well.

-tmk
30  Hardware and U-Boot firmware / Hardware / Re: My SheevaPlug is very unstable on: April 15, 2009, 07:56:01 AM
This happened to mine once. I'll let you know if it repeats.

I wasn't on the console at the time, and didn't have any USB devices attached (besides console)

I did have a SD card in/mounted, and it's possible it was disturbed.. the SD connection is kind of flimsy.

-tmk
Pages: 1 [2] 3