Okay, I just put out v25 of my "hijack" patch (VolAdj, BreakOut, ScreenBlanker, Vitals, MaxTempWarning, RotaryKnob fixes, etc..).

This is the first version to also include the long-awaited ioctl()'s for interfacing with userland applications. So.. if you own/support an Empeg application that currently requires the menuhack patches or whatever, please have a look at possibly integrating it into the menu system instead.

http://rtr.ca/empeg/

The programming interface is currently quite simple, and looks something like this:

/* Basic sequence for userland app to bind into the menu, display, and IR buttons */

/* Not shown: all "rc" return codes have to be checked for success/failure */



#include 

int fd;

unsigned long data, buttons[5] = {5, IR_KW_PREVTRACK_PRESSED, IR_KW_PREVTRACK_RELEASED, IR_KW_NEXTTRACK_PRESSED, IR_KW_NEXTTRACK_RELEASED};

unsigned char screenbuf[EMPEG_SCREEN_BYTES] = {0,};



fd = open("/dev/empeg_display"); /* substitute the actual devicename -- I don't know it */

top: while (1) {

       rc = ioctl(fd, EMPEG_HIJACK_WAITMENU, "MyStuff");

       rc = ioctl(fd,EMPEG_HIJACK_BINDBUTTONS, buttons);

       while (looping) {

          rc = ioctl(fd,EMPEG_HIJACK_DISPWRITE, screenbuf);

            /* or ioctl(fd,EMPEG_HIJACK_DISPTEXT, "Some\nText"); */

          rc = ioctl(fd,EMPEG_HIJACK_WAITBUTTONS, &data);

       }

       rc = ioctl(fd,EMPEG_HIJACK_UNBINDBUTTONS, NULL); /* VERY important! */

   }

Downloading it now!

Ooh! I like the temp warning!
just one thing, you'll need to be able to set the alarm temp in C & F.

FITNR?

top work again!

>you'll need to be able to set the alarm temp in C & F.

Silly me, forgot about the Yank's again (despite the baseball playoffs).

I'll drop degreesF into v26 (no release date planned yet).

Update: Okay, v26 is out with the C/F conversions shown for all temperatures.

Also, I fixed some bugs in the text output, and simplified the MaxTemp logic.

I'll check v26 (jebus! now v27!!) in a moment. Could you have the screen go into blank or something when paused for some time, like say, 5 minutes. A bold paused box floating around the screen would be too much to ask I guess? ;)

>Could you have the screen go into blank or something when paused

I think my existing Screen Blanker function will do this already, so long as the screen contents are not changing/scrolling while paused.

Heh, here we go again. It's like rubbing a lamp! New genie, this time.

Mark, you have our admiration and respect. Nice work!

Now, today on the way home, I had a thought... (he says as he rubs the lamp)

What if the voladj selector had four presets instead of three. It could have the three existing ones (low medium high), and also a new one called CUSTOM. The custom settings could be derived from a special [voladj] section of config.ini.

I'm aware that the config.ini isn't available when the kernel first fires up (the disks are not yet spun up), but I'm pretty sure it's readable at some point, right? And the kernel somehow knows (or can know) when it is able to read the config.ini?

The reason is that I've been very keen on the idea of playing with the parameters for Richard's code to make it behave a little differently, there just hasn't been an easy way for me to throw a whole bunch of different parameters at it in short order.

Hmm. Now that I think about it... if there were a custom setting, is there enough free bytes of flash to store the four-or-so parameters for the custom voladj settings? Then we wouldn't even need config.ini and it'd be even easier to play with them...

I'm just thinking out loud here, of course. I wouldn't want to squander my three wishes on silly stuff...

Cool stuff, like it so far. Two comments:

1) Since you're in Canada, why do you only have a MAX temp warning, why not a minimum one as well?

2) Probably nothing you can do about this one, but....

Mike's timing fixes were intended to help debounce the switches on the volume control knob. His method for doing so was to check the timing of the messages and ignore them if the user changes volume direction too suddenly (as tends to happen with dirty switches).

The first problem I see is that it makes the breakout game harder to play because it won't change direction suddenly as easily as it used to.

I know, I know, I'm the one who suggested that the timing fixes should be in your kernel. I'm not saying to remove them. They are correct in the case of a flickery volume knob. I just wanted to say that this is one side-effect you might want to know about.

I'm wondering, though, just how the knob's switches are interpreted in the first place. Are they interpreted at the kernel level, or are they just getting Up and Down messages from a PIC somewhere? My point is that the current fix seems like a bit of a kludge (no offense, Mike), almost as if the REAL debouncing needed to be done in a PIC somewhere that the software doesn't have access to, and so the only solution was to put a band aid on the symptom of the problem rather than its source. If true, then Mike's current implementation seems like the only proper way to deal with it at this time.

Since your player has brand-new switches, you don't have a glitching knob to test against, so playing with the timings yourself (for instance, making them tighter for the game only) probably would be counterproductive...

Has anyone told you recently that "You Da Man!". Can't wait to try it out.

-Mike

Great news...
I was thinking of rewriting init, as this seems to be the ideal application for starting up external apps.
The idea is that init does the usual stuff ( mount disks, start player ) and then reads a file which contains menu items and commands to execute.
This will keep memory usage low and shouldn't affect the player app.
Is the source for the original init available? If it's not, would it suffice to mount disks and start the player app?

re: custom voladj settings

I don't think it would be too wise to chew up any more flash memory for custom VolAdj parameters. As much as I'd like it, we really do have to exercise restraint on this incredibly precious/limited resource. Currently I use just four bits (total) to keep track of separate car/home settings; to do fully custom would require perhaps 32 bits or more. Uh Uh.

But just as I have enabled easy menu extensions from within the kernel, with SOME space for certain persistent settings, I really believe the next step to be a userland application. Frank has suggested enhancing/replacing "init" as a starting point for userland extensions (good place to do it, too). As that line of development continues, I believe we may commandeer a couple of disk sectors for userland persistent settings -- like custom voladj. The existing VolAdj ioctl()s are still there, so a userland menu extension can easily be coded to allow full tweaking TODAY, and with some hope of persistence later on.

Anyone wanna volunteer to do that? (I'm almost strictly a kernel guy)

One definite possibility for grabbing a couple of disk sectors would be to simply resize the swap partition to be a block smaller. We could then do direct I/O to /dev/hda to read/write the freed sectors; they don't need to be in the partition table (but they could be..).

> Since you're in Canada, why do you only have a MAX temp warning, why not a minimum one as well?

Coming as soon as it cools down here some.. Not really a warning, though, but a complete "STALL BOOTING NOW UNTIL HELL THAWS AGAIN"!

I need to play with the thermal sensor some more, as it is definitely NOT working as intended (as an Empeg/Rio insider has already mentioned). With v25 of my patches, the thermometer on my Mk2. only changed reading after power cycles(!), which is why I added the superfluous call to empeg_inittherm() prior to each reading in subsequent patches.

>Mike's timing fixes ... makes the breakout game harder to play

Stop whining! The game was far too easy before, and I still win first try every time (almost).

>wondering just how the knob's switches are interpreted(?)

I haven't looked too closely, but the knob generates IR codes (all of the front panel stuff just pretends to be an IR remote) which are handled (repeat rate, debouncing, ..) in the kernel in empeg_input.c Take a look there if you need to figure it out more (I have not bothered.. my stuff just piggybacks on the output from that stage).

Cheers!

>Has anyone told you recently that "You Da Man!".

Yeah, just a few folks.
Thanks! Like most OSS developers, I thrive on feedback!

One definite possibility for grabbing a couple of disk sectors would be to simply resize the swap partition to be a block smaller. We could then do direct I/O to /dev/hda to read/write the freed sectors; they don't need to be in the partition table (but they could be..).

I think I mentioned this in another thread, /dev/hda3 (32MB) is an unused partition by default. Some people create a /usr filesystem as I did, but I would be willing to give that up if it could be used for user settings. Instead of resizing the swap partition (which will get erased by an upgrade because the partition table gets rewritten) shouldn't it just write to that unused partition? Just a thought. I'm not well versed enough in low-level disk IO to figure out this stuff but I do know that partition was basically meant for user apps.

>I was thinking of rewriting init, as this seems to be the ideal application for starting up external apps.

How about just renaming init to something like "real_init", and then substituting a separate program
which forks off a few threads to bind menu entries (the BIND is 100% blocking, at present), and which
then runs the "real_init" as normal afterwards?

>This will keep memory usage low and shouldn't affect the player app.

Ahh.. possibly. combining them into a single executable might save us some memory; or maybe not much, since libraries are the only really common part, and those ought to get shared in memory anyway.. but a combined init might be a better (simpler) way to do it anyway.

>Is the source for the original init available?

I should hope so (it had better be available!) .. Rob?

>I think I mentioned this in another thread, /dev/hda3 (32MB) is an unused partition by default
> Instead of resizing the swap partition (which will get erased by an upgrade because the partition table gets rewritten)

Another possibility might be the boot sectors. I haven't looked at the empeg partition table yet, but most Linux configurations blow a whole (virtual) track (63 sectors) for the "boot sector", leaving 62 unused unallocated sectors at the beginning of the drive, just after the partition table. We could grab one or more of those without much fuss, I suspect (various MS-DOS drive-extenders like DiskManager and EZDrive do something like this).

I agree with those who have sent some praises in your direction lately. You're really kicking some serious butt on the Empeg hacks & addenums -side.

I've actually been a bit bummed about the fact that we haven't had enough really deep-to-the-core guys working on the extras for Empeg. It seems that now we have a couple. I appreciate your work.

Sort of really buffs up my intentions on starting to work on a project myself, I've been really looking for something as the Hijack, because my resources aren't that great of creating one on my own.

It brings great value to be able (at least in the near future, if the issues where to store data gets cleared) to get code some little app on top of the actual player software. This was the thing hindering some little projects I've had in mind. So you're sort of adding others' interest to coding by coding yourself.

Ty.

I really believe the next step to be a userland application.

I guess. But I really like how the voladj settings are implemented in your kernel because I can do this stuff without needing to play at the shell prompt or even install the developer build of the software. There's something to be said for a kernel-only mod that can be loaded in one simple step (with my logo editor).

What about the one Custom setting controlled by some config.ini parameters?

What would be nice would be a method of calling a userspace program from the menus...

ie specify a command line in config.ini... read it in from the kernel and create a menu item for it... then call the program when the menu item is selected...

This would give us an installation method as well as a hook for running user space programs...

It would save having to modify init which gets rewritten after every update...

Is this feasible...? In fact the other though that just sprung into my head is that the kernel calls init itself... so wouldn't it be possible to change the path it calls...? maybe force a mount of /drive0 and then call our own init that could live in the music partition...?

The idea being to try and get away from putting anything in the partition that gets rewritten by a player upgrade...

Cheers

Kim

>This would give us an installation method as well as a hook for running user space programs

Err.. we'd still need a method for getting the actual executable program down to the empeg.

And having the kernel initiate exec'ing userspace stuff is .. well, quirky!
I'd kinda like to see a userspace application that initializes the menu items and handles the dispatching. Mmm.. gotta think more about it, though.

Not too big a deal, I suppose, to have the kernel initiate something.
But the config.ini data is not available to the kernel, unless we wanna add code to open it up and parse it. Could be done, but this is really much better left to userspace IMHO.

Mmmm..

Hijack v30 is now available. Get it! Try it!

Mark, What you've done is simply amazing! What a sweet package of utils for our favorite player. With the ever-present help of Tony (courtesy of his LogoEditor, thanks Tony!) the install was so simple--any user able to install the beta releases of the player software can easily apply this kernal patch. It was just a drag-n-drop of the .ZIMAGE file into the logo editor and away it went...60 seconds later--POW new kernal and new toys. Too sweet.

Folks, if you have not tried this yet--DO IT.

There is no longer a need to fear the kernal!

> > Is the source for the original init available?
>
> I should hope so (it had better be available!) .. Rob?

We've asked before but it hasn't appeared, so I guess not. It shouldn't be too hard to reverse engineer, though. I just haven't been able to find any round tuits...

Borislav

I've been thinking a little further...

how about we put our own root on /dev/hda2 with our own init that calls our userland programs mounts the empeg root (/dev/hda5) somewhere and chroot and execs the distributed init...

We still need a way to upload to /dev/hda2 but the contents of /dev/hda2 remain over an upgrade... and which partition to mount as root is managable from the kernel...

so user binaries would get installed in /dev/hda2 with our own init and the empeg distributed stuff remains untouched...

we could go further and have our init look for packages to install that have been uploaded to /dev/hda2 (or install scripts if the packages are too big for /dev/hda2)

Our init could see config.ini and initialise all the menus before calling the real init...

Would this work...? or would there be some additional problems with chrooting for the real init...? My understanding is that it should work as it is the equivalent of what happens with an initrd... and an initrd allows programs to continue running that were spawned from the initrd even after you remount the real root...

Cheers

Kim

OK in trying to play with this idea I seem to be having problems overriding the root to mount via the command line in the .config of the kernel... Am I wrong in assuming I should be able to change it here...? I have mine as "mem=12M,root=/dev/hda2" but it seems to ignore that and just continues mounting /dev/hda5 as it was before...

I am just building a kernel with no root in the CONFIG_CMDLINE at all just to see if it makes any difference... and then I will try hacking the source itself to force it to mount the partition I want it to...

Cheers

Kim

OK found where /dev/hda5 was hardwired in... have now got it booting to my own init... will go ahead and try and write an init that will spawn the original init after running it's own stuff...

I'll let you all know how it goes when I get it going...

Cheers

Kim

OK here it is... really small patch to use /dev/hda2 as root instead of /dev/hda5

I first booted using a normal kernel and dropped to the shell and copied everything off the existing root partition to a new partition on /dev/hda2...

mke2fs /dev/hda2
mount /dev/hda2 /mnt
tar -cplf - . | (cd /mnt && tar xpf -)

Next I removed the existing /sbin/init on my new partition and replaced it with a new script (nothing special... just mounts /dev/hda5 on /realroot before asking whether to drop to a shell or run the original init)

I have tested playing with blitecho etc in the replacement init before it calls the real init and that sort of thing works fine... next is to write a program that will use Mark's menu system and see how that goes...

Eventually we can cut the stuff that isn't needed out of /dev/hda2 and write some software to upload install scripts there and custom programs...

If we can settle on a standard layout for /dev/hda2 we might even be able to produce an image of the partition that could be written to partition in a similar way to how player upgrades are done...

Cheers

Kim

Umm... cosmetic update to really small patch so the comment matches the code... *grin*

Cheers

Kim

You shouldn't need to do inittherm repeatedly - just once. It starts the chip doing continuous conversions - or should do, if the config byte is set up for this (which it should be). Writing the config byte is dangerous, as I said before.

It takes between 0.5s-1s to do a conversion. Read temperature reads the result of the last conversion.

If you're trying to prevent HDD damage at low temperatures, use GPIO16; you can use this to hold the HDDs in reset, which puts them into deep sleep mode. The initial boot code has stuff in there to do this, which is currently disabled; the delay on reading the thermometer would add ~1s to boot time as you wouldn't be able to let the drives out of reset until you'd read the temperature.

Hugo

I should hope so (it had better be available!) .. Rob?

Why had it better be? It isn't based on any GPL code whatsoever - it's proprietry.

In practice it isn't rocket science (the whole point is that it's minimal) so I'll look into a source release.

Rob

OK further thoughts... (someone tell me to shut up if I think aloud too much... *smile*)

/dev/hda2 as a new root partition... /etc/rchome.d containing a list of programs to start if we are at home... /etc/rccar.d containing a list of programs to run if we are in the car... an installer program that runs something like ftp and allow for programs to be uploaded to the empeg (and maybe downloaded too...? empeg-taxi?) A more complete and up to date /usr with things like vi ssh etc...

rc*.d should be symlinks to somewhere on the music parition so that we can create a partition image of /dev/hda2 with the installer, init, and updated distribution...

maybe the rather than rc*.d directories we go for entries in config.ini ...? Actually this might be better as then we could add the installer program to the list of things to run only when we need to install something and remove it afterwards...

anyway the idea being to customise your empeg the first step is upload this new partiton image and a new kernel that boots off that partition using a program something like the upgrade tool... and then we have our complete installation system and plugin system running... AND it doesn't matter if we update to a new release of the player software... to call the player software from our new init we chroot to /dev/hda5 and call that init... (or maybe just player ?)

What do you think...?

Cheers

Kim