Kexec

[MilanC]

Hi everyone!

1.
I think it would be nice if the default kernel could have kexec support (and maybe a kexec binary in the firmware).
That way, testing custom kernels would be much simpler, and less risky (i.e. not risky at all)

2.
I suppose overclocking is planned to be done through some software?
Kernel cpufreq driver might be cool, with "conservative" frequency scaling policy. Some ridiculously low clock when idle or for simple tasks [ or does high frequency + hlt instruction save more power? ], default scaling_max_freq 600MHz, but with cpuinfo_max_freq forced to something like 1 GHz...
Voltage scaling would be nice too, but I think that's just asking too much... the hardware probably doesn't support that.
EDIT: I have read somewhere that voltage could be modified - but is it in software, or was it a hardware mod?
Mmmh... "linux-phc"-like interface to set voltage...

 

[cb88]

i don't think kernel testing is risk anyway since the device can boot from SD and is unbrickable (by all accounts anyway)

 

[Squidge]

I think it would be nice if the default kernel could have kexec support (and maybe a kexec binary in the firmware). That way, testing custom kernels would be much simpler, and less risky (i.e. not risky at all)

Pandora supports booting a kernel from SD card, so no need to modify the version on NAND, and therefore no risk

I suppose overclocking is planned to be done through some software?
Kernel cpufreq driver might be cool, with "conservative" frequency scaling policy. Some ridiculously low clock
[...]
Voltage scaling would be nice too, but I think that's just asking too much... the hardware probably doesn't


The hardware (and kernel) already supports cpu frequency and voltage scaling, depending on system load.

You can change maximum voltage through sysfs interface, and max frequency can be changed in 1Mhz steps just as easily.

 

[Orkie]

kexec is however very convenient, there is no reason not to enable the syscall really. I've patched the Open2x kernel to support it.

 

[Squidge]

Indeed, as it skips out the bootloaders and starts testing your new kernel quicker.

 

[cb88]

@Orkie did that affect the kerenel size much? if not that would really be the only reason against it... also i read that kexec was only really stable on x68 but i'm thinking that info was out of date

might be nice for fully automated system upgrades....

 

[Orkie]

Barely added anything, maybe half a KB at most? Not had any stability problems with it either. The kexec functions are only called if you use the syscall anyway, so it's not something that can randomly cause problems and I've yet to have it fail to load a kernel for me.

 

[MilanC]

QUOTE
Pandora supports booting a kernel from SD card, so no need to modify the version on NAND, and therefore no risk

Hm... first LiveCD on x86, now we'll have LiveSD on ARM?
*starts thinking about some 64M SD card with kernel and openembedded-based ramdisk... eject SD card once loaded in RAM... might be quite fast...*
QUOTE

The hardware (and kernel) already supports cpu frequency and voltage scaling, depending on system load.

You can change maximum voltage through sysfs interface, and max frequency can be changed in 1Mhz steps just as easily.

Oh, then that's where the "100 hours playing mp3's" comes from... :rolleyes:

*definitely buying a Pandora as soon as it's out. Finally found an all-in-one tablet/laptop/multimedia player I wanted.*
----------------------------

Off-topic:
I've read that the PowerVR SGX supported OpenGL ES, but not full OpenGL, and that the driver was closed source. However, there seems to be an open source 2D driver for GMA500 (PowerVR SGX used with intel atom). Do you think it would be possible to write an open-source full OpenGL-enabled driver that would do soft-rendering using the DSP (or maybe part on GPU, part on DSP - impossible?), then sending it to the framebuffer? That would make porting of many games much easier...
However, memory bandwidth might be a problem then...
EDIT: I would've thought the SGX was fully OpenGL compliant, as it's used with x86 Atom chips; and ImgTec website says "exceeds the requirements of OpenGL 2.0"... Why do we end up using OpenGL ES? [ performance maybe? ]

 

[cb88]

i don't think the atom SGX and the pandora SGX are the same...