 Show Posts
|
|
Pages: [1] 2 3 ... 10
|
|
2
|
General Category / Success stories / Re: GuiPlug - using a plug as a full PC with Touchscreen or Vnc - Download it.
|
on: May 18, 2011, 06:02:00 AM
|
I have downloaded and dd'd the 8GB image to a SDHC card; but, my white Sheeva (from Globalscale) won't start. There is no uInitrd in the SD partition with the uImage so at start up I get the message "** Unable to read /uInitrd from mmc 0:1 **". I have a SD card (not from NewIT) that I have been using for a while with these boot env values: Marvell>> printenv
baudrate=115200
loads_echo=0
rootpath=/mnt/ARM_FS/
netmask=255.255.0.0
console=console=ttyS0,115200
CASset=min
MALLOC_len=1
ethprime=egiga0
bootargs_root=root=/dev/mtdblock2 ro
ethmtu=1500
usb0Mode=host
nandEcc=1bit
ethact=egiga0
serverip=10.10.0.2
ipaddr=10.10.0.1
cesvcid=ULULULULULULPPULULULULULDA
bootargs_end=:::DB88FXX81:eth0:none
image_name=uImage
standalone=fsload 0x2000000 $(image_name);setenv bootargs $(console) root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end) $(mvPhoneConfig); bootm 0x2000000;
mvPhoneConfig=mv_phone_config=dev0:fxs,dev1:fxs
mvNetConfig=mv_net_config=(00:11:88:0f:62:81,0:1:2:3),mtu=1500
yuk_ethaddr=00:00:00:EE:51:81
netretry=no
rcvrip=169.254.100.100
loadaddr=0x02000000
autoload=no
ethaddr=00:50:43:01:47:58
run_diag=no
arcNumber=2097
bootargs_console=console=ttyS0,115200
bootcmd_mmc=mmcinit; ext2load mmc 0 0x0800000 /uInitrd; ext2load mmc 0 0x400000 /uImage
bootcmd=setenv bootargs $(bootargs_console); run bootcmd_mmc; bootm 0x400000 0x0800000
stdin=serial
stdout=serial
stderr=serial
nandEnvBase=a0000
mainlineLinux=yes
enaMonExt=no
enaCpuStream=no
enaWrAllo=no
pexMode=RC
disL2Cache=no
setL2CacheWT=yes
disL2Prefetch=yes
enaICPref=yes
enaDCPref=yes
sata_dma_mode=yes
netbsd_en=no
vxworks_en=no
bootdelay=3
disaMvPnp=no
enaAutoRecovery=yes
pcieTune=no
bootargs=console=ttyS0,115200
Environment size: 1335/131068 bytes
Marvell>>
I think the problem lies in these: bootcmd_mmc=mmcinit; ext2load mmc 0 0x0800000 /uInitrd; ext2load mmc 0 0x400000 /uImage
bootcmd=setenv bootargs $(bootargs_console); run bootcmd_mmc; bootm 0x400000 0x0800000
I'd really like to use this build with my Mimo so can you tell me what to change next? I added the uInitrd from my current SD card to the uImage partition of this card and then the ext2load command for uImage never completes. Does this image require an uInitrd at all? Thanks for any help you can provide.  |
|
|
|
|
3
|
Hardware and U-Boot firmware / Hardware / Re: using i/o ports
|
on: November 05, 2010, 05:06:52 AM
|
Mine do. Some people believe that causing the Plug to continuously drive a large USB port current (rotating media, displaylink, etc.) helps to cause premature power supply failures. All the USB-Serial devices I've used haven't require much current so you should probably be safe. Does the BrainStem GP 2.0 get power from the serial port (parasitic) or somewhere else? |
|
|
|
|
4
|
Hardware and U-Boot firmware / Hardware / Re: using i/o ports
|
on: November 04, 2010, 06:48:11 AM
|
|
It is possible to attach a screen to the plug via a USB attached VGA adapter or touch panel. (search for Displaylink on this site)
It is possible to attach one or more USB-to-serial adapters (for RS-232 communications) and/or a USB keyboard/mouse as well to the plug.
You will need a POWERED USB 2.0 hub to attach all of these things at once.
|
|
|
|
|
10
|
Hardware and U-Boot firmware / Hardware / Re: Probing gpio pins from userspace using /dev/mem
|
on: October 25, 2010, 08:55:49 AM
|
Unfortunately, everything I've written was paid for (and owned) by a client so I don't have any personal sample code I can give away. Sorry.  Of course the source code for all the drivers in the kernel distribution is available. Also, Google-ing "linux device drivers" yields a BUNCH of introductions, tutorials and books. Just be careful that some of it is old and the kernel interface has and can change quickly. You want to use a simple monolithic character driver with an interrupt service routine. I can't think of a single driver that would be a good starting point since most of the latest kernel drivers are part of one or more "frameworks" and are neither simple nor monolithic. EDIT: After increasing my blood sugar level - perhaps a driver that attaches to the input event mechanism would work for this? If there were a small driver that sent IO change events through the evdev, the user software could open a /dev/input/eventX device and use standard read() or select() code to wait for change reports. |
|
|
|
|
11
|
General Category / General Discussion / Re: UPS Auto shutdown for SheevaPlug?
|
on: October 25, 2010, 08:26:54 AM
|
Unfortunately, no. The documentation I have on my machines is old and the stuff I found on the net says "Last updated: 5 July 2007". At some point, I read enough of the NUT source code to figure things out for my particular setup. Sorry. EDIT: Here is a how-to from 2008 for OpenSuse. It MIGHT help. Or not. HowTo Link |
|
|
|
|
12
|
Hardware and U-Boot firmware / Hardware / Re: Probing gpio pins from userspace using /dev/mem
|
on: October 22, 2010, 11:33:19 AM
|
First, I am looking for the fastest possible way to sequentially sample and/or output to the GPIO pins so I am looking for the method that has the least overhead (without resorting to assembly code or anything too hard).
The input pins sampling method with the least overhead is to not sample them. Implementation involves setting the input pins up to cause an interrupt when they are changed by exterior signals. This, however, requires kernel code (a device driver, usually) to handle the interrupt condition and user code to handle a propagated "IO change" event. Determining a purely user space alternative requires an understanding of the maximum "IO change" event propagation delay that can be tolerated. In short, the less delay that can be tolerated, the higher the priority of and the smaller the sleep time in the polling loop (both of which increase the overhead associated with the method). 4. Just out of curiosity, do you have to call mmap each time you want to re-read/write a GPIO line or does it only need to be done once at initialization and then it is just sufficient to reread the pointer to the mmapped region.
You only need to mmap() the registers once and then reference them via the pointer any time you want to poll the lines or change them. The pointer will remain valid until the program terminates or you call munmap(). I hope this helps. |
|
|
|
|
13
|
General Category / General Discussion / Re: UPS Auto shutdown for SheevaPlug?
|
on: October 22, 2010, 10:54:26 AM
|
|
I had the NUT server running on one plug (attached to a small UPS via serial/USB) and the NUT client running on all three of my plugs scattered around the house. It all worked as advertised. If I remember right, the documentation was horribly out-of-date when I started configuring all of this.
Now I have my media server (not a Plug) watching a larger UPS (due to rotating media) and have the three plugs powered from that same UPS; but, not running the NUT client. When the media server turns off after 15 minutes of power loss, the larger UPS can power the Plugs for HOURS.
|
|
|
|
|
15
|
Hardware and U-Boot firmware / Hardware / Re: My sheeva starts with system clock set to april 1960...
|
on: October 12, 2010, 06:56:19 AM
|
Rats! Everything I found about the "Timed out waiting for time change." message says the Real-Time Clock (RTC) hardware support is not compiled into the kernel, the hardware is toast or there is no battery. Another idea I had was this might be a symptom of the known problem with kernels before 2.6.32 on newer hardware; but, since you are using a .32 kernel, you should not be experiencing that particular problem. Just to be sure, could you use the dmesg command and check for a line that contains "Kirkwood: MV88F6281" and make sure it has a valid chip revision value? While looking at the dmesg output, you could also look at any RTC messages for possible problems. I'm running out of ideas. |
|
|
|
|
