Kernels


Yay!....can I have something to put my new funky kernel on now :rolleyes:
 
Good work Squidge.

Just had an absolute gut buster from Magic Eye's, apparently they do not have to release there Kernel source at all as they obtained a 'private' licence to use that code and u-boots code.

Do I hear a bulls**t in the house ;). That said somebody else at MagicEye's has already given me some of the code (not all :() so they really don't know what one hand is saying to the other.
 
Hmmm, still only 32MB memory. Still trying to initialise a non-existant cs89x0 network chip. FAT still reports bogus sectors. /etc/inittab still missing an action field. Still can't open expanded /dev/ram1.

Doesn't seem like much has changed :)

Then again, was the delay loop calibration there before? 99.32 BogoMIPS! Woohoo!
 
Robster posted on Oct 11 2005 at 09:15 AM said:
Then again, was the delay loop calibration there before? 99.32 BogoMIPS! Woohoo!

It was in Kernel 2 for definite (the one that gave us sound and unscrambled gfx).

Maybe the sd is fixed in this one? ;)
 
Last edited by a moderator:
Squidge posted on Oct 11 2005 at 10:52 AM said:
Robster posted on Oct 11 2005 at 09:15 AM said:
Then again, was the delay loop calibration there before? 99.32 BogoMIPS! Woohoo!

It was in Kernel 2 for definite (the one that gave us sound and unscrambled gfx).

Maybe the sd is fixed in this one? ;)

It was not in kernel3 if I remember, hmmmm, do we honestly think for one minute that there is an SD fix in this ;). Oh well, back to work, damm I would rather be hacking about.
 
Last edited by a moderator:
Kernel 5 here we are :)

Note that this one needs flashing differently. Do it wrong, and you'll get loads of really helpful error messages like nand ecc errors and the like :eek:

GPH say:

"The lighting address is different from first board and second board. When you do lighting,please confirm the lighting address. The address of second one is 0x80000."

What this actually means is that you should change the address you flash the kernel to, and then update uboot's configuration with the changes. eg:

loadb
<kermit upload of kernel>
nand erase 0x80000 0x100000
nand write 0x1000000 0x80000 0x100000
setenv bootcmd 'nand read 0x1000000 0x80000 0x100000; bootm'
saveenv

This means the nand configuration changes from:

0x00000000-0x00020000 : "Bootloader"
0x00020000-0x00040000 : "Param"
0x00040000-0x00140000 : "Kernel"
0x00140000-0x01940000 : "Filesystem"
0x01940000-0x04000000 : "Extend"

to:

0x00000000-0x00060000 : "Bootloader"
0x00060000-0x00080000 : "Param"
0x00080000-0x00180000 : "Kernel"
0x00180000-0x01980000 : "Filesystem"
0x01980000-0x04000000 : "Extend"

Now, this says to me that the new kernel overwrites part of the old file system, so I would assume it would bitch and moan, but it actually seems to work. Don't try anything exotic though, as it might reside in the address now used by the kernel.

On another interesting note, if anyone finds out why they changed the size of the bootloader from 128KB to 384KB, let me know :)
 
I have no more idea about the machinations of GPH's thought processes than anyone else, but I'd guess that they might want more space for the bootloader so they can add some graphical goodness etc to it. In the plain, stock version, it's over 100k so they're pretty close to the 128k level even without any frills...
 
Just what I was thinking, if you used a logo in U-Boot it would bloat by just about this amount based on my tests. Much better then the dirty LCD ghost you normaly get.

What really scares me about that is they would need to add support for the LCD to U-Boot (there current builds, and ME's code do not support any LCD's).

That is just a little risky this close to getting it out the door don't you think ;). Maybe they have just bloated it so they can add it later (and brick a load of GP2X's in the process) :D.
 
Back
Top