Bugzilla – Bug 980570
gfxboot should be more flexible selecting a suitable video mode for itself
Last modified: 2017-12-07 17:36:52 UTC
See https://github.com/openSUSE/gfxboot/issues/7. It doesn't start on Chromebooks as it doesn't find/can't set a video mode.
Created attachment 677455 [details] test iso 1: show available video modes Please use this ('dd' to a usb stick) to show the available video modes.
Created attachment 677518 [details] result from test iso 1 It just hangs in there. With kvm /dev/sdb on another machine I can see it correctly gives resolution list.
Does it react to 'ESC'? Like showing the text boot menu?
Right, yes it does react to Esc, I can get the boot: menu with the harddisk/linux/upgrade etc options. So it's not hanged.
Ok, then everything is fine, actually. I'll put together a new test iso today or tomorrow.
Created attachment 677583 [details] test iso 2: show active vbe mode and try to use it Please test this one. Ideally it shows the current mode and then lets you continue. Anything can happen, but I'd like at least to know the mode number.
Created attachment 677602 [details] result from test iso 2 No graphics still. (but under kvm I got the graphical menu instead of text one)
Created attachment 677608 [details] test iso 3: also list available modes Please test this one. It should list all available modes on the first text screen. Otherwise nothing has changed. Please post a screenshot of the mode list (provided there is anything).
Created attachment 677609 [details] result from test iso 3 We've some modes. The native resolution of Acer Chromebook R11 (Braswell 14nm CPU) is 1366x768.
Created attachment 677616 [details] test iso 4: just set mode 0x140 Ok, then let's just hardcode this mode number an see what happens.
With test iso 4, blank black screen after the "Press a key to continue..." prompt after the modes are displayed as in the previous image attachement. Keypresses don't seem have a visual effect. (On kvm /dev/sdb, 320x200 graphical output)
Created attachment 677696 [details] test iso 5: use framebuffer for drawing Please try this one. With some luck it might work.
With test iso 5 still just blank black screen after seeing the text "Initializing gfx code...".
Created attachment 677773 [details] test iso 6: try very hard to show something Ok, if this one also doesn't show anything I'm out of ideas for the moment.
Created attachment 677776 [details] result from test iso 6 We have image! Sorry for bad colors, they are normal red/green/blue for all the blocks. The text is ip 26d: 2010b0a9.4 (ie the '1' is what's barely visible under green color in the photo)
And if you press 'ESC' there, what happens?
Nothing seems to happen when I press Esc, the screen stasys as is.
Ok, what you see there is the debug window. You can single-step through the code with 'Enter', 'ESC' leaves the debug mode. The dots were just sprayed all over the graphics framebuffer. If you go two steps further with 'Enter' (provided it works), what number appears in the data window (upper left)? (The ip in the bottom left should show '27a'.)
I'm on vacation next week and won't respond during that time.
The number that arrives at the bottom row of data is: 0: 201114ad. c Below in the bottom box there is also: err 0 ip 27a: 45.7 Let's continue after next week then probably.
Created attachment 680084 [details] test iso 7: try to draw something I've prepared a new test image. It shows at startup on a text screen the internal memory layout. Please attach the numbers (or screenshot). Then, it will draw a bit. On the first debug screen, you should see the dots all over the screen as before + some lines crossing the screen + a small rectangle in the middle. When you press ESC there, you reach another debug point and the text 'Test' should be printed at the top of the screen. Do any of these things show up?
Created attachment 680175 [details] result from test iso 7 The memory layout is shown, but only the image shown in the attachment (below memory layout) is what's gotten after that. Waiting or pressing Esc does not change anything. That is, only the diagonal lines background that was also shown with test iso 6 (aside from top left corner that had other info), with nothing else. Note that while the background is drawn immediately, any characters outputted are v-e-r-y slow to output, so any timing assumptions may be wrong. As mentioned at https://johnlewis.ie/alls-well-that-braswell/ - if one would have a full screen of text output, it might take a full minute to draw. Think of a 300bps modem line. With short and few lines like with test iso 6, it only took maybe 10-20s or so though.
I'm currently out of ideas and it will be tricky to make progress without such a device at my desk. :-( Issues I've seen: - the video bios knows only one video mode with an unusual resolution; the standard gfxboot script doesn't expect this (and doesn't provide a theme in this resolution), but that can be trivially adjusted - it seems that the graphics card can only be accessed via framebuffer; but gfxboot uses the old method via 64k windows mapped at 0xa0000 for drawing; I've added a patch that changes this (see link below) - and which works at least on some test machines - it still doesn't work here; the patch seems to be ok because you can (a) draw directly by using the framebuffer pointer and do memory writes (the dots you see with the test isos) and (b) the debug window is visible (it's drawn using standard internal routines) - my suspicion atm is that _reading_ from the framebuffer causes problems: it's done implicitly internally at a number of places and can't be avoided (design decision from the old times where free memory was scarce); also, maybe strange mtrr settings are an issue I've put the current state into the chrome_fb branch (there's some translation update that slipped into it which can be ignored). When you build the 'test_fb' theme, you basically get test iso 7. https://github.com/openSUSE/gfxboot/tree/chrome_fb
Thank you for the investigation! It seems valuable information nevertheless. In case budget for extra hardware is found, for example this particular Chromebook is the 4GB/32GB model at https://www.amazon.de/Acer-Chromebook-CB5-132T-C732-Convertible-Quad-Core/dp/B01618Z3R4/278-3649416-4927750 I bought it for experimentation myself, since it has some interesting features like Coreboot (like all Chromebooks), touch screen, 14nm CPU with modern GPU features (Broadwell like) and 4GB RAM which is useful amount.
gfxboot doesn't support 24bpp or 32bpp. The only mode that is supported by coreboot's native graphics initialization is 32bpp. As the graphics initialization is done by coreboot, the pixel format can't be changed in (Sea)VGABIOS. I'm working on supporting multiple resolutions, but the main problem persists. There will be only one advertised pixel format ever.
gfxboot supports 32bit but not 24bit.
You are right. I got confused looking at the code: pixel_bits db 0 ; pixel size (8 or 16) color_bits db 0 ; color bits (8, 15 or 16) This should be fixed. SeaVGABios advertises 24bpp as the panel does support 24bpp, even though the VBE format should be 32bpp. I'll send a fix to SeaBIOS.
I found another issue: I tested KDE Neon Live DVD. It does not boot because the code checks additional window attributes: mov dx,[es:edi+2] ; win A/B attributes and dx,707h cmp dl,7 jz set_mode_50 ; win A is rw It depends on VBE_WINDOW_ATTRIBUTE_RELOCATABLE. The comment indicates that it needs only VBE_WINDOW_ATTRIBUTE_READABLE and VBE_WINDOW_ATTRIBUTE_WRITEABLE. Is the attribute VBE_WINDOW_ATTRIBUTE_RELOCATABLE required ? It shows a splash screen and boots if I just advertise VBE_WINDOW_ATTRIBUTE_RELOCATABLE without checking what's it's good for.
> SeaVGABios advertises 24bpp as the panel does support 24bpp, even though the > VBE format should be 32bpp. I'll send a fix to SeaBIOS. Uhm, is there a way to detect this situation? Like, add at least the color mask bits up to 32? > Is the attribute VBE_WINDOW_ATTRIBUTE_RELOCATABLE required ? Good point. It isn't.
(In reply to Steffen Winterfeldt from comment #29) > > SeaVGABios advertises 24bpp as the panel does support 24bpp, even though the > > VBE format should be 32bpp. I'll send a fix to SeaBIOS. > > Uhm, is there a way to detect this situation? Like, add at least the color > mask > bits up to 32? Yes that should be working, but all VBE clients expect the bpp to match the accumulated color bit mask. I've sent a fix to SeaBIOS. > > > Is the attribute VBE_WINDOW_ATTRIBUTE_RELOCATABLE required ? > > Good point. It isn't. Looking at the code is seems that relocation is required as the "window" has a maximum pagesize of 64K, but I'm not familar with those addressing modes. In VBE2.0 there's a linear framebuffer that does not need relocations at all and it's the only mode supported by coreboot's SeaVGABios implementation. Would it be possible to add VBE2 and linear framebuffer support to gfxboot ?
> Looking at the code is seems that relocation is required You're right; after reading up the vbe specs again, 'relocation' means mapping different regions into the window. So yes, it's required and the code is correct. > Would it be possible to add VBE2 and linear framebuffer support to gfxboot? Yes, I've done this in the branch mentioned in comment 23. The patch basically simulates the 64k window thing by moving 64k segment selectors across the framebuffer.
My patches made it into SeaBios git. Following points are fixed: * Advertise 32bpp instead of 24bpp * Advertise additional VBE modes I tried your examples but I'm not sure what they want to show, and pressing ESC doesn't work. It looks like it crashes. Is there anything I can help at ?
I don't see any reason why the code in the chrome_fb branch shouldn't work. It does, for example, work in qemu as running './gfxtest -t test_fb' shows. From Timo's reports it seems it gets the framebuffer address right: the code in themes/test_fb/test_fb.bc that draws directly by writing bytes into the fb and creates the diagonal pixel pattern seemed to work. But then it gets wrong. I don't have an idea so far, why.
Fixed by https://github.com/openSUSE/gfxboot/pull/25 Tested on real hardware.
Thanks a lot! Then, AIUI, the only thing left is to recognize the video mode as 32bit even though it's advertised as 24bit, right? Can we do that by adding up the rgb+reserved bits and use this if the sum is > than bits_per_pixel?
If you mind adding a workaround for broken VGABIOS, yes that's the solution. Please note that the bpp is correctly advertised in SeaBios git. With the next stable release this issue will be fixed, too.
Patrick, if you could try out https://github.com/openSUSE/gfxboot/pull/26 this would be great. There should be everything in place now.
I think it's all in Tumbleweed meanwhile, closing.
My framebuffer fixes are part SeaBIOS 1.11.0 stable.