The empeg boots very fast. Too fast, in fact, it even has to wait a bit for the drives to spin up before it can recognize them. On a dual-drive unit, the second drive may take a bit longer to spin up than the first, so the empeg tries for another second and bit before giving up on it and proceeding with only the first drive. The problem with that is that a single-drive unit takes a second and a bit longer to boot than it would if it didn't look for a second drive.

Well, it's quite unlikely that a second drive would appear in my unit while I'm looking the other way, so I might as well enjoy my music for that entire second and a bit rather than just stare at the empeg logo.

Here are the goodies:

zipped mk2 kernel image
zipped mk1 kernel image
kernel patch

Please note:

• USE ONLY ON SINGLE-DRIVE UNITS!
  
• The mk1 image is very thoroughly untested

These images include Frank's irhack for displayserver. If you want any other patches bundled in, just ask.

Happy fast booting,
Borislav

Neat, do they include your persistant display stuff too? -Mike

Neat, do they include your persistant display stuff too?

No, but here are ones that do:

zipped mk2 kernel image
zipped mk1 kernel image

Borislav

Hehehe, cool. Half the booring time!!!!

Thanks man..

TommyE

OK, it is becoming increasingly obvious that I need to setup my own cross-compile system, but in the meantime how about the above + rijovs volume adjusting stuff? -Mike

OK, it is becoming increasingly obvious that I need to setup my own cross-compile system, but in the meantime how about the above + rijovs volume adjusting stuff?

It's becoming increasingly obvious that I need to setup some sort of automatic kernel compilation facility for a chosen set of patches, or I'll go crazy once I flush my pipeline.

There we go, 1disk + settings + irhack + voladj:

zipped mk2 kernel image
zipped mk1 kernel image

Wishes,
Borislav

Blimey, talk about knowing how to make a girl feel guilty! It was me who caused Mike to insert a slightly longer timeout into the boot for the second disk.

I can't fathom (but then I haven't looked) why the device driver for the AT disks in the unit is unable to determine the presence of a disk drive and then respond to the kernel so that it can take appropriate action. This would be the case under Slowaris and FreeBSD; how come not with Linux? Or is this just too obvious?

One of the few remaining Mk1 owners... #00015

Blimey, talk about knowing how to make a girl feel guilty! It was me who caused Mike to insert a slightly longer timeout into the boot for the second disk.

No problem, the fast boots are only a patch away. I can well see why that delay is necessary, if you have two different disks, or something.

I can't fathom (but then I haven't looked) why the device driver for the AT disks in the unit is unable to determine the presence of a disk drive and then respond to the kernel so that it can take appropriate action. This would be the case under Slowaris and FreeBSD; how come not with Linux? Or is this just too obvious?

Sounds like the disks need to spin up before the controller would recognize them. On a desktop system you load the kernel image from disk, so you are guaranteed that the disks are spinning before the kernel tried to detect them. Not so on the empeg, the kernel there is in flash. That's my understanding of it, anyway.

Borislav

Yes, you're right - well thunked. Chilean wine is good for reducing brain function, obviously.

As for the controller - not convinced; the AT command set for the on-disk controller should respond to commands to indicate the controller is present, and the state of attached disks (stopped, spinning up, at speed, deccellerating) can be reported seperately. The idea of "UNIX" is multi-processing, so if you have a kernel image already in the air, it doesn't have to wait for a disk to come up to speed before proceeding. I suppose what we're talking about here is the player application's startup time being dependent on the speed at which the disks become available (since its resources - MP3s - are on disk).

It still implies the designers of the kernel have not considered the kernel being loaded from a different media other than the root disk of the system. Yuck, chicken-and-egg. When will empeg-sorry-SonicBlue(Cambridge) take the HURD on board???

One of the few remaining Mk1 owners... #00015

Thanks, so who will be the first to setup a webpage where you can go, select the patches you want added into the basic empeg kernel and have it automagically compiled and emailed to you :-)

-Mike

Tempting, but definitly not on my system here. I suppose a system could be set to ensure the kernel selected hasn't already been compiled before to help save CPU time.

Too bad the 8 processor system sitting at work as a lab machine can't be accessed from the internet.

Hmm, it's only been a few mins and already I have the PHP code running through my head for this custom kernel building web site. If I do the code, someone willing to host it?

If I do the code, someone willing to host it?If it can be done reasonably on Solaris/Intel with a Linux/ARM cross-compiler, I'd be willing; I have such a machine (hosting , among other things) which is already running Apache/PHP4.

-----
Daniel M. Zimmerman, Caltech Computer Science
Mk.2 #060000058, 36GB
Mk.1 #00101, 10GB

...this is what the (not-yet-implemented) drives count seen in the /proc/empeg_id bit is for. On AC it will always wait for both drives & save the result - then on DC it will only wait for one drive if required.

Not got round to fixing it yet though.

Hugo

...this is what the (not-yet-implemented) drives count seen in the /proc/empeg_id bit is for. On AC it will always wait for both drives & save the result - then on DC it will only wait for one drive if required.

Cunning, wish I'd thought of doing that. I'll give it a shot when I get a spare minute again. Do you have a location in flash set aside for storing this?

Borislav