* Matt Fleming wrote:
> On Mon, 14 Oct, at 09:57:26AM, Ingo Molnar wrote:
> >
> > * H. Peter Anvin wrote:
> >
> > > On 10/12/2013 10:49 AM, Ingo Molnar wrote:
> > > >
> > > +static void early_efi_write_char(void *dst, char c, int h)
> > > +{
> > > +const u8 *src;
> > > >>>
On Mon, 14 Oct, at 09:57:26AM, Ingo Molnar wrote:
>
> * H. Peter Anvin wrote:
>
> > On 10/12/2013 10:49 AM, Ingo Molnar wrote:
> > >
> > +static void early_efi_write_char(void *dst, char c, int h)
> > +{
> > + const u8 *src;
> > + u32 fgcolor = 0xaa;
> > >>>
>
* H. Peter Anvin wrote:
> On 10/12/2013 10:49 AM, Ingo Molnar wrote:
> >
> +static void early_efi_write_char(void *dst, char c, int h)
> +{
> +const u8 *src;
> +u32 fgcolor = 0xaa;
> >>>
> >>> That's RGB grey, right? Why not 0xff for a very visible wh
On 10/12/2013 10:49 AM, Ingo Molnar wrote:
>
+static void early_efi_write_char(void *dst, char c, int h)
+{
+ const u8 *src;
+ u32 fgcolor = 0xaa;
>>>
>>> That's RGB grey, right? Why not 0xff for a very visible white?
>>
>> The VGA earlyprintk code uses the equivale
* Matt Fleming wrote:
> On Thu, 10 Oct, at 07:28:44PM, Ingo Molnar wrote:
> > Btw., could we perhaps remap the whole framebuffer at init time, or is it
> > too large? If early_ioremap() fails for whatever reason then that will
> > emit a WARN_ON(), which will recurse in a fairly nasty way ...
On Thu, 10 Oct, at 07:28:44PM, Ingo Molnar wrote:
> Btw., could we perhaps remap the whole framebuffer at init time, or is it
> too large? If early_ioremap() fails for whatever reason then that will
> emit a WARN_ON(), which will recurse in a fairly nasty way ...
The framebuffer memory will be
On Thu, Oct 10, 2013 at 8:09 PM, Peter Jones wrote:
> INTN
> GetPixelElementSize (
> IN EFI_PIXEL_BITMASK *PixelBits
> )
> {
> INTN HighestPixel = -1;
> INTN BluePixel;
> INTN RedPixel;
> INTN GreenPixel;
> INTN RsvdPixel;
> BluePixel = FindHighestSe
* Matthew Garrett wrote:
> On Thu, Oct 10, 2013 at 07:45:21PM +0200, Ingo Molnar wrote:
>
> > Also, the main question would be, what is the typical value for
> > si->lfb_depth. 32 on almost all EFI systems? All around the map? Depends
> > on what graphics state the EFI bootloader passes us?
>
On Thu, Oct 10, 2013 at 07:45:21PM +0200, Ingo Molnar wrote:
>
> * Peter Jones wrote:
>
> > On Thu, Oct 10, 2013 at 07:28:44PM +0200, Ingo Molnar wrote:
> > >
> > > Is a non-32-bit framebuffer a possibility? If yes then it might be nice
> > > to
> > > emit an informative printk() here, so tha
On Thu, Oct 10, 2013 at 07:45:21PM +0200, Ingo Molnar wrote:
> Also, the main question would be, what is the typical value for
> si->lfb_depth. 32 on almost all EFI systems? All around the map? Depends
> on what graphics state the EFI bootloader passes us?
Microsoft require that it be 32, so in
* Peter Jones wrote:
> On Thu, Oct 10, 2013 at 07:28:44PM +0200, Ingo Molnar wrote:
> >
> > Is a non-32-bit framebuffer a possibility? If yes then it might be nice to
> > emit an informative printk() here, so that users who try to enable EFI
> > early-printk can at least see why it's not work
On Thu, Oct 10, 2013 at 07:28:44PM +0200, Ingo Molnar wrote:
>
> Is a non-32-bit framebuffer a possibility? If yes then it might be nice to
> emit an informative printk() here, so that users who try to enable EFI
> early-printk can at least see why it's not working. (Assuming they get to
> look
* Matt Fleming wrote:
> From: Matt Fleming
>
> It's incredibly difficult to diagnose early EFI boot issues without
> special hardware because earlyprintk=vga doesn't work on EFI systems.
>
> Add support for writing to the EFI framebuffer, via earlyprintk=efi,
> which will actually give users
13 matches
Mail list logo
