Running out of hard drive space :/

[Gerry Havinga]

Yes, the SSD pinout is completely standard.  It's basically a PC in there.  Even the motherboard is an off-the-shelf gaming/home theater component unit widely available.  Note the various unused serial ports as well as 1/8th inch audio I/o in orange and blue colors.

At the most fundamental level, the Prophet X is a PC-based sample playback computer with an SSD full of 8DIO samples, routed to a synthesis board designed by Dave Smith with analog filter architecture designed by Dave Rassum.  I would wager it's running a common Linux OS distribution and the SSD is partitioned allowing 150gb for 8DIO, 50gb user partition, and a 40gb OS area (or less) .  This is why it's critical to mirror the factory SSD to the new one. 

Don't ge the wrong.  This isn't SIMPLY a PC.  The genius is in that synthesis/filter board.  No shame in the off-the-shelf PC components being used for the basic tasks.  Acceptable in fact.  No need to re-invent the wheel. 

Here is what you will see if you crack your unit (courtesy of Monty):

OK very clear standard ASRock J3455-ITY board, probably a Celeron CPU as there is no fan. I don't see any other storage device, so the whole system boots from the SSD. That means the boot sector will also have to be copied of the Intel SSD (dd can do that of course).

I will order the parts for my new system later this week after I have asked my supplier to check my order.

Regarding the partitioning did you confirm this or is this conjecture? The 50 Gbyte limit might also be "hard-coded" into the firmware/bootstrap. In that case there isn't much point to this exercise of course  .

In the meantime I have loaded a great church organ sample, dual layered, at very high quality into my P X. This sample, across the keyboard is more than 500Mbytes. I want to load a few more church organ samples (using different stops and registers), so I will be filling up the 50Gbytes pretty darn quick. I need to experiment a bit more with these samples as there might not be any point in multi-layering it, saving disk space.

But it sounds so so great! And having that sample available to mangle and modify, wow.

[Lady Gaia]

Yes, the SSD pinout is completely standard.  It's basically a PC in there.

There is a pretty standard PC motherboard, but as you note it's just the starting point.  Note just the analog side of things, but also digital processing including the use of an FPGA makes this a pretty heavily customized design.  The SSD may be off-the-shelf but there's no guarantee that it uses a familiar partitioning scheme or filesystem format.  In fact, I can't really see a compelling reason for it to do so.

I would wager it's running a common Linux OS distribution and the SSD is partitioned allowing 150gb for 8DIO, 50gb user partition, and a 40gb OS area (or less) .  This is why it's critical to mirror the factory SSD to the new one.

The operating system is much smaller and is stored in Flash memory alongside user and factory presets, if I remember correctly from the experience of those who had to swap their SSD with a factory replacement.  You'd have to image a replacement, but I'd be willing to bet that in doing so you're also copying information on the drive about how much free space there is - and wouldn't gain anything.

Any extra space beyond the 150GB + 50GB on the factory drive is likely used to aid in wear leveling (you can only write to a given cell in Flash a certain number of times before it wears out, and with 150GB already reserved is helps to spread the remaining writes out across more physical space than the unit advertises.)

[Gerry Havinga]

Yes, the SSD pinout is completely standard.  It's basically a PC in there.

There is a pretty standard PC motherboard, but as you note it's just the starting point.  Note just the analog side of things, but also digital processing including the use of an FPGA makes this a pretty heavily customized design.  The SSD may be off-the-shelf but there's no guarantee that it uses a familiar partitioning scheme or filesystem format.  In fact, I can't really see a compelling reason for it to do so.

I would wager it's running a common Linux OS distribution and the SSD is partitioned allowing 150gb for 8DIO, 50gb user partition, and a 40gb OS area (or less) .  This is why it's critical to mirror the factory SSD to the new one.

The operating system is much smaller and is stored in Flash memory alongside user and factory presets, if I remember correctly from the experience of those who had to swap their SSD with a factory replacement.  You'd have to image a replacement, but I'd be willing to bet that in doing so you're also copying information on the drive about how much free space there is - and wouldn't gain anything.

Any extra space beyond the 150GB + 50GB on the factory drive is likely used to aid in wear leveling (you can only write to a given cell in Flash a certain number of times before it wears out, and with 150GB already reserved is helps to spread the remaining writes out across more physical space than the unit advertises.)

The motherboard is standard, using X86 architecture. Therefore it must use a bootstrap process that is compatible with this architecture. A legace MBR (Master Boot Record) or more modern UEFI boot environment which then bootstraps the rest of the system. Given the P X startup time my guess is a small Linux kernel that initializes a simple real-time environment to interface between the FGPAs, the rest of the system and storage. Perhaps some processing is also done by the X86 board.

How it interfaces with the rest of the system (FPGAs) is a different matter of course.

[Lady Gaia]

The motherboard is standard, using X86 architecture. Therefore it must use a bootstrap process that is compatible with this architecture. A legace MBR (Master Boot Record) or more modern UEFI boot environment which then bootstraps the rest of the system.

Sure, but there's nothing demanding that the SSD be the system disk, and as noted above I believe that it is not.  My FreeNAS uses a similar configuration (and indeed I believe the same motherboard supplier), and it boots the OS from Flash just like I suspect the Prophet X does.  That would mean the SSD can be exposed as a raw device to be formatted in any manner of Sequential's choosing.  They might have chosen to use a familiar filesystem for ease of implementation, or they might have rolled their own to optimize for their specific usage patterns.  There's not much evidence one way or another.

[station2station]

The motherboard is standard, using X86 architecture. Therefore it must use a bootstrap process that is compatible with this architecture. A legace MBR (Master Boot Record) or more modern UEFI boot environment which then bootstraps the rest of the system.

Sure, but there's nothing demanding that the SSD be the system disk, and as noted above I believe that it is not.  My FreeNAS uses a similar configuration (and indeed I believe the same motherboard supplier), and it boots the OS from Flash just like I suspect the Prophet X does.  That would mean the SSD can be exposed as a raw device to be formatted in any manner of Sequential's choosing.  They might have chosen to use a familiar filesystem for ease of implementation, or they might have rolled their own to optimize for their specific usage patterns.  There's not much evidence one way or another.

I agree with everything we are tossing around.  All the aforementioned potentials are in play...

Except I guarantee they are using standard disk formatting..  I don't see a reason Sequential would decide to roll their own disk formatting structure.  That would be akin to deciding to use a different voltage.  This would be such an unnecessary battle  - heck if they're using a common system board and likely a Linux distro, they are just using a ext4 or ext3.

Anyway, you guys are bird dogging this one well.  I'll keep an eye one it.  Looks like Gerry might be close to pulling his disk and running fdisk against it. (or some disk utility.  THAT will be enlightening.)

[composerjk]

The operating system on the Prophet X/XL is QNX. I believe the filesystem is the QNX Power-Safe filesystem. fyi.

[Gerry Havinga]

The operating system on the Prophet X/XL is QNX. I believe the filesystem is the QNX Power-Safe filesystem. fyi.

OK that makes a lot of sense, COW file system of choice ;-)

I'll check how easy it is to adjust this file system. I see if I can get some help from some old colleagues working in the "ultimate embedded" systems company here in the Netherlands.

[Lady Gaia]

OK that makes a lot of sense, COW file system of choice ;-)

Pfft.  Give me ZFS any day.

For an embedded system, a QNX foundation makes a lot of sense and knowing that it’s a documented format makes this endeavor a little more practical sounding.  I’ll sit on the sidelines for a change of pace while others do some digging, but I’ll be curious to hear whether there’s a promising path for expanding the storage available.

[station2station]

OK that makes a lot of sense, COW file system of choice ;-)

Pfft.  Give me ZFS any day.

For an embedded system, a QNX foundation makes a lot of sense and knowing that it’s a documented format makes this endeavor a little more practical sounding.  I’ll sit on the sidelines for a change of pace while others do some digging, but I’ll be curious to hear whether there’s a promising path for expanding the storage available.

I'll sit with you...

[Shaw]

Interestingly enough, most of us "hard drive curious" folks are likely out of the warranty period on our Prophet X's... not that that means anyone wants to brick their synth, but at least we don't void a warranty by opening her up and having a nosey around a bit.

[composerjk]

Interestingly enough, most of us "hard drive curious" folks are likely out of the warranty period on our Prophet X's... not that that means anyone wants to brick their synth, but at least we don't void a warranty by opening her up and having a nosey around a bit.

Opening up the Prophet XL was one of the things I did early on after obtaining it, earlier this year, partially to make sure I had a backup.

[Gerry Havinga]

Interestingly enough, most of us "hard drive curious" folks are likely out of the warranty period on our Prophet X's... not that that means anyone wants to brick their synth, but at least we don't void a warranty by opening her up and having a nosey around a bit.

Opening up the Prophet XL was one of the things I did early on after obtaining it, earlier this year, partially to make sure I had a backup.

How did you go about making a backup?

[composerjk]

Interestingly enough, most of us "hard drive curious" folks are likely out of the warranty period on our Prophet X's... not that that means anyone wants to brick their synth, but at least we don't void a warranty by opening her up and having a nosey around a bit.

Opening up the Prophet XL was one of the things I did early on after obtaining it, earlier this year, partially to make sure I had a backup.

How did you go about making a backup?

First time was using the old Unix dd(1) command to copy the raw disk to another disk. More recently, I used an external disk duplicator. Some of the boxes intended for temporarily connecting an internal drive via USB have multiple slots and can attempt duplication to a disk that's at least the same size plugged into it without being connected to a computer. In both cases, it requires physically removing the drive, of course. And, if you do this, make sure to be careful when specifying the source and destination drives so as not to accidentally overwrite your original drive.

Hopefully, someday, there'll be an option to backup the drive to a USB connected drive from the keyboard, itself. That would be useful.

[Gerry Havinga]

Quick update on progress. I have assembled the new AMD based server. CentOS 8 installed flawlessly from USB stick and the extra 1Tbyte SATA SSD has arrived.

Unfortunately I have ran out of time, work is taking op all my time including weekends. The next two weeks I will be occupied with work and will be traveling. I will report back in a few weeks.

[Gerry Havinga]

Interestingly enough, most of us "hard drive curious" folks are likely out of the warranty period on our Prophet X's... not that that means anyone wants to brick their synth, but at least we don't void a warranty by opening her up and having a nosey around a bit.

Opening up the Prophet XL was one of the things I did early on after obtaining it, earlier this year, partially to make sure I had a backup.

How did you go about making a backup?

First time was using the old Unix dd(1) command to copy the raw disk to another disk. More recently, I used an external disk duplicator. Some of the boxes intended for temporarily connecting an internal drive via USB have multiple slots and can attempt duplication to a disk that's at least the same size plugged into it without being connected to a computer. In both cases, it requires physically removing the drive, of course. And, if you do this, make sure to be careful when specifying the source and destination drives so as not to accidentally overwrite your original drive.

Hopefully, someday, there'll be an option to backup the drive to a USB connected drive from the keyboard, itself. That would be useful.

Yep using the dd command routinely almost, no confusing the ins and the outs ;-)

[Gerry Havinga]

Latest update: successfully made backup copies of Prophet X 250 (224) GByte Intel SSD to local disk image and to a fresh 1Tbyte SSD. There are two partitions installed IDs b1 and b3; 245 Mbytes and 223.3 Gbytes respectively.

I put my Prophet X back together with the original SSD for the time being so I can make some music with it ;-). The guts of the P X are very well designed and fit nicely together, impressive and very easy to get to and to repair if needed.

I am trying to work out access to the QNX file system so I can extend it. Currently my strategy is to run an old QNX version (it was open sourced once a long time ago) under CentOS 8 KVM and try to give it access to the Prophet X image and/or 1 TByte SSD.

Now I have ran out of time, but I will keep trying later this week. The QNX 6.3.0 ISO image won't boot beyond the "Hit Esc for .altboot.............." message. I am running Qemu/KVM in 486 mode, also tried kvm32 but no luck yet.

When I have time again I will investigate deeper.

[Shaw]

Latest update: successfully made backup copies of Prophet X 250 (224) GByte Intel SSD to local disk image and to a fresh 1Tbyte SSD. There are two partitions installed IDs b1 and b3; 245 Mbytes and 223.3 Gbytes respectively.

I put my Prophet X back together with the original SSD for the time being so I can make some music with it ;-). The guts of the P X are very well designed and fit nicely together, impressive and very easy to get to and to repair if needed.

I am trying to work out access to the QNX file system so I can extend it. Currently my strategy is to run an old QNX version (it was open sourced once a long time ago) under CentOS 8 KVM and try to give it access to the Prophet X image and/or 1 TByte SSD.

Now I have ran out of time, but I will keep trying later this week. The QNX 6.3.0 ISO image won't boot beyond the "Hit Esc for .altboot.............." message. I am running Qemu/KVM in 486 mode, also tried kvm32 but no luck yet.

When I have time again I will investigate deeper.

Sounds like progress... please keep us posted.

[Antti]

Note just the analog side of things, but also digital processing including the use of an FPGA makes this a pretty heavily customized design.

FWIW, the FPGA almost certainly acts only as an interface between the quad core 1.5 GHz x86 cpu and the analog parts (basically a 16 channel audio interface + control of the various CVs). When you have that kind of processing power in the cpu itself, there is no point in trying to do too much on the FPGA (huge development effort for little gain).

[Gerry Havinga]

Update for last week/weekend:

I decided to see if I could boot a 64bit VM directly from the disk image of the Prophet X SSD. I made several backup copies: sda1 and sda2 separately and a copy of sda (the whole disk from beginning to end). Of course I also copied the MBR (Master Boot Record) separately just in case.

1. Booting from the sda image and giving sda2 to the VM is possible but the system doesn't get past the message that it cannot detect block devices.
2. Booting from the sda image is possible but same error, block device cannot be detected
3. I copied (dd) the sda image directly to an attached 1 TByte SSD and attached the SSD to the virtual machine to boot from the drive. Same result, boot process starts till it fails to detect block devices.

There is progress but it goes slow. I have many more options to explore. I want to figure out exactly the SATA controller type on the Prophet X PC board. It is clear that QNX has difficulty detecting the correct controller / disk combination.

I will keep you all posted.

[Gerry Havinga]

Update for last week/weekend: unfortunately I did not manage to put any time aside for either music creation/recording as working on the QNX image. I am counting on life to slow down a bit in the next few weeks.