Re: Video subsystem draft
Yoshinori K. Okuji wrote: > On Saturday 26 November 2005 01:28 am, Vesa Jääskeläinen wrote: >>> Compression might make the performance horrible, because PPF is very >>> optimized. >> When there is a caching implemented in a one day, it's only initial >> cost. So far I haven't seen performance problems with this. But then >> again I haven't tried it too much. > > I must test it myself, too. The performance of reading a compressed file is > slow, because of seeking. Seeking forward is fast, but seeking backward is > very slow. So compression makes sense for OS images, but not much for font > files. > The most important part is the initial cost, BTW. Since a boot loader must be > quick to start up (otherwise, the user loses some seconds every time), > caching is not so important. There is this transparent gzip support in gz file open, that diagnoses file to decide wether it is gzipped or not. If there is transparent option specified, it can also read nongzipped files. This would allow user to pack font file if there is a need to compress it (of course with cost of speed) If I remember correctly I also saw caching of sectors in disk code, so basicly if disk cache is big enough old font data will already be in memory. And this will only cause little delay as there is no I/O latency. Actual testing in real hardware will tell how good this is. I am currently only running this on vmware. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Video subsystem draft
Vincent Pelletier wrote: > By the way, there is already a font format handled by IEEE1275 > frame buffercards. > - From the standard : > > set-font ( addr width height advance min-char #glyphs -- ) > Set the current font as specified. > > So I think they can handle arbitrary-sized glyphs. > I can't find the font data definition, but as "default-font" returns > all those values for the default font, reverse engineering will be a > matter of minutes. > > If the font format you want to design could be compatible with ths one, > it would be a pleasure to port it to sparc :) - and probably the same > for PPC. I am not familiar with that, but current implementation only supports case when grub can read the actual font data itself and render it. So at this point this is a requirement for graphical console. In principle if necessary data can be acquired, hardware renderable fonts can be used but there must be a mechanism to specify viewport that hardware font rendering checks and does not exceed. Currently font format itself is open to suggestions and I would like to hear about possible issues related to some "foreigner" fonts that I haven't used before. There perhaps are many different kinds of scripts that might be unreasonable to support but at this point nothing is dropped out. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Video subsystem draft
Vincent Pelletier wrote: > By the way, I think we should start a discussion on the API common to > all architectures for framebuffer handling. Currently there is a terminal implementation that uses video subsystem to render screen. So basicly in every arch there must be a video driver if you want graphical console. You can see my current idea how to use video driver in grub wiki: http://grub.enbug.org/VideoSubsystem Actual implementation is currently in a bit flux, so I don't want people to start coding until all really needed features work correctly with one driver so others can use it as a reference when developing other video drivers. If you want to look at you can see current implementation in URL that I posted day or two ago to list. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
PowerPC C++ kernel woes.
Hello,
I've been trying to get some C++ running (now that I can print "Hello
World" from OF, I'd like to move my "Hello World" C++ kernel to
PowerPC), but it has been without much success.
I've finally figured out that there are these small data sections
which I was not taking care of in my ld script (sdata, sbss, sdata2,
sbss2). Prior to me figuring this out, I would get a crash. After I
added these sections, I've noticed several globals appear in .sbss
(using powerpc-linux-nm to see all syms), but now I get CLAIM failed
while loading my kernel in OF. Odd.
So I guess I have several questions:
Am I doing something wrong w.r.t sdata, sbss, sbss2, and sdata2
in my ld script? I am also not sure as to how these should be
aligned, if at all.
What about _SDA_BASE_ and _SDA_BASE2_? AFAIK, these should point
in the middle of the sdata+sbss and sdata2+sbss2. Should I load r13
and r14 with these values?
So far my code doesn't appear to use either register.
I 've been doing this for SDA_BASE and SDA2_BASE
PROVIDE (_SDA_BASE_ = ld_sdata + ((ld_sbss_end - ld_sdata) / 2));
PROVIDE (_SDA2_BASE_ = ld_sdata2 + ((ld_sbss2_end - ld_sdata2) / 2));
... but the linker seems to ignore my values and gives
0020f000 G _SDA_BASE_
0021 G _SDA2_BASE_
( kernel linked @ 2MB, same way as I linked my C hello world example,
which works just fine).
Thanks and have a great day.
/* The sdata section. */
.sdata ALIGN(0x1000): {
ld_sdata = .;
/* SData. */
*(.sdata)
*(.gnu.linkonce.s.*)
ld_sdata_end = .;
}
.sbss : {
ld_sbss = .;
/* BSS. */
*(.sbss)
*(.scommon)
ld_sbss_end = .;
}
/* The sdata2 section. */
.sdata2 ALIGN(0x1000): {
ld_sdata2 = .;
/* SData2. */
*(.sdata2)
*(.gnu.linkonce.s2.*)
ld_sdata2_end = .;
}
/* The SBSS2 section. */
.sbss2 : {
ld_sbss2 = .;
/* SBSS2. */
*(.sbss2)
*(.gnu.linkonce.sb2.*)
ld_sbss2_end = .;
}
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Video subsystem draft
On Saturday 26 November 2005 03:36 pm, Vincent Pelletier wrote: > By the way, there is already a font format handled by IEEE1275 > frame buffercards. > From the standard : > > set-font ( addr width height advance min-char #glyphs -- ) > Set the current font as specified. If my understanding is correct, the firmware does not handle multiple widths of fonts. If I'm wrong, correct me. > By the way, I think we should start a discussion on the API common to > all architectures for framebuffer handling. Vesa is doing this, IIRC. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Video subsystem draft
On Saturday 26 November 2005 01:28 am, Vesa Jääskeläinen wrote: > > Compression might make the performance horrible, because PPF is very > > optimized. > > When there is a caching implemented in a one day, it's only initial > cost. So far I haven't seen performance problems with this. But then > again I haven't tried it too much. I must test it myself, too. The performance of reading a compressed file is slow, because of seeking. Seeking forward is fast, but seeking backward is very slow. So compression makes sense for OS images, but not much for font files. The most important part is the initial cost, BTW. Since a boot loader must be quick to start up (otherwise, the user loses some seconds every time), caching is not so important. > Byte order is currently exactly the same as in .hex file :) Yes. > It has minor issue with widechar fonts (char width > 1). It like > contains two different font data. First there is first half of like > normal 8x16 font and then there is second half. My idea would be to > store bitmap in scanlines instead of character blocks so I can take > whole character width and draw that. I see. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Video subsystem draft
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 26 Nov 2005 02:28:53 +0200 Vesa Jääskeläinen <[EMAIL PROTECTED]> wrote: > Yoshinori K. Okuji wrote: > > If you want to improve it, feel free to do it. It is our own > > format. But I think the byte order was set conveniently. > > Byte order is currently exactly the same as in .hex file :) > > It has minor issue with widechar fonts (char width > 1). It like > contains two different font data. First there is first half of like > normal 8x16 font and then there is second half. My idea would be to > store bitmap in scanlines instead of character blocks so I can take > whole character width and draw that. By the way, there is already a font format handled by IEEE1275 frame buffercards. - From the standard : set-font ( addr width height advance min-char #glyphs -- ) Set the current font as specified. So I think they can handle arbitrary-sized glyphs. I can't find the font data definition, but as "default-font" returns all those values for the default font, reverse engineering will be a matter of minutes. If the font format you want to design could be compatible with ths one, it would be a pleasure to port it to sparc :) - and probably the same for PPC. By the way, I think we should start a discussion on the API common to all architectures for framebuffer handling. Vincent Pelletier -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDiCCXFEQoKRQyjtURAryjAJ9Xppf3KxB4aYi8m5V1Xzta6fB5XgCeJXwE lVa4Lay3OgE/JF3WHBqfZ0k= =RJLt -END PGP SIGNATURE- ___ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger T�l�chargez cette version sur http://fr.messenger.yahoo.com ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
