Compact Flash Cards
![[Deleted User]](https://w0.vanillicon.com/v2/0187f1a608087cabcaa1e34b064ff753.svg)
[Deleted User]
Posts: 0
in AMX Hardware
Can NetLinx Master cards and/or NI-2000/3000/4000 controllers be upgraded via stock Compact Flash cards, instead of cards already loaded with firmware, etc.? I.e., can the blank card be put into the unit and then NetLinx Studio run to download firmware?
Customer has 1GB Compact Flash card already and wants to use it for upgrade in NI-3000 (instead of the 32MB that it comes with).
Customer has 1GB Compact Flash card already and wants to use it for upgrade in NI-3000 (instead of the 32MB that it comes with).
0
Comments
I think the short answer is no. The CF cards used in the Netlinx masters and in the touchpanels do not appear to use standard CF file systems. Although the compact flash cards used by AMX are industry standard, they need to be formatted properly for the target device. I am also not sure that even if you were able to format a standard CF correctly that you would not also have to pre-load certain files for the Master or the touchpanel to be able to bootstrap. I too would like to be able to use off-the-shelf CF cards for Masters and Touchpanels and did a little research into it. Perhaps someone with more in-depth knowledge can point us in the right direction.
Now, in reality, I've done it with a NXC-ME260 card. You most certainly need to be able to boot the card running some version of NetLinx firmware (the NetLinx firmware is receiving the new flash files to load, so putting a blank card in wouldn't work, I'd expect).
What I've done in the past: I had a 16MB (I think) CF card. I had a 256MB CF card. With a PCMCIA adapter, I made an exact copy of the files on a "good" compact flash card (the 16MB card) using Windows. I then put the new CF card in my laptop, copied the identical files to the card, put the card in the MXC-ME260, and it booted. After that, using NetLinx Studio, I was able to update the firmware, etc, to the new CF card, no sweat.
When I later had problems with an MVP-8400 (corrupted CF card), Tech Support was quite clear that this would NOT work. I didn't try it, since I didn't have a sample "good" card.
Jeff,
You are correct and I stand corrected - I just used a CF card reader to 'mount' a Master CF card on my laptop and the CF is indeed formatted with a FAT file system. Therefore, you could very well do as you suggest - format a new CF using Windows to create a FAT file system and then copy onto the new CF the files required for the Master. On my Master's CF, aside from the Token file that I downloaded to it and the ZIP file containing the sources, there is a vxWorks file and a file named bw. I suspect these are the critical files that must be present.
I also had a similar experience to yours with an 8400 that had become corrupt since a TPD4 transfer failed in the middle leaving the manifest file on the CF corrupt. I tried to examine the CF for the touchpanel but the file system was not FAT or anything that could be understood by the laptop. I thought the MVP panels were Linux based and perhaps the CF is formatted as a Unix file system - just speculation.
There are some hardware/software combinations on the market that will duplicate a CF card bit for bit without concern for the format or contents of the card. This would be an option for creating a CF that might work in an MVP panel.
What I haven't had success with is taking a CF card that I formatted as FAT on my laptop, copying same files onto it, and trying to use that to boot a master.
- Chip
One would think that you can write a "block copy" type application, such that a "good" CF card could be copied (block for block, bit for bit, without regards to file format) and create an identical file format on a second CF card *OF IDENTICAL SIZE*. One would think this could be done without hardware (other than getting access to the CF, like via PCMCIA or something).
Know of any software that can do that? It was pretty dang painful when I needed to send back an MVP-8400 due to a corrupt CF, when the hardware was otherwise perfect ...
-- Jeff
Jeff,
I did some research on Windows applications that would do raw CF copies (like a Unix dd) some time back. Here is a link to one of the sites I found but there are other packages out there and I will try to find some additional links:
http://www.cardupdate.com/mce/aboutmce.php
Applications that treat the CF as a raw device and do a sector by sector copy should be oblivious to file system type, files on the CF, etc.
I agree with you 100% on the 8400 issue - I had the same problem except Tech Support was able to overnight me a new CF which I replaced myself but as you pointed out, we were still down for 2 days with a perfectly good panel solely because of a corrupt file on the CF.
Reese
The CF cards contain the firmware and operating system, so you need to have those files on there. The NetLinx and Modero's are Linux based, so you also need your card to be formatted for a Linux system. If you have that all covered, you can in fact do an upgrade. However, there is a limit. The mainboard itself can only "see" a certain amount of memory - or perhaps can only accept a certain size card. This is why the upcoming Duet firmware requires the new masters. Expanding to that size card requires, as it was told to me, some very hokey manual modifications to the mainboard, which includes soldering jumpers and cutting circuit board lands. For obvious reason, AMX doesn't want to go there, therefore the new master requirement.
Dave,
I assume when you said Netlinx in your response that you meant the Master CF card was formatted as a Linux file system also. Are you positive about that? Chip and I have both mounted CF cards for the Master and they appear to be Windows FAT formatted. I thought that the Master was VxWorks based and used the FAT format for compact flash.
I agree with you on the Modero - it does appear to be Linux based and there are tools that allow a Linux based file system to be formatted or mounted under Windows so you could conceivably recover a Modero in an emergency if you had the right tools. I am mainly interested in quick recovery of Masters and Modero panels and not so much in expanding the capacity of the device CF cards more cheaply than buying from AMX. I do wish the CF cards from AMX were priced a little more reasonably.
On the impending Duet firmware, I was not aware of the limitation on expanding CF capacity and its dependence on the main board. I knew that the Master card required a certain amount of memory and that AMX had investigated being able to factory upgrade the ME cards to support the required minimum amount of memory but decided for cost reasons it was simply not an effective way to go.
Thanks,
Reese
Now that you mention it, my discussions with Tech Support were over the Modero's, and I assumed the NetLinx were the same. Every now and then I do that and confuse my speculations with the facts; sorry about the misinformation.
The CF cards will have several partitions, and it is not that simple to just copy files from an older to a new one. I believe that also some of these partitions will have different rights. AMX uses a special script to create the CF cards.
What a shame <cough> it would be if that script leaked out... Imagine being able to upgrade CF cards all by our lonesomes.
- Chip
It's better not to experiment with the flash cards, if you want the support from AMX. I fully understand their situation in this matter.
The claim I've heard is that it is all due to liscensing with vxWorks. Don't know if I buy it, don't know if I understand it.
All I do know is that it's awful nice on that other control system to just swap a CF card if you want more space AND not have to pay the completely stupid prices AMX wants for theirs.
At the VERY, absolutely minimally least - offer a list of supported CF manufacturers and a service with a MINIMAL charge where you send in your master's CF and a new, larger, approved CF, and in return get back the small CF wiped clean and the vxWorks image on the larger one.
- Chip
I think the main reason is support. The support people do not want to spend several hours for a lot of people to configure a Linux Computer and get everything working (and keep it working). They can use their time better.
The software that Reese mentioned should work. But as I looked into it, I'm uncertain of the support on that product. It hasn't been re-released for a long time, and I can't get a demo key for the product (their WWW site is broken). It's a UK based company, and I just didn't get the warm and fuzzies from an ongoing maintenance perspective.
I had considered that I could just write a small C++ program to do raw input and output to copy an image of the card. But that's just a specialized version of DD. I am comfortable with Linux, but my Linux server doesn't have PCMCIA slots, and I didn't want to try and figure out how to use a USB card reader.
So I ended up downloading Knoppix (from http://www.knoppix.org), a Linux CD-based distribution that has good driver support for most things. I put a compact flash card (mounted in a PCMCIA carrier) in my laptop and booted off the CD that I burned from the downloaded ISO.
Sure enough, Knoppix made it trivial to get at the compact flash card. For me, /dev/hde was the Compact Flash card. I could use 'dd' to copy an image, modify the data on the card, and then restore the image. This same method will work with MVP-8400 compact flash cards. For example, something like:
dd if=/dev/hde of=/tmp/MVP8400.image
will create an image of the compact flash card in the machine. Then, to restore it, you can do something like:
dd if=/tmp/MVP8400.image of=/dev/hde
By default, Knoppix boots everything in read-only mode, so you need to launch a root shell to do this (trivial, there's an icon for it). And, since my file systems on my laptop are NTFS anyway (not safe to write to), I use FTP to transfer these files to another machine (the files are created in a RAM file system). Knoppix had no problem launching the network on my laptop, so this was no problem.
All in all, this is an easy solution to create a known-good image backup of an MVP-8400.
If I feel strongly inclined, I could play with checking into using a larger card. Since I can always get back to a known state, I'll bet that it shouldn't be too difficult to look at the partition table with fdisk of sfdisk, pop in a bigger card, and experiment away. Just be aware that Knoppix uses a RAM-based file system, by default. So you need to have enough memory to store the image that you're playing with. Or you need to have a FAT file system to write to on the local machine.
Hope this proves useful. If you're concerned about this, I found that Knoppix made it trivially easy to save images of compact flash cards.
Jeff,
That is great information. Leon mentioned in an earlier post on this thread that he thought the CF for the touchpanels would have multiple filesystems. Did you try to mount the filesystems on the CF or did you just do the raw copy to RAM and then to a CF? I suspect that going to a larger CF would require we have more knowledge about the filesystem or filesystems on the CF and what files need to be located in which filesystems. This would also be good information to have. However, at least having the ability to create a new CF that is a copy of an existing touchpanel CF for emergency purposes is a great start. Thanks,
Reese
For now, I've only played with image backup/restore (RAW copy to/from RAM), which was my immediate, short-term need. I plan on looking more at this later when I get a "good" compact flash card to recover my MVP-8400 from.
This is low priority for me, though. The default (64MB?) card appears to be plenty big for me (I have about 32MB free).
Personally, I kinda wish that AMX would just make a recovery image for Modero touchpanels available on their WWW site, along with a brief how-to on how to recover it. Knoppix really does make it pretty dang easy. But this is a different topic. It just takes time to get new CF cards from AMX, which could be eliminated if something was available from their WWW site.
Howdy folks.
I had a little time to poke around at a MVP-8400 compact flash card.
The card is set up with four partitions, like this (I hope this comes out right):
Now, I couldn't figure out what file system lived in /dev/hde1 or /dev/hde2. My guess is that these are some sort of raw boot partitions, although it's hard to know for certain. I did note that /dev/hde3 contained no boot files (that I recall, anyway). So there's a very good chance that either /dev/hde1, /dev/hde2, or both are related to booting. The boot code has to be somewhere! Perhaps hde1 is the boot loader, and hde2 is the kernel? This could be the case, but 1MB seems awfully big for a boot loader ...
/dev/hde3 is an ext2 file system and /dev/hde4 is an ext3 file system. Somehow, I thought that AMX would have done something more clever like using jffs2, which is designed for CF cards; but I guess they view writes to the card as being infrequent enough to not make it worth worrying about.
/dev/hde3 (type ext2) contains UNIX utilities, networking code, driver code, etc. I was surprised at the number of UNIX utilities that they had for such a specialized purpose, but whatever ... This partition was 9.4M in size, 9.2M used, 182k free (or 99% full). Clearly, they don't expect to add things here. I guess it's small enough where even if they trimmed down the utilities quite a bit, they'd only save a MB or two, which answers my question of why they had so many UNIX utilities that would not normally be used.
/dev/hde4 is an ext3 file system that contains the panel files. On the demo CF, this is 48M in size, 24M free, 25M available (or about 50% free).
I believe extending these cards would be trivial. There are two ways to do it:
1) Create partition table of identical sizes for hde1, hde2, and hde3. Use dd to copy hde1 and hde2, use dump or dd to copy hde3 (you can use dd if the size is truely identical). Make hde4 as big as you want, restore this with restore (back up with dump) since the file system will be of a different size (bigger). You could trivially create a script to do this.
2) Restore a 64MB image to a bigger flash card, then delete the last partition, recreate it to fill the rest of the card, use newfs to initialize an ext3 file system, and restore (from dump/restore) this from the old card into a bigger file system.
I think #2 would be the faster solution, as you wouldn't need to muck around with the first three partitions at all.
Note that I haven't actually tried this; I just poked around a bit. But I see no reason why this wouldn't work (just as I saw no reason why 'dd' wouldn't work to copy the card - and it did work just fine).
This is just for grins and giggles. The 64MB card is plenty big for me. Although ... if I did have a ton more space, I likely wouldn't use dynamic images nearly as much. Heck, I could even store all my album art directly on the panel if I wanted to! ;-)
I may play with this a bit and actually try extending. Knoppix does have all the facilities you need to take care of this, which is nice (that enables me to use my Windows laptop to do all this, rather than muck with my UNIX server to do this stuff).
Anyway, that's what I found to date. Extending this cards looks like a fairly simple task with a laptop, a Knoppix boot CD, and a PCMCIA CF card adapter.
Hope this helps,
-- Jeff
This, it appears, is NOT the case. So, I stand corrected - I've corrected myself.
Where's what I did:
I took a 512MB Sandisk CF card ($43 at Costco), copied a 64MB partition to it, and manipulated the last partition. Basically, I did:
- dd if=MVP-8400.image of=/dev/hde (restore 64MB image)
- mkdir /mnt/hde4; mount -r /dev/hde4 /mnt/hde4 (mount read only)
- dump -0u -f /tmp/dump.hde4 /mnt/hde4 (back up last partition)
- umount /mnt/hde4
- fdisk /dev/hde (deleted last partition, recreated to fill remainder of CF card)
- mkfs -t ext3 /dev/hde4 (make new file system)
- tune2fs -i0 -c0 /dev/hde4 (optimize as AMX did)
- mount /dev/hde4 /mnt/hde4 (mount new file system)
- cd /mnt/hde4; restore -f /tmp/dump.hde4 (restore files)
Much to my surprise, this did NOT work. Gosh, and it seemed so simple! ;-) So I spent another 15 minutes troubleshooting.I learned that:
- When I copied a 64MB image (unmodified) from the MVP-8400 card to another MVP-8400 card (using instructions from prior posting), the copied card image worked fine.
- When I copied a 64MB image (unmodified) to the 512MB flash card, that card did NOT work fine. This was unexpected; normally software can't tell the difference if you copy a disk in this fashion.
This leads me to believe there is some sort of hardware or driver dependency with the SimpleTech CF cards that AMX is using (or perhaps, in the boot sequence, AMX just does some sanity checks on the CF card to eliminate the very thing I was trying to do). If the later, it's likely something in /dev/hde3 (the UNIX scripts and utilities and startup tools), although I can't rule out something in the boot loader or kernel (probably /dev/hde1 and /dev/hde2), and I didn't care enough to look that closely at /dev/hde3.I did briefly look at SimpleTech cards. I believe that AMX has either OEM'ed specific cards from them, or they're using some older SimpleTech model. The SimpleTech WWW site lists different model numbers from what I have, with a yellow label vs. a white label.
So, in short, I can't really continue without a larger SimpleTech card that AMX supports, and getting that elsewhere is likely non-trivial.
Anyone buy a larger MVP-8400 card, by chance? Is AMX still using SimpleTech, or someone else?
It really surprised me that the Sandisk 512MB card didn't work. Usually, CF cards provide an IDE interface for compatibility. The fact that both the Sandisk 512MB card and the SimpleTech 64MB card both used the IDE driver in Knoppix verified this. So, I'm surprised and a little perplexed by these results.
In summary:
If you want to recover a CF image due to corruption, this is wicked trivial (instructions previously posted).
If you want to extend the CF card yourself in an MVP panel, this looks more involved than just extending the partition, and I'm not sure why. If this is what you want, buy the card from AMX.
If someone else wants to continue where I left off, I'd be interested in hearing the results ...
Ryan
You can also do this with Cygwin or from within Linux running in VMWare on Windows.
Drives mounted in Cygwin are also available to the Windows file system.
To backup a CF card in Cygwin
Mount Raw Disk
Figure out which drive number the drive has (NT Disk Manager).
Let's presume it's 2:
$ mount -f -b //./physicaldrive2 /dev/xyz
Note that "xyz" is a placeholder. Name the drive as you want,
for example "/dev/hdb" or "/dev/amx"
Confirm your disk is mounted
$ mount
Copy disk image to file
$ dd if=/dev/xyz of=/path/to/image.img
or compress
$ dd if=/dev/xyz | gzip > /path/to/image.gz
While this backup process in going on you can open a Windows file explorer and monitor image size. It takes a while...
hmm. try burning as slow as possible (4-10x) not the very fast stuff like 48x...
i had a problem with the HP Notebook of my workmate. I had luck with the boot option "nodma" or maybe I typed "knoppix nodma".
If the disk only doesnt work on a specific PC, try google
Restore would look something like this:
dd if=/path/to/image/image.img of=/dev/sdb bs=1M
gzip -dc /path/to/image/image.gz | dd bs=1M of=/dev/xyz
Control Panel/Administrative Tools/Computer Management, select Disk Management
Scroll down to the CF card. Note the number.
Another method for backup in Cygwin:
run cat /proc/partitions
Note disk size, and determine which device is your CF drive.
(assuming /dev/sdc is your CF card) run dd if=/dev/sdc of=/path/to/image/image.img bs=1M
bs is optional, it just increases the speed of the backup/restore.
The dd parameters are identical on any Linux machine (that includes modern Macs).
I seem to have successfully made images of a few CF cards, but I cannot write them to a new card with Cygwin. I am getting an "access denied" message when I attempt it on the CF dev. What am I missing?
Be sure to use the device name from /proc/partition. The other method has been outdated.
Try to clear CF disk:
$ dd if=/dev/zero of=/dev/sda& pid=$!
(use your proper device name here. If you don't check it, you may very well clear your hard drive. That would be really bad)
then run
$ top
when it disappears from the top screen, do a Ctrl+C to kill top.
remove CF card, and re-insert. It should then complain card is not formated.
Without appending the & pid=$! the dd command would complain and not work for me. Not sure why. There are a number of complaints on the Internet about this.
http://cygwin.com/ml/cygwin/2005-05/msg00132.html
Note prior to issuing any dd command, always confirm the proper disk with cat /proc/partition, or you may end up with a bad day. The disk device may shift in the list... User the dd command very carefully
This is what I have done (Cygwin) :
$ mount -b -f //./f: /dev/cf1
Drive numbers did not work. Using f: results in CF access when attempting the dir command, etc. If I did not use the -f parameter, the mount failed with the message "/dev/cf1 does not exist." An empty mount command confirms it was mounted.
$ dd if=/dev/cf1 of=c:/Temp/test.image
This appears to work. The command completes, the card reader light flickers, a file appears in the folder named test.image that is 1008 KB in size (MVP8400 card).
Put a blank card in.
$ dd if=c:/Temp/test.image of=/dev/cf1 or $ dd if=c:/Temp/test.image of=/dev/cf1& pid=$!
Does not work - "dd: opening '/dev/cf1': Invalid argument"
Same error if attempting to dd /dev/zero to the flash drive.
So what am I missing? Some flags needed? Something about the way I mounted it? SOmething inherent in the card reader?