is running the cbfstool line mandatory after building the coreboot even if I built for each laptop separately?
Not mandatory. That's only if you would like to make a universal build that could be flashed to both G505S laptops. Now CC'ing to coreboot mailing list...
On Thu, May 16, 2019 at 10:50 AM bruts@netc.fr wrote:
I created a vm to build/patch coreboot, for each build i started clean, then patched with your scripts, however I never manually used cbfstool, I only replaced the atombios during "make menuconfig" (so .config reads either pci1002,6665.rom or pci1002,6663.rom). is running the cbfstool line mandatory after building the coreboot even if I built for each laptop separately? (if not, then maybe i should do a rebuild)
De : Mike Banon mikebdp2@gmail.com À : bruts@netc.fr Sujet : Re: Lenovo G505s, results irqpoll Date : 16/05/2019 06:17:02 Europe/Paris Copie à : awokd awokd@danwin1210.me
Which AtomBIOS you've added to your coreboot? Currently, coreboot's .config can't be set up to include both HD-8570M and R5-M230 roms even with my patch, you could only have there one ROM for integrated iGPU and one ROM for discrete dGPU. If after building the coreboot you don't run
./build/cbfstool $COREBOOT_ROM_PATH add -f $VGABIOS_PATH -n pci****,****.rom -t optionrom
command to add the AtomBIOS for another dGPU as well, your coreboot build will not be fully universal. Although it will make dGPU working on a one type of discrete G505S, it will not be working with the same coreboot ROM on another. So, regarding the difference at your messages:
R5 M230 show: [drm:radeon_get_bios [radeon]] *ERROR* Unable to locate a BIOS ROM
HD 8570M show: [drm:radeon_get_bios [radeon]] *ERROR* ACPI VFCT image header truncated
- maybe the coreboot ROM flashed to your G505S with R5-M230 dGPU,
contains only the AtomBIOS for HD-8570M dGPU, - can't find for R5-M230 and there's such an error. E.g. if you built a coreboot.rom and simply flashed it to both G505S without adding another AtomBIOS.
"*ERROR* ACPI VFCT image header truncated" is not critical and your GPU can work with it, but "*ERROR* Unable to locate a BIOS ROM" is critical.
P.S. Hopefully you could get a public e-mail that's "for coreboot / etc. mailing lists", so that we'll be able to repost this knowledge above to these mailing list archives with your current "brutc@netc.fr" removed everywhere, and also continue discussing freely with your new e-mail
On Wed, May 15, 2019 at 10:31 PM bruts@netc.fr wrote:
Hi there! thanks for your reply.
I took a peek too. The only notes.log I found was under R5
M230/Qubes/notes. Most of them don't seem bad except the ones about the PCI ROM header signature seem to say that GPU isn't getting initialized. It might still be available for passthrough, though? Might not even matter if dom0 can't use it.
sorry, one notes.log was not saved for whatever reason, but the GPU error is also showing when booting Ubuntu, so maybe this is something for Mike to have a look at? you can find notes.log also in Ubuntu folder.
R5 M230 show: [drm:radeon_get_bios [radeon]] *ERROR* Unable to locate a BIOS ROM
HD 8570 show: [drm:radeon_get_bios [radeon]] *ERROR* ACPI VFCT image header truncated
perhaps this error is expected, i don't know.
Yes, it seems to manifest most when I use the keyboard and/or mouse
while it's still booting up VMs. Basically, I'll put in my user password, then not touch anything until it's all the way up (wifi connected, etc.) The more impatient I got, the more it happened. :)
Yes I experienced the same! Would be nice eventually we find the reason for this happening, but no big deal right now.
shutdown Qubes
@awokd: remove ioctl on qubes device is busy << that line appears multiple times on shutdown of Qubes, that's also normal right? i can remember i read some post somewhere at some stage that explained this, but i forgot.
OK, enjoy your evening!
De : awokd awokd@danwin1210.me À : bruts@netc.fr; mikebdp2@gmail.com Sujet : Re: Lenovo G505s, result111s irqpoll Date : 15/05/2019 21:01:34 Europe/Paris
bruts@netc.fr wrote on 5/15/19 4:29 PM:
@awokd: thanks for your advise, adding irqpoll to kernelopts fixed the usb problem!
When inserting UFD, it appears several times as you can see on the screenshot image (attached), is that normal behavior? It's not resulting in any errors, but just checking with you.
Yes, that's by design.
@mikeb: i booted both laptops with Ubuntu 18.04 and Qubes 4.01 - i will attach a zip file containing the journalctl, there are a few 'errors' that I want to check with you: see notes.log (most errors or warnings are the same, but some differ for both laptops/os).
I took a peek too. The only notes.log I found was under R5 M230/Qubes/notes. Most of them don't seem bad except the ones about the PCI ROM header signature seem to say that GPU isn't getting initialized. It might still be available for passthrough, though? Might not even matter if dom0 can't use it.
Also some behavior I found with Qubes only:
- when laptops are powered off and then booted, a few times after I got the log-in screen for Qubes, the mouse and keyboard stopped responding.
the system was still responsive, but obviously i could not do anything anymore.
@awokd: you had this yourself? it just occurs a few times really, cannot replicate it, just random it seems, but only on a cold boot.
Yes, it seems to manifest most when I use the keyboard and/or mouse while it's still booting up VMs. Basically, I'll put in my user password, then not touch anything until it's all the way up (wifi connected, etc.) The more impatient I got, the more it happened. :)
- only the laptop with the hd8750, when poweroff from a terminal the logoff splash screen of Qubes remains frozen en poweroff does not complete.
also this happens random so far, but quite frequently, i will try to find anything in logs related to that (any suggestions are welcome where to look).
Mike,
So by default if you want to build for HD-8570M, you change in .config:
CONFIG_VGA_BIOS_DGPU_FILE="pci1002,6663.rom" CONFIG_VGA_BIOS_DGPU_ID="1002,6663"
and you simply complete your build (do you at any point need to run "make menuconfig" or is this only a gui for the .config and can be ignored if you make the changes in the .config file?
So if you make a snapshot after applying the patches, you can then change the .config to your preferences and make a build and do that again if you need another build, correct?
You would use the cbfstool only if you make a snapshot after you already built and then want to change the dgpu, correct?
^^ just to clarify things 100% :)
De : Mike Banon mikebdp2@gmail.com À : bruts@netc.fr; awokd awokd@danwin1210.me; coreboot coreboot@coreboot.org Sujet : Re: Lenovo G505s, results irqpoll Date : 16/05/2019 20:25:54 Europe/Paris
is running the cbfstool line mandatory after building the coreboot even if I built for each laptop separately?
Not mandatory. That's only if you would like to make a universal build that could be flashed to both G505S laptops. Now CC'ing to coreboot mailing list...
On Thu, May 16, 2019 at 10:50 AM bruts@netc.fr wrote:
I created a vm to build/patch coreboot, for each build i started clean, then patched with your scripts, however I never manually used cbfstool, I only replaced the atombios during "make menuconfig" (so .config reads either pci1002,6665.rom or pci1002,6663.rom). is running the cbfstool line mandatory after building the coreboot even if I built for each laptop separately? (if not, then maybe i should do a rebuild)
De : Mike Banon mikebdp2@gmail.com À : bruts@netc.fr Sujet : Re: Lenovo G505s, results irqpoll Date : 16/05/2019 06:17:02 Europe/Paris Copie à : awokd awokd@danwin1210.me
Which AtomBIOS you've added to your coreboot? Currently, coreboot's .config can't be set up to include both HD-8570M and R5-M230 roms even with my patch, you could only have there one ROM for integrated iGPU and one ROM for discrete dGPU. If after building the coreboot you don't run
./build/cbfstool $COREBOOT_ROM_PATH add -f $VGABIOS_PATH -n pci****,****.rom -t optionrom
command to add the AtomBIOS for another dGPU as well, your coreboot build will not be fully universal. Although it will make dGPU working on a one type of discrete G505S, it will not be working with the same coreboot ROM on another. So, regarding the difference at your messages:
R5 M230 show: [drm:radeon_get_bios [radeon]] *ERROR* Unable to locate a BIOS ROM
HD 8570M show: [drm:radeon_get_bios [radeon]] *ERROR* ACPI VFCT image header truncated
- maybe the coreboot ROM flashed to your G505S with R5-M230 dGPU,
contains only the AtomBIOS for HD-8570M dGPU, - can't find for R5-M230 and there's such an error. E.g. if you built a coreboot.rom and simply flashed it to both G505S without adding another AtomBIOS.
"*ERROR* ACPI VFCT image header truncated" is not critical and your GPU can work with it, but "*ERROR* Unable to locate a BIOS ROM" is critical.
P.S. Hopefully you could get a public e-mail that's "for coreboot / etc. mailing lists", so that we'll be able to repost this knowledge above to these mailing list archives with your current "brutc@netc.fr" removed everywhere, and also continue discussing freely with your new e-mail
On Wed, May 15, 2019 at 10:31 PM bruts@netc.fr wrote:
Hi there! thanks for your reply.
I took a peek too. The only notes.log I found was under R5
M230/Qubes/notes. Most of them don't seem bad except the ones about the PCI ROM header signature seem to say that GPU isn't getting initialized. It might still be available for passthrough, though? Might not even matter if dom0 can't use it.
sorry, one notes.log was not saved for whatever reason, but the GPU error is also showing when booting Ubuntu, so maybe this is something for Mike to have a look at? you can find notes.log also in Ubuntu folder.
R5 M230 show: [drm:radeon_get_bios [radeon]] *ERROR* Unable to locate a BIOS ROM
HD 8570 show: [drm:radeon_get_bios [radeon]] *ERROR* ACPI VFCT image header truncated
perhaps this error is expected, i don't know.
Yes, it seems to manifest most when I use the keyboard and/or mouse
while it's still booting up VMs. Basically, I'll put in my user password, then not touch anything until it's all the way up (wifi connected, etc.) The more impatient I got, the more it happened. :)
Yes I experienced the same! Would be nice eventually we find the reason for this happening, but no big deal right now.
shutdown Qubes
@awokd: remove ioctl on qubes device is busy << that line appears multiple times on shutdown of Qubes, that's also normal right? i can remember i read some post somewhere at some stage that explained this, but i forgot.
OK, enjoy your evening!
De : awokd awokd@danwin1210.me À : bruts@netc.fr; mikebdp2@gmail.com Sujet : Re: Lenovo G505s, result111s irqpoll Date : 15/05/2019 21:01:34 Europe/Paris
bruts@netc.fr wrote on 5/15/19 4:29 PM:
@awokd: thanks for your advise, adding irqpoll to kernelopts fixed the usb problem!
When inserting UFD, it appears several times as you can see on the screenshot image (attached), is that normal behavior? It's not resulting in any errors, but just checking with you.
Yes, that's by design.
@mikeb: i booted both laptops with Ubuntu 18.04 and Qubes 4.01 - i will attach a zip file containing the journalctl, there are a few 'errors' that I want to check with you: see notes.log (most errors or warnings are the same, but some differ for both laptops/os).
I took a peek too. The only notes.log I found was under R5 M230/Qubes/notes. Most of them don't seem bad except the ones about the PCI ROM header signature seem to say that GPU isn't getting initialized. It might still be available for passthrough, though? Might not even matter if dom0 can't use it.
Also some behavior I found with Qubes only:
- when laptops are powered off and then booted, a few times after I got the log-in screen for Qubes, the mouse and keyboard stopped responding.
the system was still responsive, but obviously i could not do anything anymore.
@awokd: you had this yourself? it just occurs a few times really, cannot replicate it, just random it seems, but only on a cold boot.
Yes, it seems to manifest most when I use the keyboard and/or mouse while it's still booting up VMs. Basically, I'll put in my user password, then not touch anything until it's all the way up (wifi connected, etc.) The more impatient I got, the more it happened. :)
- only the laptop with the hd8750, when poweroff from a terminal the logoff splash screen of Qubes remains frozen en poweroff does not complete.
also this happens random so far, but quite frequently, i will try to find anything in logs related to that (any suggestions are welcome where to look).
So by default if you want to build for HD-8570M, you change in .config (6665 ---> 6663) and you simply complete your build?
Yes, and indeed it could be said that "make menuconfig" is "only a GUI for the .config". If you'd like, you could avoid running it - as long as your manual changes to .config are still compatible with Kconfigs of coreboot source tree (Kconfigs are determining the default values and dependencies of many configuration options) - and if your desired .coreboot configuration is the same as this one which I provided as an example. "6665 ---> 6663" change is very simple - so could be done manually - however for the bigger changes it is more convenient to use a GUI menu, since you may forget about some dependencies and if any of your .config options are in conflict with Kconfigs, these .config options will be reset during a build (there will be a message at the beginning of build but you could skip it accidentally) and there will be a problem. "GUI menu" also helps you to learn more about the coreboot options, you could press a question sign on any of them and get a small useful README.
So if you make a snapshot after applying the patches, you can then change the .config to your preferences and make a build and do that again if you need another build, correct?
Yes, but such a simple switch is possible only if you are building for the same board. If you'd like to build for a different board, you'd also need to run a "make clean" to clean the compiled files, and maybe even "make distclean" if there are any problems. Perhaps it's better to keep the separate coreboot directories for the different boards.
You would use the cbfstool only if you make a snapshot after you already built and then want to change the dgpu, correct?
Not to change the dGPU but rather to add the AtomBIOS for a different one - since the AtomBIOS for another dGPU will still be inside your CBFS (Coreboot ROM's FileSystem), so both dGPUs will be supported - unless you'd remove another AtomBIOS, which is already there, manually (with cbfstool). Also, you could use the cbfstool to add a floppy-based operating system - such as KolibriOS - or simply to print a memory map of your coreboot.rom to see how much of a free space there's left.
Best regards, Mike Banon