OK, I've heard a lot of speculation of the maximum Hard Drive size in one of these animals; what is it?

Is it currently 128GB (that was mentioned earlier I think) or is that a limitation that could be overcome eventually by someone hacking the Kernel or an update from Sonicblue?

Thanks!

Jerz

I would think that the only limit would be the linux kernel limit. If the kernel limit were in effect, it would be something close to 127gb, yes.

Not sure if the Rio Central runs the kernel version that contains the limit, I think it runs a later kernel than the car player (which has the limit)... Dunno...

Is it currently 128GB (that was mentioned earlier I think) or is that a limitation that could be overcome eventually by someone hacking the Kernel or an update from Sonicblue?

The current 128G limit is because of the kernel, yes. With a newer zImage, bigger drives could be used. (Because the root filesystem is at the start of the disc, you probably won't need to reflash the flash kernel, just rewrite the disc kernel.) I think Mark Lord has a patch floating around for the kernel version used in Jupiter; otherwise it shouldn't be a big problem to upgrade the kernel, or perhaps just the IDE drivers, to 2.4.19 which has big-drive ("LBA48") support built-in. The next major drive size flag day isn't until 2TB, which is the point when sector offsets exceed the reach of 32-bit integers. At current rates of progress, that won't be until about 2005.

Peter

The Rio Central source code from the vendor shows LBA48 support already in the kernel, configured and all. Is the actual loaded kernel not the one that source was provided for?

Cheers

Mmm, should be, as the release scripts that build the CD image package up the kernel source that was used to build the kernel image.

However, there may be an older image in the flash; the kernel in flash boots a new kernel off disk. If the flash kernel doesn't do LBA48 I guess it won't recognise the disk at all?

It is possible to update the flash kernel, but if the process goes wrong you'll need a serial debug lead to attach to J2 inside the central, which you can operate the bootloader from - the reflashers for the empeg-car will work with it.

Basically, it's just waiting for someone to do a new disk-loadable kernel with reflash support in it, plus a tested LBA48 kernel (you could try, say, a 160GB disk as a secondary to see if it really did work with the disk-loaded kernel). This could all be neatly packaged as a bootable ISO.

Really, though, with such big disks you'd be starting to want another 16MB of SDRAM, which there are pads for on the board. This isn't enabled in the SDRAM controller though, so you'd need to do that somewhere "safe" (like in the E000 boot section which runs direct from flash and is in a writable flash area).

Hugo

In reply to:

---

It is possible to update the flash kernel, but if the process goes wrong you'll need a serial debug lead to attach to J2 inside the central

---

And before anyone actually tries messing with this, I wanted to say that the "serial debug lead" that Hugo talks about is not just a couple of pins that connect to a serial plug. It's actually a little custom-made device with electronics on it. So it's not a good idea to try messing with the pins unless you've got one of these special devices.

Nice! Has anyone actually upgraded the RAM on their central? And would it be possible to upgrade it by more than another 16M? It seems that if you are going to go through the trouble to up the RAM, you might as well bump it up to 32+16 or 64+16 (128+16? Dare I dream?)

You should be able to add another two 4Mx16 SDRAM chips and caps to get a total of 32MB. However, you'll also need to write some code to (a) turn the bank on and initialise it correctly, which has to run from flash (eg, on the 0xe000 boot section) and (b) tell linux about the extra memory.

Unfortunately, I didn't have time to make it autodetect memory and autoconfigure it. That and I don't think (at the time) we had any spare chips to test such a patch

Hugo

Ok, 200G HDD just hit 60$ at the local computer store. I'm starting to think about what it will take to go larger than 120G. I have some questions and thoughts.

Here are my assumptions and questions so far:

1. Partitions located entirely in the <128G drive space will be recognized by the flash kernel. Given a kernel with >128G support on the root partition, the whole drive should be recognized.

2. Why would more RAM be required? Is that just to handle the larger number of songs that could be placed on >128G disks?

3. It seems that a whole new install CD would need to be created because the RIO cds would only recognize the first 128G of the disk (would it even do that?). Would it be easier to A) create a whole new install CD and copy the software over, or should the process be to B) run the RIO install, and then have another install CD which resizes the disks? Will RIO come after me if I use the method "A" (it involves putting their software on a new ISO image)?

4. Is there something built for the empeg-car that might be usable in this endeavor?

I've experimented with this a bit and I can't get a drive larger than 120 GB to work correctly. I've tried a blank 160 GB drive and tried to run the original CD to prep the drive. The process seems to work but then upon rebooting it goes back to the CD and gets stuck in a sort of endless loop...

I've also tried copying the contents of my 120GB Rio Central drive to a 160 GB blank drive on my hard drive copy system. This creates a 160 GB drive that has the 120GB Rio data copied to it with the same size partition, etc. as the 120. This drive won't boot at all....

So unless someone wants to do some software hacking, etc. to get the Central to recognize a larger drive, I haven't had any luck trying various combinations of new drives, larger copies, etc and just using the standard Central software...

Randy

Did you hook the drive up to a linux box and see what was on the 160G disk after you ran the RIO install? It would be quite interesting to see the partition sizes, etc.

Just browsing the forum and noticed the question above for me... Better late than never, I guess...

No, I never hooked up my failed 160GB install disk to a Linux box to check it out...That would have been interesting...

However, I now have a new strategy for Central diskspace...

Because I've hooked up removable hard drive canisters on my Centrals, I have built up a "fleet" of 120 GB drives. I currently have 4 sets of 2 disks (each Central disk has a backup copy sitting on my shelf that I refresh periodically).

Each of these 4 Central disks has different music on it (one is even dedicated to Christmas music!!)...

While it would be nice to have all of my music collection on one Central hard drive, I've come to the conclusion that the performance would suffer too much for that to be a good solution...

My Central disk #1 has about 100 GB of music on a 120GB drive, and while it works, it is sluggish and prone to jEmplode instability.

However, I just built Central disk #4 and it currently has about 20GB of music on it. It runs much much faster in general and shows none of the stability or sluggishness issues when accessing the database with jEmplode, etc.

So I think I'll just keep doing it this way. If I want to play music that's on another Central Hard drive, it's just a swap away....

I think it would take a lot of work on the large hard drive side and software hacks/changes to get the kind of performance that we're used to with the smaller disks, etc.

Any thoughts?

Thanks, Randy

Ok, I just scored a 300G drive. I hope to get it working over the next few days. Stay posted.

Ok, so far, the install seems to stall halfway through the "initializing music storage" part. Next is to hook it up to a Knoppix cd via a USB enclosure. I hope my USB enclosure supports 300G drives.

I did get the markings off the RAM chips though.

Hyndai Korea
HY57V651620B
0028B P TC-7

Ok, here's what I see on the HDD... looks like the music partition is installed as hda1, with an extended partition (hda2) next that contains root (hda5), the rio mystery partition (hda6) and finally swap (hda7).

The full space (300G) is used by the partitions.

Ok, been doing some thinking. There's some conflicting items.

1. The CD install actually recognizes the full size of the disk. (!)
2. The boot partition is in the >128G section of the HDD.
3. The installed HDD won't boot.

Is it possible that the kernel on the install cds (I tried 1.02 and 1.10) is newer than the one on the MB in RAM? Does the install CD even boot a kernel as part of the install process?

I could try and take the <128G drive, and manually create the partitions and copy everything on the larger drive.

What do you guys think?

Would having the a line level converter on the debug port do me any good here?

Ok, I ordered a line lever converter. <echo>

Tap, tap. Is this thing on?

I'm here and reading with great interest, thinking about getting a central so you could be about to k=make my day.

I have a bid on a Central

Ok, I have the line level converter. I'm going to get the cables and hook it up tomorrow.

Ok, I have a console to the rio now. It worked the first time using a converter off ebay. One item I noticed is that HyperTerminal doesn't work particularly well for communicating with the Central. I installed cygwin and minicom, and that works great. I attached a boot log of the central operating normally.

Ok, here's what happens when I boot the 300G disk after it fails halfway thorough 1.10 installation.

The superblock of the boot partition is "unable to be read". It could be because of a corrupted partition, corrupted partition table, or the partition being out of the readable range. From my last tests, I think the partition table and partitions are ok, but I'm going to double check.

BTW, what does "hit control-a to enter pump" mean?

Full log attached for those interested.

-------------------
NetWinder Floating Point Emulator V0.95 (c) 1998-1999 Rebel.com
VFS: Mounted root (ext2 filesystem).
empeg-pump v0.04 (20001108)
Press Ctrl-A to enter pump...EXT2-fs: unable to read superblock
upgrade triggered
VFS: Disk change detected on device sr(11,0)
Mounting CD: No medium foVFS: Disk change detected on device sr(11,0)
und
VFS: Disk change detected on device sr(11,0)
ejecting cd

It looks like a flash kernel upgrade is possible via the same mechanism as the empeg. I'm unwilling to try this without a copy of the original flash kernel though. Does anyone at cambridge have access to the original flash kernel for the central? Or is there a way to download the kernel from flash?

Thanks!

-------------------
//from Mark Lord's download.c
static char magic[]="peace...";
...
printf("Turn on empeg unit now\n");
magicpos=0;
while(1) {
/* Look for magic string */
d=readbyte(1);
if (d<0) magicpos=0;
else {
if (d==magic[magicpos]) {
magicpos++;
if (magic[magicpos]==0) break;
}
else magicpos=(d==magic[0])?1:0;
}
}

You can copy it from the flash if you've got command line access. There should be a device in /dev which maps to the flash. At least there is on my empeg but that might be an addition by Mark.

Thanks! I copied the flash off. The device was /dev/flash.

Is the flash loading feature part of the kernel? Aka, if I install a bad kernel, can I reinstall the original one?

I'm compiling a fresh kernel now.

The loader is in flash but it is in the protected bootloader part which you can't erase or overwrite without hardware modification.

The file you got out of /dev/flash is probably the contents of the entire flash tho so you'll have to work out what chunk is the kernel.

You are correct. I see the messages about loading the new flash in the file I downloaded, so the /dev/flash does give you everything in the flash.

Is there a utility to extract the kernel from the flash file for the empeg? Is this a job for a hex editor? Are there instructions anywhere on how to do this?

Also, does anyone know the available space in the flash? The used space seems to be right at 1M.

In case anyone is interested, I have a copy of the flash out at:
flash

Also, what is the first kernel responsible for? It seems to load more than I would expect. As I'm configuring the kernel to replace the one in flash, all I'm really thinking it would need is compatibility with the processor, the "newkernel" feature to allow a second kernel, the right kernel flags set and ability to read >128G hdd...

Is there a reason there are as many drivers in the flash kernel as there are?

You gave me an idea... Maybe I can shrink hda1 to a very small size, and relocate the data file partition to a new, partition (hda8?). Then, I change the mount table to mount the new partition as /drive0.

Maybe that's what you said.

Anyway, I'll fire up "parted" soon, and see what I can do.