Since the kernel is stored in flash I figured that there must be maximum size for it. Does anyone know what it is?

I'm having a bizarre problem - downloading a new kernel doesn't seem to work, even though I'm using the same method that was working yesterday. The kernel on the player remains one that I compiled at 11.07pm, even though the ctime on the zimage file is today, and the image appears to download correctly according to logoedit.

I'm wondering whether my (small) modifications to the kernel to support Bass and Treble adjustments have pushed the kernel size too big? It's currently 512460 bytes.

I've "make clean"ed and rebuildt the kernel to ensure that my latest code is in the zimage file, and the build appears to go fine with my latest modifications proprogating correclty to arch/arm/special/special.a (strings special.a |grep shows this). Linking appears to succeed, but the kernel on the player still appears to be old!

Anyone got any ideas what's going on? I'm hitting my head against a wall here!

Thanks.

Max kernel size (compressed) is 640KB in flash memory.

You are remembering to reboot afterwards, right?

Perhaps the logo-downloader has some kind of size limit (dubious) or other bug (likely).

If you have ethernet connectivity to the player, try FTP'ing the new kernel over to /proc/empeg_kernel instead of using serial. It's much faster that way, as well.

-ml

Yeah, I've rebooted in order to watch the kernel boot up messages.

I must have done something stupid somehow then in my directory structure. Maybe it's time to start afresh from the tarball.

At least I know it's not the kernel size Thanks.

I'm reasonably close to inital Bass/Treble control. I've managed to decode the dB settings in the eq section (second byte of word2 is absolute gain - 0x40 is 0dB, and the players eq settings mapped to this byte perfectly using the equation dB=20log(gain/0x40) ). The frequency and q factor have still got me puzzled though, and based on the numbers that I've seen I suspect that the player is not really adjusting f and Q in total isolation (player bugette maybe?), which makes it difficult to decode. Maybe I'm just missing something.

Anyway, dB is enough to get started - initially the user can set up the eq bands' f and Q values manually, and then access the dB gain though hijack. Eventually I want to make these f and Q values config.ini options and overload any eq settings. I will probably also lock out the treble adjustment when in 4x5 eq mode and just allow bass adjustments to all 4 channels. I've set up the gains to be +-6dB in 0.5dB increments which should be more usable than +-12dB in 1dB increments - anything over 6dB in magnitude is too extreme given the low Q factor that will be used.

It's not something silly like doing make instead of make zImage.. ?

If you have ethernet connectivity to the player, try FTP'ing the new kernel over to /proc/empeg_kernel instead of using serial. It's
much faster that way, as well.

Didn't know you could do that. Is it safe?
And do I need to 'site rw' first?

No, make zImage it is...

I'm wondering whether my Makefile got screwed somehow..
Hmm..

ftp> put genixia.zImage empeg_kernel
local: genixia.zImage remote: empeg_kernel
200 Okay.
550 Failed.

Edit: Doh! Read the FAQ and don't forget to switch to binary mode

No, no need for "SITE RW" when uploading a new kernel with FTP.

Cheers

Well, FTP worked and changed my kernel. Looks like a logoedit bug maybe?

If serial via logoedit worked before, and then suddenly stopped working with no other changes, I would suspect cabling. That's what it was when I started having trouble with my serial connection: The cable was frayed and had to be replaced. This was not immediately obvious (cable looked fine), but the replacement cable solved all problems immediately.

Other possible problems for serial uploads are other apps grabbing the serial (such as palm) or a serial IRQ shared with a modem IRQ (such as a mouse on com1 with the serial on com3, or a modem on com2 with the serial on com4).

There was one problem on certain computers where it seemed that "slowing down" Hugo's dowload.c code by making it print debug messages helped it. This only happened on one or two computers that I know about, and was always fixed by moving to another computer.

In theory, that last bug could be solved by a slowdown instruction at the right "spot" in the code. However, despite my requests, I have not yet been offered any help in testing/debugging this by someone experiencing the problem. Since I can't reproduce the bug myself, I can't code a work-around to a problem I'm not having.

Tony, I can quite believe that it is cabling/interference given the number of computing devices in this room.

I try and help debug, but since I discovered the speed of FTP kernel downloads, I've switched methods! If it is intererference/cabling then reproducing the problem when you have a slowed down version to test may or may not be easy. Yesterday I downloaded 15 or so times during coding without issues, and then it stopped downloading completely late last night, without me being aware of moving anything!

originally by genixia:

I'm reasonably close to inital Bass/Treble control. I've managed to decode the dB settings in the eq section (second byte of word2 is absolute gain - 0x40 is 0dB, and the players eq settings mapped to this byte perfectly using the equation dB=20log(gain/0x40) ).

Ok, it seems as though I'm wrong here..Just. The bass/treble levels are indeed changed, but some of my values result in lower volumes than they should.....all of the odd values. So it looks as though bit 0 of this word is actually doing something else...All of the player eq values are even. But dividing both the absolute gain and the 0dB gain by 2 still results in the equation being valid....I think..