Upgrading a BCM HDD to SSD

It should work, however there is no BIT tool for the BCM50 or BCM450.

--DB

I tried this on a test BCM 50. I used a 64 GB Kingston SSD drive.

I used Acronis to make an image of the existing BCM drive. I couldn't get the BCM to boot with this drive at all. It would get so far and then fail the boot sequence.

I know the process I followed to image the drive was OK since I pushed the same image onto a Western Digital 120GB drive and that booted the BCM just fine.

I tried the BCm on Rls 3.0 and 5.0 with the same results.

Maybe a different drive to the Kingston SSD drive would work?

I can't really see why it shoudln't work as the host system doesn't really see that the drive is different. However maybe it objects to certain vendors

Good to know. The only thing I can think of is that the version of Linux that is used may not have the correct boot driver to support an SSD drive.

Have you attempted to load a basic Linux operating system, such as CentOS, on a regular PC to see if that works?

--DB

Remote Support Specialist

I haven't tried CentOS or simialr no - I will give that a go and see if I can get that to run.

I agree it would be good to have a BCM 50 running off an SSD drive.

Has anyone managed to get a solid state drive to work yet?

Haven't needed to use an SSD. It's much cheaper for us to use the SATA drive in the BCM50/BCM450.

--DB

I was install Intel 40 Gb SSD with any problem on BCM50 Rel6.0.
I used Acronis boot CD to make an image of the existing BCM drive.

What model Intel SSD did you use? I tried a Kingston one and it woudln't boot. I am keen to swap to an SSD if possible in a BCM running 6.0

Confirmed that INTEL X25-M drives work on BCM 50 Rls 3 & 6

Confirmed Corsair CSSD-F11 works

You can take a peek at this thread:

Intel 80GB 335 SSD works fine in BCM450 r6.

For the 2.5" to 3.5" adapter I use an ICY DOCK.

Model # on the SSD: SSDSC2CT080A4K5
Model # on the adapter: MB882SP

Procedure I uses was
1. shutdown the system,
2. pull the HD
3. Attach to PC with USB to SATA adapter
4. Backup entire disk to .TIB file in Acronis
5. Remote HD and attach SSD to PC
6. Restore .TIB file to new SSD
7. Install back in BCM

Boot up was much faster than usual. No problems so far and nothing in alarm report.

I guess I'll put my two cents in as well.

What I am about to tell you is not yet tested by me, so consider that in your decision.
I have spoken to several people on the topic, and the response I got on the topic is as follows:
Your flash media may need to be X133, not the newer, faster type.
This suggested to another respondent that the BCM50 drivers may not understand the newer UDMA used
in newer flash media. Sandisk Extreme CF cards (for example) claim to comply with not only UDMA5, but all UDMA as well,
So this could be a good choice. I was also advised that the software only takes up 10GB on the drive,
so a smaller SSD might save some money. I would not go quite as small as 10Gb however. Depending on the services
enabled via keycodes, you may need more space for messages and configuration data.

The real message here is that the drivers used to boot the BCM50 are rather particular about the hardware they recognize.

As this thread is probably still discovered on google, as I did, here's my three bits worth..

Beware, i'm going to delve into unix/linux technobabble!

Relating to the last post about the utilised space on the 80gig sata disk, your friend is
close, but because it's spread across multiple partitions, you'd need to back off each partition, re-size the heavily over-sized ones, re-build a test disk, then copy those back
on (and I am going to try it at some point), see if it still boots, and if so.. then, you
could use a myriad of tools (i use the unix dd util) to image this to a SSD.

In the below, "rootfs" is the third partition; /dev/sdb3 in linux-speak, mounted there at
boot time by a line in the system flash parameters:
hdboot=setenv bootargs root=/dev/sda3 rw;bootfat 0x600000;reset

On a UK Release 3 system, this is the filesystem layout in a normally running situation:

[pre]Filesystem Size Used Avail Use% Mounted on
rootfs 3.9G 1.8G 2.0G 47% /
/dev/sda5 251M 57M 180M 24% /nn/altroot
/dev/sda6 9.8G 1.4G 8.0G 15% /var
/dev/sda7 9.8G 491M 8.8G 6% /var/shadow
/dev/sda8 509M 17M 467M 4% /var/log
/dev/sda9 3.9G 33M 3.7G 1% /nn/patches
/dev/sda1 7.8M 956k 6.8M 12% /nn/images/kernels[/pre]

Some of those are heavily over-sized. /dev/sda7 - Hmnn.. there are 7853 call detail
records in there dating back to 2009... Truncate that by 8gb and the entire footprint
goes below 40 gigs.. to fit on an Intel 40g SSD for example.

/nn/patches? Being these are being phased out, I doubt a patch is going to be more than
about 500mb, so that could slim down too.

Looking at the partition tables on the actual machine, there are the other ones up
there, only mounted when you boot the "altroot", used to rebuild a messed-up system
in the case of a level 1/2 reset.. they are not mounted in a normally-running system.

Here's the partitions: And it's true, only up to 47gb are used. Rest isn't even used
by any partition. Talk about laziness and future. That could be used for messaging?
Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

[pre] Device Boot Start End Blocks Id System
/dev/sda1 1 1 8001 4 FAT16 <32M
/dev/sda2 2 2 8032+ 83 Linux
/dev/sda3 3 525 4200997+ 83 Linux
/dev/sda4 526 4701 33543720 f W95 Ext'd (LBA)
/dev/sda5 526 558 265041 83 Linux
/dev/sda6 559 1864 10490413+ 83 Linux
/dev/sda7 1865 3170 10490413+ 83 Linux
/dev/sda8 3171 3236 530113+ 83 Linux
/dev/sda9 3237 3759 4200966 83 Linux
/dev/sda10 3760 4282 4200966 83 Linux
/dev/sda11 4283 4291 72261 83 Linux
/dev/sda12 4292 4357 530113+ 83 Linux
[/pre]
/dev/sda4 is what you call the dos partition which wraps the following
partitions as 'extended' -in dos speak. Why use DOS? perhaps a hang-over from
the NT early systems? developed when linux wasn't fully adopted from filesystem
up? Who knows. Odd. (in my opinion)

Now, it would be kinda dumb to not copy over the rescue partitions, so mounting
them for a look at size, we see:
[pre]Filesystem Size Used Avail Use% Mounted on
/dev/sda10 3.9G 2.6G 1.1G 69% /10
/dev/sda11 68M 4.2M 60M 7% /11
/dev/sda12 509M 17M 467M 4% /12[/pre]

Partition 10 is the rescue stuff. Need that, and it *MUST* be partition 10, as
this is what a reset-button-boot mounts when rebuilding.

So... there's a fair bit of work in there to move things around before you could
obtain a hacked, rather, "intelligently updated" filesystem for simplifying and
copying to a new SSD. And I do think it's silly to throw a huge disk in there when
most of it isn't even seen by the system.

I have tried a SSD "OCZ Vertex Plus R2 MLC SATA II" 60gb disk which didn't boot
properly.. endless loop. Add that to the list of avoids, sadly.

Happy tinkering. Long live single-pair digital sets! who needs 3-PAIR IP sets?
how did that make it past the future-proofers? I wonder if the IP-telephony
lobby ever look into an RJ-45 and curse at that centre pair... grrr...

I suspect that SSD drives with SandForce controllers are not recognized. The OCZ drive you mentioned uses Indilinx - so it looks like that controller is not recognized either.

Thanks for mentioning that.. It indeed has a bright INDILINX INFUSED warning sticker on it.
I found an Intel 40gb X25-V Sata-II SSD on e-bay for £29, with 3.5" bracket. Going to give it a try.
SandForce. Wonder where the marketing folks come up with these names...

I can confirm that Intel X25-V works fine.

Intel 80 gig ssd sata 2 using clonezilla custom sector by sector clone worked great
samunsung sata 3 drives would not work

That's good to hear.

I have had a good experience with 64GB Crucial V4 drives. I installed them in several BCM50 systems - all of them are working without a glitch.

In the US, you can get them for example from Sunrise Nanotech for $50: