Thanks for your replies. It's exciting to have my questions received so well.
I'm not quite allergic to opening the case of my unit, but I should be totally honest about my plan to be a 'consumer' rather than a 'producer' of coreboot knowledge. Investing time and money in hardware to program the flash ROM and to detect small steps toward success would take me off-line from other projects (like earning a living) that I can't afford to quit.
My little Evo has a socket for additional flash memory, but the socket is empty and that's OK with me:
I am using the T20 as a thin client for several hours each day, with gentoo linux kernel 2.6.24. I get X graphics at 1280x1024@16bpp, the maximum supported by the GX1, by using a patched version of GRUB that lies to the kernel about what memory should be used where. This patch, kindly supplied by others, sacrifices the framebuffer console displays, though. (All of them!) I am hoping that coreboot might get me everything: best-possible video, hi-res framebuffer, and efficient [non-emulated] sound support. (Then I would drop X and go with directfb for VNC.) Success stories and documentation are on the wiki at http://open-evot20.sourceforge.net/wiki/
Thanks again, ... Philip
Am Mon, 12 May 2008 22:38:45 -0700 schrieb Philip Loewen philip@tidepool.ca:
Thanks for your replies. It's exciting to have my questions received so well.
I'm not quite allergic to opening the case of my unit, but I should be totally honest about my plan to be a 'consumer' rather than a 'producer' of coreboot knowledge. Investing time and money in hardware to program the flash ROM and to detect small steps toward success would take me off-line from other projects (like earning a living) that I can't afford to quit.
My little Evo has a socket for additional flash memory, but the socket is empty and that's OK with me:
I am using the T20 as a thin client for several hours each day, with gentoo linux kernel 2.6.24. I get X graphics at 1280x1024@16bpp, the maximum supported by the GX1, by using a patched version of GRUB that lies to the kernel about what memory should be used where. This patch, kindly supplied by others, sacrifices the framebuffer console displays, though. (All of them!) I am hoping that coreboot might get me everything: best-possible video, hi-res framebuffer, and efficient [non-emulated] sound support. (Then I would drop X and go with directfb for VNC.) Success stories and documentation are on the wiki at http://open-evot20.sourceforge.net/wiki/
Thanks again, ... Philip
Yes Juergen Beisert works an the Sound of the GX1. It works for my. He says it's not perfect but you have sound. I uses an Evo T30. On this the flashrom works.
Greeding Markus
On Tuesday 13 May 2008 07:38, Philip Loewen wrote:
Thanks for your replies. It's exciting to have my questions received so well.
I'm not quite allergic to opening the case of my unit, but I should be totally honest about my plan to be a 'consumer' rather than a 'producer' of coreboot knowledge. Investing time and money in hardware to program the flash ROM and to detect small steps toward success would take me off-line from other projects (like earning a living) that I can't afford to quit.
My little Evo has a socket for additional flash memory, but the socket is empty and that's OK with me:
I am using the T20 as a thin client for several hours each day, with gentoo linux kernel 2.6.24. I get X graphics at 1280x1024@16bpp, the maximum supported by the GX1
Maximum support up to 2048x1024@16bpp (its simply a question of available memory bandwidth).
by using a patched version of GRUB that lies to the kernel about what memory should be used where.
coreboot can setup the correct memory mapping between main and video memory for the old GX1.
This patch, kindly supplied by others, sacrifices the framebuffer console displays, though.
With the kernel built in framebuffer console you can't work, if there is no VSA in your system. You need a native GX1 framebuffer driver with coreboot.
(All of them!) I am hoping that coreboot might get me everything: best-possible video, hi-res framebuffer,
Yes.
and efficient [non-emulated] sound support.
Partly yes. Difficult, because the sound hardware cannot generate a regular interrupt. I'm still out of luck to write a small system management code that only forwards SMI occurrence to a regular interrupt the kernel could handle.
Juergen
-
Juergen Beisert -
Markus -
Philip Loewen