Since there is so much confident misinformation about on this about on the net, I'm stooping to the depravations of SEO and have put my main point into the headline: If you have a Garmin GPSmap device from the later 60 series and worry whether you'll still get SD cards that will work with it, relax: I just bought a 64 GB SDXC card and made it work inside a 60csx that will replace the 64s I had since 2017 (which hopefully has found a new home in Paris. Ahem).
While it is by no means certain that a vintage 2006 machine can deal with SDHC (since that was only specified in January 2006), and machines that only support SD 1.0 usually get confused with higher-capacity cards, Garmin got it right for these devices. You may be out of luck for the vintage 2003 60C and 60CS, though, but I have no means of ascertaining that.
In case you're wondering why anyone bothers with hardware that's coming of age these days: I was surprised myself that the things still go for about 100 Euro on ebay, but they are well-made, and very frankly: except for the support for multiple gmapsupp.imgs, I see the GPSmap 64s as a step back over my original 60Cx, in particular when finding features. The GPSmaps are also sturdy devices surviving 20 years of (ab)use, and they're running on standard NiMH cells. What's not to like?
But, sure enough, when you insert a card you get at your local chemist's today (which will be SDXC) into the 60CSx, it will not (immediately) be recognised. That is because while the machine can deal with SDHC (and thus SDXC) Card-Specific Data and thus the hardware is fine, it cannot deal with exFAT file systems (and preformatted exFAT, really, is the difference between SDXC and SDHC). To my surprise, it could deal with a FAT32 file system, so running, on a linux host with a card reader, sudo mkfs.fat /dev/mmcblk0p1 was all I needed to do to make the device see the file system.
For reference: the way to figure this out is to create a Garmin subdirectory on the card, and put some (sufficiently small; there's still the 4GB limit on file sizes with FAT32) gmapsupp.img file in there. If you don't have one, my favourite sources at this point are Computerteddy's classics or frikart's renderings.
You should now see the map data on the device.
In case reformatting as FAT32 does not do the trick for you: I seem to remember my old 60CS insisted on FAT16, which would explain the talk about a 4 GB limit for the card that's reported in multiple places. If this is true for your 60CS, fetch gparted from your distribution's repository, run it on your SD card, resize the existing partition to 4096 MB, tell gparted to put a FAT16 file system on it, and then try again.
There is another snag when you run GPSmap devices on suitably configured Linux systems and want to use the pleasantly unconventional gpsman to manage tracks and waypoints: power management.
The way gpsman interacts with the USB port makes Linux suspect it doesn't use it at all and then suspend the device if you have enabled USB autosuspend; in consequence, you cannot talk to the device any more, and gpsman's “check device” will fail. And you probably have enabled USB autosuspend if you are on a mobile platform and use software like tlp.
To still make gpsman work, turn off USB autosuspend at least for the GPSmap. In the tlp case, the way to do that is to figure out the USB id for the GPSmap (use lsusb), which turns up 091e:0003 for the 60CSx. Then tell tlp to leave such devices alone by adding that id to tlp's USB_DENYLIST variable. Don't edit /etc/tlp.conf directly, though, because that will make your dist-upgrades more painful. Rather, create a file /etc/tlp.d/10-stop-autosuspend and put something like:
|||Resize instead of drop and recreate because the card vendors seem to be doing some voodoo when aligning their pre-created partitions, supposedly to improve speed (or perhaps even to reduce wear, which probably isn't an issue on the Garmin devices which essentially never write). By resizing, you don't disturb the voodoo. Because, you know, it may work even if you don't believe in it.|