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.

I resized hda1 (drive0), resized hda2 (extended partition), moved hda5 (root) into the <128G section. I was unable to move hda6 (rio partition) because parted couldn't recognize the partition type.

I'm going to fire up the central and see if anything changed.

You are right about the partition mounting though. I checked fstab, and it's empty.

It's booting!!! After boot, the system recognizes the entire disk. Mounting swap succeeds and it's in the last space on the drive.

Ok, from this, I can draw the following conclusions:
1. The kernel in flash doesn't support >128G drives.
2. The stock kernel on the HDD does.

Is there a way to move the rio partition, or create it earlier on the drive? If I can move it, I can add the largest partition on the end of the disk without changing the partition numbers of the existing partiitions.

With that bit of information, I'm pretty sure I can get this 100% working, one way or another. I attached my boot log for those interested.

I may be able to create the new partition and then use "dd" to do a raw copy...

http://www.sysdesign.ca/guides/partitions.html

Could anyone let me what's failing on line 433 of player.cpp? Maybe someone in Cambridge?

I'm also looking into the drive errors. Apparently, I may have to compile a kernel yet.

--------------------------------
Permanent section: 0x0x22d6248..0x0x22d7324 (mlocking 8K)
jupiter 1.10-rc1 (build 23) 2002/11/19.
hda: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hda: drive_cmd: error=0x04 { DriveStatusError }
E !! player.cpp 433: MainThread::Init failed!

I'm compling try #2 of the kernel now. Apparently, what I thought would be loaded was pretty far off from what is actually loaded in the stock kernel. I also found what seems to be a fix for that specific HDD error. Interestingly, this may also allow for hooking up external USB drives, because that was the error encountered when trying to do so in the past.

More to come...

Kernel #4 is looking better. The partition table is now recognized, there's no more HDD errors, and I'm getting root to mount, and I think I have nearly all the same drivers loading (in addition to others). /dev/hda1, the reiserfs partition is failing to mount, I'll have to take a look at that tomorrow.

I have to say, doing this without the benefit of LILO or grub is a serious pain.

Also, if anyone tries to compile a kernel, use the source on the 1.10 cdrom image. I couldn't get earlier kernels to compile at all...

Thanks for the effort you are putting into this. I don`t have the time to do this kind of research on my Central.

Heh, I'm not sure I do either.

Well, here's my lastest attempt. I'm going to attach my kernel log, if anyone has comments, I'd be glad to hear them.

Ok, here's my problem... The SCSI generic driver is attaching to the HDD. I can mount the reiserfs disk using the SCSI emulated name but not as /dev/hda1. I have used SCSI generic support extensively in the past and never had this problem. Does anyone have any insight into this issue? SCSI generic is required to support cd burning under Linux.

hda: ST3300631A, ATA DISK drive
hdb: CD-W58E, ATAPI CD/DVD-ROM drive
ide0 at 0xf7000000-0xf7000007,0xf7000038 on irq 6
hda: 586072368 sectors (300069 MB) w/16384KiB Cache, CHS=581421/255/63
Partition check:
/dev/ide/host0/bus0/target0/lun0: p1 p2 < p5 p6 p7 p8 >
...
SCSI subsystem driver Revision: 1.00
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
Vendor: TEAC Model: CD-W58E Rev: 1.0A
Type: CD-ROM ANSI SCSI revision: 02
Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
sr0: scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 cdda tray
cdrom: entering register_cdrom
Uniform CD-ROM driver Revision: 3.12
cdrom_init finishes
cdrom: drive "/dev/sr0" registered
...
Tried to mount /dev/hda1 as reiserfs but got error 2
No primary hard disk

----------------------------------------------------------------
Edit: Apparently, the problem was caused by devfs being compiled into the kernel. The /dev files should be copied from the original directory by using "cp -dpR /dev/* /destination".

Ok, my 120G HDD is most certainly failing. It's time for a new HDD for the central. I may pick up this line of research again when I get the new HDD. Does anyone have a suggestion for how to get this done, or is everyone rocking out with their iPods? Thanks!

I have some RAM chips that I suspect are compatible with the central. The chips are marked with:

IC42S16400-6T
PB2645111 0307

I also have the datasheets for both the stock chip (listed above in this thread) and the suspected compatible chip. Could one of you hardware gurus take a peek and let me know if you think the chips are compatible?

Edit: I checked the form factor and the pin out, and they seem to be the same.

Stock chip datasheet.

Hyndai Korea
HY57V651620B
0028B P TC-7

Edit: added markings from stock RAM chip

I forgot to add... These IC RAM chips are from a Linksys WRT56G router, among others. Thus, they are generally available, and in most cases, for the cost of shipping a bricked router.

Ok, I have two RAM chips that I desoldered from the router. I have 2 questions.

1. If the chips are compatible and soldered on the board, will the machine be able to boot normally with no code changes? Obviously I wouldn't expect the additional RAM to be recognized.
2. Do you think the RAM will work?

If the Central is anything like the Empeg, then changes to the Kernel would be needed to recognize the extra RAM exists, and changes to the player code would be needed in order to do something useful with that RAM, such as cache and database space.

I soldered a surface mount amd486-133 onto a board that had a amd486-66 chip to attempt to gain some facility with a soldering iron. I'm going to test it tomorrow and if it works, I'll solder the RAM chips on the central. If it doesn't work, I think I need more practice with the soldering iron.