coreboot November 2018

coreboot@coreboot.org

71 participants
149 discussions

coreboot's memtest86+ is buggy compared to memtest86+ floppy
by Mike Banon 05 Nov '18

05 Nov '18

coreboot's memtest86+ payload is buggy compared to memtest86+ floppy (which could be downloaded from memtest.org and added to CBFS to be accessible as SeaBIOS menu entry). at AMD Lenovo G505S and maybe some other coreboot laptops, the USB devices like keyboard are not working at coreboot's memtest86+ while working fine at all the other payloads using "libpayload" (i.e. coreinfo or tint) - so it's not a libpayload problem - and also the same USB keyboards are working at memtest86+ floppy. So it is obvious something is broken at 86+ payload source code. Also, with LZMA compression 86+ floppy occupies much less space than 86+ payload. So, aside from academic/research purposes, I do not see any advantages of 86+ payload compared to 86+ floppy - only disadvantages: larger size and troubled USB. I've seriously considered submitting a patch which replaces coreboot's memtest86+ payload with a floppy (download, compare its' checksum and then insert to CBFS), but then I thought that maybe someone could need 86+ payload as a coding example. If you would like to try out a floppy (e.g. because something else - like 2GB support - could be also broken at 86+ payload, while working fine at 86+ floppy booted through SeaBIOS) , here are the instructions: 1) Download the latest 5.01 version of memtest86+ from memtest86.org : wget https://www.memtest.org/download/5.01/memtest86+-5.01.floppy.zip 2) Calculate its' sha256 : sha256sum ./memtest86+-5.01.floppy.zip should be 2a2d4c1234c9130e1da5fea941ccfbaa343739d5b3302b5f3f9b24077868f8ee ./memtest86+-5.01.floppy.zip 3) If sha256 is correct, unzip ./memtest86+-5.01.floppy.zip . You'll get a "floppy" directory with these files: ls ./floppy/ dd.exe install64.bat install.bat memtestp.bin rawrite.exe README.txt You only need memtestp.bin , sha256 of which is " ddd4a2ba44c312aa4f2c7506a388cc2ca7f1caec60c3c6d80ed8a9f0b43d529c " 4) Size of memtestp.bin file is 150024 bytes. To be understood by SeaBIOS, it needs to be expanded to 1474560 bytes (by zeroes), which could be done with this command: dd if=/dev/zero of=./memtestp.bin bs=1 count=1 seek=1474559 conv=notrunc sha256 of expanded memtestp.bin file will be " 364535abd0d105da9396df6015e480c4d4c52b07dcc4e1d4756bde8ef87a30f1 " 5) Now it could be added to the compiled coreboot.rom with this command: ./build/cbfstool ./build/coreboot.rom add -f ./floppy/memtestp.bin -n floppyimg/memtestp.lzma -t raw -c lzma If done everything correctly, it will be available at SeaBIOS boot menu as Ramdisk [memtestp] Best regards, Mike Banon On Mon, Nov 5, 2018 at 3:51 PM Krystian Hebel <krystian.hebel(a)3mdeb.com> wrote: > > > > On 11/05/18 13:32, Paul Menzel wrote: > > > Thank you for the patch. If it’s the common problem, then it was > fixed in “coreboot’s” MemTest86+ [1]. Can you reproduce the problem > with that version? > Yes, it is the version on which I tested. It worked OK before [1], because when no > coreboot tables were found MemTest86+ resorted to e820. > > It was reproduced on PC Engines apu3 (2 GB version) and apu1, the latter requires SPD fix [2]. > 4 GB versions of apu doesn't seem to be affected. > > [1]: https://review.coreboot.org/cgit/memtest86plus.git/commit/?id=0704ab381a7eb… > > [2]: https://review.coreboot.org/c/memtest86plus/+/29372 > > Regards, > > Krystian > > > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > https://mail.coreboot.org/mailman/listinfo/seabios

1 0

Re: [coreboot] Update on G505S (dGPU init success)
by Mike Banon 04 Nov '18

04 Nov '18

Dear HJK, > the problem is that the stock BIOS patches the raw VBIOS/Oprom files during execution - which Coreboot doesn't do > Since CB doesn't patches the VBIOS files, I had to do this manually But these iGPU and dGPU VBIOS/OpROM files for G505S that we are using - available at https://github.com/g505s-opensource-researcher/g505s-atombios repository - have been extracted from the running system with proprietary UEFI/BIOS (as you could see from this repository's readme) which of course have patched them during booting. So these files should have been already patched by it, and I dont understand why this additional patching was needed. Maybe you are using the different VBIOS files - which have been directly extracted from UEFI binary image (probably obtained from this another repository https://github.com/g505s-opensource-researcher/g505s-proprietary/tree/maste… ) - that were not patched? It would be interesting to see your VBIOS files after you would share your ./coreboot/ directory (hopefully they would be inside) to compare them with "g505s-atombios" files > if I'm not mistaken normally Oprom execution should do this, right? Maybe OpROM execution could initialize some of its' own fields during its' execution, but there are data structures which have to be patched by someone else. When we tried to use "clean" VBIOS files ("clean" = directly extracted from UEFI image and therefore not patched by it), the screen's backlight was not working ; then we compared "clean" (from WinVALGC300_unpacked) vs "dirty" (patched, from g505s-atombios) VBIOSes - and there were many differences, including at these data structures: LVDS_Info, sLCDTiming, ucLVDS_Misc, ucLCDPanel_SpecialHandlingCap, PowerPlayInfo, usSpreadSpectrumPercentage . I am attaching "clean" and "dirty" iGPU AtomDis outputs to this email if anyone wants to compare. By the way, what is better - AtomDis or radeon-bios-decode ? > I have multiple variants of APUs, the iGPU pci device ID need to match within VBIOS What other APUs do you have in addition to A10 that are working at coreboot? I've always thought that coreboot is compatible only with A10-5750M G505S. If you would like to make a universal coreboot image that would be compatible not just with A10 but e.g. with A8-5550M also, it might be a good idea to get and include the extra "pci1002,990d.rom" file (A8-5550M GPU 8550G VBIOS) in addition to "pci1002,990b.rom" (for A10-5750M HD 8650G). Although these GPUs could be 100% compatible with each other, in which case you could indeed patch A10 iGPU VBIOS with A8 iGPU IDs and use A10's VBIOS with A8 (maybe it'll even give you some extra performance). To verify its' okay to do, you could extract iGPU VBIOS from A8 G505S running UEFI, and compare it with A10 VBIOS. > The important thing is though to prevent SB from creating the boot entry for the executable Oprom What command are you using to add dGPU OpROMs to coreboot? I think that if you'd be adding it like this: ./util/cbfstool/cbfstool $COREBOOT_ROM_PATH add -f $VGABIOS_PATH -n pci****,****.rom -t optionrom ( -t optionrom is important ) SB will not be creating the boot entry for it, at least SB never created it during my experiments > I used version 0600111F AMD Fam 15h microcode (even though this was later recalled by AMD to n-1 version 06001119) Are you sure 0600111F has been recalled? It has been released only for some proprietary UEFI laptops, and they still have this microcode if my data isn't outdated. So not recalled, just has never been released to the "open source world" for stupid reasons - never pushed to linux-firmware.git / amd-ucode and there's horribly outdated 06001119 from 2012 year Best regards, Mike Banon > On Sun, Nov 4, 2018 at 1:14 PM Hans Jürgen Kitter <hansjurgenj789(a)gmail.com> wrote: > > Hi, > > Here are some additional details, but before I answer I share some preconceptions I had along the way: > - after some initial tries I thought, that the stock BIOS sets up the configuration in a special way for the iGPU and gDPU (PCI adress BARs, IO addresses etc) to get those working therefore, I tried to achieve a very similar setup using CB > - the problem is that the stock BIOS patches the raw VBIOS/Oprom files during execution - which Coreboot doesn't do. (ref: https://www.coreboot.org/Board:lenovo/x60/Installation) > - when I started "hacking" months ago I got similar linux kernel panics like you got when pci bus 02.0 was enabled. I assumed there was a pci allocation problem behind (one additional pci device with big pci resource requirement), also I assumed (maybe wrongly), that pci BAR addresses for the dGPU - and also UMA memory - need to be below the first 4 GB of memory - for the dGPU to work. (details below) > - some of these preconceptions might not need to be considered any more, but so far I haven't made attempts to exclude any of these. By sharing this, I hope more people can help us cleaning the unnecessary stuff... > > On Sat, Nov 3, 2018 at 8:13 PM Mike Banon <mikebdp2(a)gmail.com> wrote: >> >> Dear HJK, >> >> My sincere huge congratulations to you for your incredible >> breakthrough! :-) As you could see from >> http://mail.coreboot.org/pipermail/coreboot/2018-November/087679.html >> - I got stuck after loading both iGPU and dGPU OpROMs at kernel panic >> and thought its' only because of a broken PCI config. But after >> reading your good experience, it seems there were some other problems >> as well which you've successfully solved. Please could you clarify >> some details : >> 1) >> > I modified the IO address & the PCI device ID in APU GPU VBIOS file (even though IO address change to 0x3000 might not required). >> > I modified the IO address in the dGPU VBIOS files to the actual CB - linux kernel provided (0x1000) address >> 1a) Please confirm that you've modified the IO addresses as following: >> APU iGPU (integrated GPU) = 0x3000 >> dGPU (discrete GPU) = 0x1000 >> 1b) Why these exact "IO address" values? How you came up with them, >> and why not any different addresses? >> 1c) At what address offsets (in relation to the beginnings of VBIOS >> files) these "IO address" values are situated? >> 1d) To what value you've changed the PCI device ID in APU iGPU VBIOS, >> and why this change is necessary? > > > When CB boots the iGPU gets IO address 0x3000 and dGPU gets address 0x1000 from the resource allocator. Since CB doesn't patches the VBIOS files, I had to do this manually. Giving it a thought now, this might not be required any more (to mod the VBIOS), because 1. this was not the problem the dGPU didn't init, 2. if I'm not mistaken normally Oprom execution should do this, right? > Offset for IO address for iGPU is @ 0x1A4 (2 bytes), for dGPU @ 0x218. You can use radeon-bios-decode to check the result, and use atomcrc.exe to show the new checksum (@offset 0x21) - to be corrected with hexedit. > I have multiple variants of APUs, the iGPU pci device ID need to match within VBIOS (offset 0x1b8 for pci id (4 bytes)). additional remark: you can also set the subsystem ID @ 0x1a6 (4 bytes). > > >> 2) >> > I had to add my SPI chip driver for EN25QH32=0x7016 to CB >> Why it was needed? My G505S also has this EN25QH32 chip and I never >> had to add any SPI chip drivers - this chip always "just worked" at >> coreboot. If this is indeed required (e.g. for the successful graphics >> initialization), where to get this SPI chip driver and how to add it? > > > This is not required for graphics, but hybernation support needs that CB writes data to the SPI chip. You can see if SPI writes succeed or not in CB console log. I have multiple g505s boards - each with different SPI chips and my EON chip ID was not listed in CB SPI eon.c > >> 3) >> > I enabled pci 00:02.0 for dGPU in devicetree.cb → according to the CB logs this causes pci resource allocation problems >> Do you still have any part of this log, for the reference? I don't >> remember any resource allocation problems in 8 level CB logs > > > Well, this is an interesting topic and I admit, that I don't fully understand all the details, so my phrasing below might not be too "academic"... Moreover, pls. check my preconceptions, and note the fact that pci 02.0 has to be enabled in CB to be able to fill the VFCT for the dGPU. > In the stock BIOS iGPU gets BAR address @0xd0000000. But iGPU UMA size=768M, therefore I assume iGPU also occupies +2x256M UMA memory starting from 0xb0000000. If you check the stock BIOS it is located in the 0x9xxxxxxx range, whereas in CB - depending on the pci resource allocator provided ranges, the AGESA stipulations and the UMA size - from normally end of the 0xb.... range. The problem is that it seems in AGESA Top of low memory (TOM) is always 0xe0000000 (set by the BSP through msr register), this is used by CB to calculate the relative offsets. In a g505s without dGPU pci addres BAR for iGPU is set @ 0xe0000000, and since CB UMA size=512MB, there is room for the 512 MB UMA (below 4GB) starting from 0xc... and the iGPU BAR from 0xe... > When I enabled the dGPU in CB (in another board), pci resource allocator provided pci address 0xd... to the iGPU which causes overlap with UMA memory (512 Mb from 0xc...). I got a black screen (and kernel panic). I "managed" to solve this by decreasing UMA size to 256M and also modified UMA_base to start 256M "lower". This way iGPU UMA memory started from 0xc.. (256MB), iGPU pci address was @0xd.. and dGPU pci address was @ 0xe.. Enabling the dGPU with its own 2GB RAM will potentially circumvent the negative performance effects using a lower iGPU UMA size. > In a recent modificaion, I changed this method: instead of setting UMA_base address starting at a lower address, I modified CB in a way, that when BSP TOM address is "announced" to the other CPUs, I write 0xd0000000 instead of AGESA 0xe0000000 to the msr register. > > There could certainly be better ways to modify the CB code, to consider UMA_size, additional PCI resources and still allocate these memory resources below 4GB. > >> 4) >> > I modified pci_device.c, function pci_dev_init to only enable pci_rom_probe and pci_rom load for the dGPU pci device (no oprom exec needed for PCI_CLASS_DISPLAY_OTHER) >> Why OpROM exec is not needed for dGPU device? And what would happen if >> I will execute it there? (would it break the things, or just no >> difference) > > > My experience shows, that dGPU Oprom execution in itself didn't properly initiated the dGPU, kernel still complained. I had interim attempts, when CB or Seabios executed the dGPU Oprom, without any noticeable init results at those times. The important thing is though to prevent SB from creating the boot entry for the executable Oprom, because this always freezes the laptop at boot list (without any means to debug what has happened). I solved that by modifying SB to run the dGPU oprom using the vgarom_setup function and not the optionrom_setup function. > > Remark: you can disable oprom execution an easy way by changing the 4th byte of the oprom from 0xe9 to 0xcb --> return without initial jump to the exec code. > >> 5) >> > I modified pci_rom.c, so the VBIOS of the dGPU is copied to 0xd0000 from CBFS (..check_initialized..) >> Why this specific 0xd0000 address has been selected? Or it has been >> automatically chosen by coreboot when it wanted to load this OpROM to >> dGPU ? > > > We have two pci vga cards, and the shadow rom by design for non-legacy vga starts at 0xc0000 and is 64K long. 0xd0000 is the non-vga pci option rom shadow area. Interestingly linux kernel allocates 132K starting from 0xc0000 for video shadow, and this could be a reason, why "normal" oprom initialization for vga card1 + vga card2 doesn't work, because vga card 1 claims in linux kernel all 132K for itself, and therefore the second vga card cannot use this overlapping range for its shadowed rom. At least this is something (how I understood) I found when searching for this. This was mentioned in connection with a linux 3.16? kernel issue. > Also note, that SB alligns oproms with 2048 (0x800) address allignment, so when I "played" with oprom init both in CB and in SB I transparently used 4096 (0x1000) allignment in SB. Oproms can only exectue, if its addresses are alligned to at least 0x800 as I remember... > > >> 6) >> > and pci_rom_write_acpi_tables only run for PCI_CLASS_DEVICE_OTHER → dGPU (ACPI VFCT fill is done from the previously prepared 0xd0000=PCI_RAM_IMAGE_START address) >> Why this should be done for dGPU only? (not for APU iGPU or any other devices) >> > So far I haven't succeeded to modify CB ACPI VFCT creator function to povide VFCT tables, that contain both VBIOSes(Oproms) in a way, that the kernel radeon or amdgpu driver can use. The problem is, that I believe one main ACPI-VCFT table need to be created, with two VBIOS contents at different offsets (ref: https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-sou…). Also worth to check the linux kernel sources for ACPI VFCT headers.. > CB ACPI VFCT was not designed to provide that, it runs once when normally pci_class = PCI_CLASS_DEVICE_VGA device is found. For simplicity, I modified this to run oly for PCI_CLASS_DEVICE_OTHER, and it worked, so I haven't gone further. CB initializes iGPU oprom anyways.. > dGPU is only initialized (KMS) when linux kernel loads the radeon/amdgu driver, until that the dGPU is not initialized. > >> 7) I would like to refine your "hacks" and commit them to coreboot, >> while giving a full credit to you of course. But, if I would start >> doing it from scratch according to your instructions, there is always >> a chance that I'd misunderstand or forget something (or you forgot to >> mention some small but important technicality) and as result my >> attempt to reproduce your success could be problematic. It would be >> ideal if you could share: >> A*) your successful coreboot.rom (I'd like to check its' PCI state out >> of curiosity) >> B*) your coreboot's .config file for the reference purposes >> C*) upload your whole coreboot directory to some convenient place, >> either to GitHub or just archive it as .tar.gz (maybe as a multipart >> archive if it ends up too big) and upload it to some hosting website; >> or maybe even create a .torrent out of it and host it temporarily - >> whatever is most convenient to you. > > > OK, I'll see what I can do to submit logs, config files and maybe "cleaned up" patches, of my current working setup. > > BR, > HJK > > >> Hopefully you could share this stuff and I will be able to reproduce >> your results, initially "AS-IS" - but then I will try my best to >> refine it to the acceptable code quality (so that it could be >> officially accepted to coreboot) while checking from time to time if >> it is still working after my gradual changes. Hope to hear any news >> from you soon >> >> Best regards, >> Mike Banon >> On Sat, Nov 3, 2018 at 8:42 PM Hans Jürgen Kitter >> <hansjurgenj789(a)gmail.com> wrote: >> > >> > Hi All, >> > >> > I thought that I share with the G505S+Coreboot (+QubesOS) users that I finally managed to enable and use the dGPUs on the G505S boards. When mentioning boards, I mean, that both variants with its respective VBIOSes: dGPU=1002,6663 (ATI HD 8570M, Sun-Pro) and the dGPU=1002,6665 (ATI R5 M230, Jet-Pro) are working under Ubuntu Linux or Qubes 4.0 (no Windows testing was done or planned). >> > DRI_PRIME=1 seem to work, I use the radeon driver for the APU GPU (A10-5750m) and amdgpu for the dGPU. I'm currently investigating how to get the most out of this setup in Qubes (HW accel 2D in AppVMs). >> > >> > Problem statement: the dGPU was not initiated correctly and was not enabled by the radeon or amdgpu kernel module, VFCT header was corrupt/truncated (effectively was not corrupt, but only VFCT for the APU/iGPU was present). Trying to init the dGPU device through Oprom initialization failed all my attempts (radeon 0000:04:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x0000). This was true whether using Coreboot+GRUB or using Coreboot+Seabios, regardless of kernel version 4.x. >> > >> > Solution in short: Modify Coreboot, that the VFCT table is only created for the dGPU so it can be used by either the radeon or amdgpu KMS driver. >> > >> > Solution in more details: >> > >> > CB 4.8 latest, with SB latest 1.11.2 as payload >> > I modified the IO address & the PCI device ID in APU GPU VBIOS file (even though IO address change to 0x3000 might not required). >> > I modified the IO address in the dGPU VBIOS files to the actual CB - linux kernel provided (0x1000) address >> > both prepared VBIOSes were put into CBFS >> > Coreboot config: std. g505s build, but both run oprom & load oprom was enabled (native mode), also display was set to FB, 1024x768 16.8M color 8:8:8, legacy VGA → this provides console output even if eg. GRUB is the payload). >> > main payload Seabios (compiled as elf separately) >> > I had to add my SPI chip driver for EN25QH32=0x7016 to CB >> > I used version 0600111F AMD Fam 15h microcode (even though this was later recalled by AMD to n-1 version 06001119). Nevertheless, Spectre V2 RSB and IBPB mitigations are thus enabled. >> > I enabled pci 00:02.0 for dGPU in devicetree.cb → according to the CB logs this causes pci resource allocation problems, because the 256M address window of the dGPU conficts with the APU GPU VRAM UMA memory window (originally 512M). Solution (not really professional, but I gave up understanding the whole AGESA and CB PCI allocation mechanism): I decreased the UMA size in buildopts.c to 256M (0x1000) and patched amd_mtrr.c, function setup_bsp_ramtop, to bring TOM down by 256M. So now the APU GPU has an 256M PCI address window @0xd0000000 and the dGPU has also 256M from 0xe0000000 without eventual resource conflict (there's an initial allocation warning for pci:00:01.0 in linux log though). >> > I modified pci_device.c, function pci_dev_init to only enable pci_rom_probe and pci_rom load for the dGPU pci device (no oprom exec needed for PCI_CLASS_DISPLAY_OTHER). >> > I modified pci_rom.c, >> > >> > so the VBIOS of the dGPU is copied to 0xd0000 from CBFS (..check_initialized..) >> > and pci_rom_write_acpi_tables only run for PCI_CLASS_DEVICE_OTHER → dGPU (ACPI VFCT fill is done from the previously prepared 0xd0000=PCI_RAM_IMAGE_START address) >> > >> > Remark1: there could be one ACPI VFCT table containing both VBIOSes present, but the APU GPU VBIOS is fully working via Oprom exec only. >> > Remark2: in the stock v3 bios additional ACPI tables are present (SSDT, DSDT) which contain VGA related methods and descriptions therefore, the VFCT table itself (in EFI mode) is a lot smaller ca. 20K (vs. 65k). These additional ACPI extentions allow eg. the vga_switcheroo to work under Ubuntu in stock BIOS. WIth CB currently only offloading (DRI...) seems to work. And as I checked I will need to understand the whole ACPI concept before I can migrate the relevant ACPI tables from the stock BIOS to CB for the switching to work. Also, it seems, that TurboCore (PowerNow?) is not currently enabled entirely in CB --> also implemented via ACPI tables in stock BIOS. >> > Well, I’m not a coding expert (just a G505S enthusiast), this is the reason I didn’t include patches. My goal was to describe a working solution, and someone with proper coding skills and the possibility to submit official patches for CB can get this committed. >> > >> > BR, >> > HJK >> > -- >> > coreboot mailing list: coreboot(a)coreboot.org >> > https://mail.coreboot.org/mailman/listinfo/coreboot > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Matrix instead (or additionally to) IRC
by Philipp Stanner 04 Nov '18

04 Nov '18

Hey, have you guys already heard of Matrix? https://matrix.org/blog/home/ It's some sort of modern IRC, using JSON to format messages. It's more modern than IRC. Features are: * Source code formatting and highlighting in messages * multiple devices * history + history synchronization between multiple devices * possible E2C encryption and many more. In theory it will be a decentralized protocol, but there aren't that many servers yet and actually only one working server-software Many projects, especially tech-based ones like the Rust programming language already use the service. Personally I think it's an enormous progress to IRC. I would give it a chance if I were you :) P.

3 3

Re: [coreboot] Status Update of F2A85M
by kinky_nekoboi 04 Nov '18

04 Nov '18

i am using Debian Testing with Kernel 4.18. sooo this should not be the problem i guess.. The 2 Mainproblem atm are make the USB2 ports work. fix iommu also it would be nice if there would be nice if they add a working microcode update mechanism Am 3. November 2018 20:02:23 MEZ schrieb Mike Banon <mikebdp2(a)gmail.com>: >Have you tried any Linux distributions other than Debian? Because >Debian's packages and Linux kernel - are relatively ancient, and maybe >the problems you're having - have been fixed in the recent kernel >versions (although they could have broken something else there ;) . >Please try a very modern Linux distribution, like Antergos >(newbie-friendly Arch Linux with GUI), Artix Linux (friendly Arch >without systemd), or maybe a fully updated Void Linux (really clean >and ultra fast Linux, also no systemd). Maybe some of your current >problems wouldn't exist there, it might be a good idea to try ;) >On Sat, Nov 3, 2018 at 2:37 AM Kinky Nekoboi ><kinky_nekoboi(a)bluetardis.de> wrote: >> >> i have tried it, microcode is now updated, but this does not help >with >> linux not wants to boot with iommu enabled >> >> >> Am 02.11.2018 um 21:29 schrieb Mike Banon: >> > For our Richland 15h family AMD CPUs (and for 16h also) , this >> > microcode update procedure - accessible from coreboot's >configuration >> > "menuconfig" menu - is broken, I've observed this 0K problem too. >You >> > should leave this "Include CPU microcode in CBFS" option as "Do not >> > include microcode updates" and just run a script from this wiki - >> > >http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#AMD_microcode_upda… >> > - it will patch the AMD microcodes hardcoded inside .c source code >> > files as the arrays of hex values. After you'll patch your >coreboot, >> > rebuild it and install to your motherboard, your microcode's patch >> > level should change from 0x0600110f to 0x0600111f (0f->1f) >> > >> > Best regards, >> > Mike Banon >> > On Fri, Nov 2, 2018 at 10:51 PM kinky_nekoboi >> > <kinky_nekoboi(a)bluetardis.de> wrote: >> >> I tried only the one included in current master tree. >> >> >> >> But CBFS reports me an 0KB blob as an output ... so that its >mostlikele >> >> the reason it halts after boot (maybe updating an not working >microcode >> >> to the cpu than ?) >> >> >> >> i have microcodes enabled per linux kernel update >> >> dmesg | grep microcode: >> >> [ 3.794585] microcode: CPU0: patch_level=0x0600110f >> >> [ 3.794588] microcode: CPU1: patch_level=0x0600110f >> >> [ 3.794595] microcode: CPU2: patch_level=0x0600110f >> >> [ 3.794602] microcode: CPU3: patch_level=0x0600110f >> >> [ 3.794653] microcode: Microcode Update Driver: v2.2. >> >> >> >> Am 02.11.2018 um 17:12 schrieb Mike Banon: >> >>> Which microcode gives you a brick? Have you tried those new 2018 >> >>> microcodes (not merged yet to coreboot) for 15h generation - >> >>> https://review.coreboot.org/c/coreboot/+/28273 ? If not, here is >a >> >>> quick & secure way to get them - >> >>> >http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#AMD_microcode_upda… >> >>> (although this script is at "Lenovo G505S hacking" page, the same >> >>> microcodes should work for desktop Richland CPUs as well) . By >the >> >>> way, it could help you to get your hardware virtualization >(IOMMU) >> >>> working >> >>> On Fri, Nov 2, 2018 at 7:06 PM kinky_nekoboi >> >>> <kinky_nekoboi(a)bluetardis.de> wrote: >> >>>> Hi Mike, i hope i can help u i am just a User of coreboot and >noo skilled coreboot hacker yet lol. >> >>>> The A10-6800K should work as its the same CPU core/ gen. >> >>>> do not include microcode it makes the rom a brick mode. >> >>>> U have to add a VGA bios if u are using the Internal GPU. >> >>>> i am using a F2A85M rev 1.1 (not pro and not LE, they are quite >rare) >> >>>> >> >>>> Am 2. November 2018 17:01:24 MEZ schrieb Mike Banon ><mikebdp2(a)gmail.com>: >> >>>>> Nice report. Do you think A10-6800K CPU would have worked at >this >> >>>>> motherboard? Or only A8-6600K is supported? Also, what hardware >> >>>>> revision of this motherboard do you have? (there were F2A85M / >--//-- >> >>>>> PRO and some other revisions, so I'm a bit confused) . I am >seriously >> >>>>> considering doing a similar build, but would like to get the >fastest >> >>>>> available CPU you could install there >> >>>>> On Fri, Nov 2, 2018 at 4:29 AM kinky_nekoboi >> >>>>> <kinky_nekoboi(a)bluetardis.de> wrote: >> >>>>>> something like that happens if u connect anything to a USB2 >Port >> >>>>>> >> >>>>>> [ 2600.001601] usb 7-1: new full-speed USB device number 3 >using ohci-pci >> >>>>>> [ 2600.001612] ohci-pci 0000:00:12.0: dma_direct_map_page: >overflow 0x00000001c52c2ea8+8 of device mask ffffffff >> >>>>>> [ 2600.001619] ohci-pci 0000:00:12.0: dma_direct_map_page: >overflow 0x00000001c52c2ea8+8 of device mask ffffffff >> >>>>>> [ 2600.001624] ohci-pci 0000:00:12.0: dma_direct_map_page: >overflow 0x00000001c52c2ea8+8 of device mask ffffffff >> >>>>>> [ 2600.185864] usb 7-1: device descriptor read/64, error -11 >> >>>>>> [ 2600.293659] ohci-pci 0000:00:12.0: dma_direct_map_page: >overflow 0x00000001c52c2ea8+8 of device mask ffffffff >> >>>>>> [ 2600.293669] ohci-pci 0000:00:12.0: dma_direct_map_page: >overflow 0x00000001c52c2ea8+8 of device mask ffffffff >> >>>>>> [ 2600.293674] ohci-pci 0000:00:12.0: dma_direct_map_page: >overflow 0x00000001c52c2ea8+8 of device mask ffffffff >> >>>>>> [ 2600.477668] usb 7-1: device descriptor read/64, error -11 >> >>>>>> [ 2600.585647] usb usb7-port1: attempt power cycle >> >>>>>> [ 2601.090486] usb 7-1: new full-speed USB device number 4 >using ohci-pci >> >>>>>> [ 2601.090494] ohci-pci 0000:00:12.0: dma_direct_map_page: >overflow 0x00000001c52c2ea8+8 of device mask ffffffff >> >>>>>> [ 2601.301659] ohci-pci 0000:00:12.0: dma_direct_map_page: >overflow 0x00000001c52c2ea8+8 of device mask ffffffff >> >>>>>> [ 2601.509672] usb 7-1: device not accepting address 4, error >-11 >> >>>>>> [ 2601.693678] usb 7-1: new full-speed USB device number 5 >using ohci-pci >> >>>>>> [ 2601.693693] ohci-pci 0000:00:12.0: dma_direct_map_page: >overflow 0x00000001c52c2ea8+8 of device mask ffffffff >> >>>>>> [ 2601.901677] ohci-pci 0000:00:12.0: dma_direct_map_page: >overflow 0x00000001c52c2ea8+8 of device mask ffffffff >> >>>>>> [ 2602.109672] usb 7-1: device not accepting address 5, error >-11 >> >>>>>> [ 2602.109723] usb usb7-port1: unable to enumerate USB device >> >>>>>> >> >>>>>> >> >>>>>> Am 02.11.2018 um 02:01 schrieb kinky_nekoboi: >> >>>>>> >> >>>>>> heeey >> >>>>>> >> >>>>>> i am very happy that i have coreboot running now on my >desktop machine... >> >>>>>> >> >>>>>> ADDON-GPU card works now >> >>>>>> >> >>>>>> Nvramcui works >> >>>>>> >> >>>>>> Optionrom execution works. >> >>>>>> >> >>>>>> IOMMU does not work .. debian has to boot with iommu=off. >> >>>>>> >> >>>>>> but KVM virtualsation works somehow. >> >>>>>> >> >>>>>> Suspend does not work. >> >>>>>> >> >>>>>> USB is still extremely buggy ... only the USB3 Ports are >useable. >> >>>>>> >> >>>>>> >> >>>>>> here some output >> >>>>>> >> >>>>>> Architektur: x86_64 >> >>>>>> CPU Operationsmodus: 32-bit, 64-bit >> >>>>>> Byte-Reihenfolge: Little Endian >> >>>>>> CPU(s): 4 >> >>>>>> Liste der Online-CPU(s): 0-3 >> >>>>>> Thread(s) pro Kern: 2 >> >>>>>> Kern(e) pro Socket: 2 >> >>>>>> Sockel: 1 >> >>>>>> NUMA-Knoten: 1 >> >>>>>> Anbieterkennung: AuthenticAMD >> >>>>>> Prozessorfamilie: 21 >> >>>>>> Modell: 19 >> >>>>>> Modellname: AMD A8-6600K APU with >Radeon(tm) HD Graphics >> >>>>>> Stepping: 1 >> >>>>>> CPU MHz: 2068.754 >> >>>>>> Maximale Taktfrequenz der CPU: 3900,0000 >> >>>>>> Minimale Taktfrequenz der CPU: 1900,0000 >> >>>>>> BogoMIPS: 7786.16 >> >>>>>> Virtualisierung: AMD-V >> >>>>>> L1d Cache: 16K >> >>>>>> L1i Cache: 64K >> >>>>>> L2 Cache: 2048K >> >>>>>> NUMA-Knoten0 CPU(s): 0-3 >> >>>>>> Markierungen: fpu vme de pse tsc msr pae mce >cx8 apic >> >>>>>> sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht >syscall nx >> >>>>>> mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl >nonstop_tsc >> >>>>>> cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma >cx16 sse4_1 >> >>>>>> sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm >extapic >> >>>>>> cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop >skinit wdt >> >>>>>> lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb >cpb >> >>>>>> hw_pstate ssbd vmmcall bmi1 arat npt lbrv svm_lock nrip_save >tsc_scale >> >>>>>> vmcb_clean flushbyasid decodeassists pausefilter pfthreshold >> >>>>>> >> >>>>>> >> >>>>>> 23 entries total: >> >>>>>> >> >>>>>> 0:1st timestamp 13,116 >> >>>>>> 1:start of romstage 13,477 >(361) >> >>>>>> 2:before ram initialization 75,515 >(62,038) >> >>>>>> 3:after ram initialization >1,308,025 (1,232,510) >> >>>>>> 4:end of romstage >1,319,893 (11,867) >> >>>>>> 8:starting to load ramstage >1,319,966 (73) >> >>>>>> 15:starting LZMA decompress (ignore for x86) >1,319,984 (18) >> >>>>>> 16:finished LZMA decompress (ignore for x86) >1,370,088 (50,103) >> >>>>>> 9:finished loading ramstage >1,370,357 (269) >> >>>>>> 10:start of ramstage >1,371,078 (720) >> >>>>>> 30:device enumeration >1,461,571 (90,493) >> >>>>>> 40:device configuration >1,470,758 (9,186) >> >>>>>> 50:device enable >1,501,692 (30,933) >> >>>>>> 60:device initialization >1,569,453 (67,761) >> >>>>>> 65:Option ROM initialization >1,769,162 (199,708) >> >>>>>> 65:Option ROM initialization >1,936,860 (167,697) >> >>>>>> 70:device setup done >2,011,094 (74,234) >> >>>>>> 75:cbmem post >2,366,967 (355,873) >> >>>>>> 80:write tables >2,371,915 (4,947) >> >>>>>> 85:finalize chips >2,750,289 (378,374) >> >>>>>> 90:load payload >2,755,411 (5,122) >> >>>>>> 15:starting LZMA decompress (ignore for x86) >2,797,472 (42,060) >> >>>>>> 16:finished LZMA decompress (ignore for x86) >2,823,100 (25,628) >> >>>>>> 99:selfboot jump >2,838,148 (15,048) >> >>>>>> >> >>>>>> Total Time: 2,825,023 >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> coreboot mailing list: coreboot(a)coreboot.org >> >>>>>> https://mail.coreboot.org/mailman/listinfo/coreboot >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot > >-- >coreboot mailing list: coreboot(a)coreboot.org >https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Update on G505S (dGPU init success)
by Hans Jürgen Kitter 04 Nov '18

04 Nov '18

Hi, Here are some additional details, but before I answer I share some preconceptions I had along the way: - after some initial tries I thought, that the stock BIOS sets up the configuration in a special way for the iGPU and gDPU (PCI adress BARs, IO addresses etc) to get those working therefore, I tried to achieve a very similar setup using CB - the problem is that the stock BIOS patches the raw VBIOS/Oprom files during execution - which Coreboot doesn't do. (ref: https://www.coreboot.org/Board:lenovo/x60/Installation) - when I started "hacking" months ago I got similar linux kernel panics like you got when pci bus 02.0 was enabled. I assumed there was a pci allocation problem behind (one additional pci device with big pci resource requirement), also I assumed (maybe wrongly), that pci BAR addresses for the dGPU - and also UMA memory - need to be below the first 4 GB of memory - for the dGPU to work. (details below) - some of these preconceptions might not need to be considered any more, but so far I haven't made attempts to exclude any of these. By sharing this, I hope more people can help us cleaning the unnecessary stuff... On Sat, Nov 3, 2018 at 8:13 PM Mike Banon <mikebdp2(a)gmail.com> wrote: > Dear HJK, > > My sincere huge congratulations to you for your incredible > breakthrough! :-) As you could see from > http://mail.coreboot.org/pipermail/coreboot/2018-November/087679.html > - I got stuck after loading both iGPU and dGPU OpROMs at kernel panic > and thought its' only because of a broken PCI config. But after > reading your good experience, it seems there were some other problems > as well which you've successfully solved. Please could you clarify > some details : > 1) > > I modified the IO address & the PCI device ID in APU GPU VBIOS file > (even though IO address change to 0x3000 might not required). > > I modified the IO address in the dGPU VBIOS files to the actual CB - > linux kernel provided (0x1000) address > 1a) Please confirm that you've modified the IO addresses as following: > APU iGPU (integrated GPU) = 0x3000 > dGPU (discrete GPU) = 0x1000 > 1b) Why these exact "IO address" values? How you came up with them, > and why not any different addresses? > 1c) At what address offsets (in relation to the beginnings of VBIOS > files) these "IO address" values are situated? > 1d) To what value you've changed the PCI device ID in APU iGPU VBIOS, > and why this change is necessary? > When CB boots the iGPU gets IO address 0x3000 and dGPU gets address 0x1000 from the resource allocator. Since CB doesn't patches the VBIOS files, I had to do this manually. Giving it a thought now, this might not be required any more (to mod the VBIOS), because 1. this was not the problem the dGPU didn't init, 2. if I'm not mistaken normally Oprom execution should do this, right? Offset for IO address for iGPU is @ 0x1A4 (2 bytes), for dGPU @ 0x218. You can use radeon-bios-decode to check the result, and use atomcrc.exe to show the new checksum (@offset 0x21) - to be corrected with hexedit. I have multiple variants of APUs, the iGPU pci device ID need to match within VBIOS (offset 0x1b8 for pci id (4 bytes)). additional remark: you can also set the subsystem ID @ 0x1a6 (4 bytes). 2) > > I had to add my SPI chip driver for EN25QH32=0x7016 to CB > Why it was needed? My G505S also has this EN25QH32 chip and I never > had to add any SPI chip drivers - this chip always "just worked" at > coreboot. If this is indeed required (e.g. for the successful graphics > initialization), where to get this SPI chip driver and how to add it? > This is not required for graphics, but hybernation support needs that CB writes data to the SPI chip. You can see if SPI writes succeed or not in CB console log. I have multiple g505s boards - each with different SPI chips and my EON chip ID was not listed in CB SPI eon.c 3) > > I enabled pci 00:02.0 for dGPU in devicetree.cb → according to the CB > logs this causes pci resource allocation problems > Do you still have any part of this log, for the reference? I don't > remember any resource allocation problems in 8 level CB logs > Well, this is an interesting topic and I admit, that I don't fully understand all the details, so my phrasing below might not be too "academic"... Moreover, pls. check my preconceptions, and note the fact that pci 02.0 has to be enabled in CB to be able to fill the VFCT for the dGPU. In the stock BIOS iGPU gets BAR address @0xd0000000. But iGPU UMA size=768M, therefore I assume iGPU also occupies +2x256M UMA memory starting from 0xb0000000. If you check the stock BIOS it is located in the 0x9xxxxxxx range, whereas in CB - depending on the pci resource allocator provided ranges, the AGESA stipulations and the UMA size - from normally end of the 0xb.... range. The problem is that it seems in AGESA Top of low memory (TOM) is always 0xe0000000 (set by the BSP through msr register), this is used by CB to calculate the relative offsets. In a g505s without dGPU pci addres BAR for iGPU is set @ 0xe0000000, and since CB UMA size=512MB, there is room for the 512 MB UMA (below 4GB) starting from 0xc... and the iGPU BAR from 0xe... When I enabled the dGPU in CB (in another board), pci resource allocator provided pci address 0xd... to the iGPU which causes overlap with UMA memory (512 Mb from 0xc...). I got a black screen (and kernel panic). I "managed" to solve this by decreasing UMA size to 256M and also modified UMA_base to start 256M "lower". This way iGPU UMA memory started from 0xc.. (256MB), iGPU pci address was @0xd.. and dGPU pci address was @ 0xe.. Enabling the dGPU with its own 2GB RAM will potentially circumvent the negative performance effects using a lower iGPU UMA size. In a recent modificaion, I changed this method: instead of setting UMA_base address starting at a lower address, I modified CB in a way, that when BSP TOM address is "announced" to the other CPUs, I write 0xd0000000 instead of AGESA 0xe0000000 to the msr register. There could certainly be better ways to modify the CB code, to consider UMA_size, additional PCI resources and still allocate these memory resources below 4GB. 4) > > I modified pci_device.c, function pci_dev_init to only enable > pci_rom_probe and pci_rom load for the dGPU pci device (no oprom exec > needed for PCI_CLASS_DISPLAY_OTHER) > Why OpROM exec is not needed for dGPU device? And what would happen if > I will execute it there? (would it break the things, or just no > difference) > My experience shows, that dGPU Oprom execution in itself didn't properly initiated the dGPU, kernel still complained. I had interim attempts, when CB or Seabios executed the dGPU Oprom, without any noticeable init results at those times. The important thing is though to prevent SB from creating the boot entry for the executable Oprom, because this always freezes the laptop at boot list (without any means to debug what has happened). I solved that by modifying SB to run the dGPU oprom using the vgarom_setup function and not the optionrom_setup function. Remark: you can disable oprom execution an easy way by changing the 4th byte of the oprom from 0xe9 to 0xcb --> return without initial jump to the exec code. 5) > > I modified pci_rom.c, so the VBIOS of the dGPU is copied to 0xd0000 from > CBFS (..check_initialized..) > Why this specific 0xd0000 address has been selected? Or it has been > automatically chosen by coreboot when it wanted to load this OpROM to > dGPU ? > We have two pci vga cards, and the shadow rom by design for non-legacy vga starts at 0xc0000 and is 64K long. 0xd0000 is the non-vga pci option rom shadow area. Interestingly linux kernel allocates 132K starting from 0xc0000 for video shadow, and this could be a reason, why "normal" oprom initialization for vga card1 + vga card2 doesn't work, because vga card 1 claims in linux kernel all 132K for itself, and therefore the second vga card cannot use this overlapping range for its shadowed rom. At least this is something (how I understood) I found when searching for this. This was mentioned in connection with a linux 3.16? kernel issue. Also note, that SB alligns oproms with 2048 (0x800) address allignment, so when I "played" with oprom init both in CB and in SB I transparently used 4096 (0x1000) allignment in SB. Oproms can only exectue, if its addresses are alligned to at least 0x800 as I remember... 6) > > and pci_rom_write_acpi_tables only run for PCI_CLASS_DEVICE_OTHER → dGPU > (ACPI VFCT fill is done from the previously prepared > 0xd0000=PCI_RAM_IMAGE_START address) > Why this should be done for dGPU only? (not for APU iGPU or any other > devices) > > So far I haven't succeeded to modify CB ACPI VFCT creator function to povide VFCT tables, that contain both VBIOSes(Oproms) in a way, that the kernel radeon or amdgpu driver can use. The problem is, that I believe one main ACPI-VCFT table need to be created, with two VBIOS contents at different offsets (ref: https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-sou…). Also worth to check the linux kernel sources for ACPI VFCT headers.. CB ACPI VFCT was not designed to provide that, it runs once when normally pci_class = PCI_CLASS_DEVICE_VGA device is found. For simplicity, I modified this to run oly for PCI_CLASS_DEVICE_OTHER, and it worked, so I haven't gone further. CB initializes iGPU oprom anyways.. dGPU is only initialized (KMS) when linux kernel loads the radeon/amdgu driver, until that the dGPU is not initialized. 7) I would like to refine your "hacks" and commit them to coreboot, > while giving a full credit to you of course. But, if I would start > doing it from scratch according to your instructions, there is always > a chance that I'd misunderstand or forget something (or you forgot to > mention some small but important technicality) and as result my > attempt to reproduce your success could be problematic. It would be > ideal if you could share: > A*) your successful coreboot.rom (I'd like to check its' PCI state out > of curiosity) > B*) your coreboot's .config file for the reference purposes > C*) upload your whole coreboot directory to some convenient place, > either to GitHub or just archive it as .tar.gz (maybe as a multipart > archive if it ends up too big) and upload it to some hosting website; > or maybe even create a .torrent out of it and host it temporarily - > whatever is most convenient to you. OK, I'll see what I can do to submit logs, config files and maybe "cleaned up" patches, of my current working setup. BR, HJK Hopefully you could share this stuff and I will be able to reproduce > your results, initially "AS-IS" - but then I will try my best to > refine it to the acceptable code quality (so that it could be > officially accepted to coreboot) while checking from time to time if > it is still working after my gradual changes. Hope to hear any news > from you soon > > Best regards, > Mike Banon > On Sat, Nov 3, 2018 at 8:42 PM Hans Jürgen Kitter > <hansjurgenj789(a)gmail.com> wrote: > > > > Hi All, > > > > I thought that I share with the G505S+Coreboot (+QubesOS) users that I > finally managed to enable and use the dGPUs on the G505S boards. When > mentioning boards, I mean, that both variants with its respective VBIOSes: > dGPU=1002,6663 (ATI HD 8570M, Sun-Pro) and the dGPU=1002,6665 (ATI R5 M230, > Jet-Pro) are working under Ubuntu Linux or Qubes 4.0 (no Windows testing > was done or planned). > > DRI_PRIME=1 seem to work, I use the radeon driver for the APU GPU > (A10-5750m) and amdgpu for the dGPU. I'm currently investigating how to get > the most out of this setup in Qubes (HW accel 2D in AppVMs). > > > > Problem statement: the dGPU was not initiated correctly and was not > enabled by the radeon or amdgpu kernel module, VFCT header was > corrupt/truncated (effectively was not corrupt, but only VFCT for the > APU/iGPU was present). Trying to init the dGPU device through Oprom > initialization failed all my attempts (radeon 0000:04:00.0: Invalid PCI ROM > header signature: expecting 0xaa55, got 0x0000). This was true whether > using Coreboot+GRUB or using Coreboot+Seabios, regardless of kernel version > 4.x. > > > > Solution in short: Modify Coreboot, that the VFCT table is only created > for the dGPU so it can be used by either the radeon or amdgpu KMS driver. > > > > Solution in more details: > > > > CB 4.8 latest, with SB latest 1.11.2 as payload > > I modified the IO address & the PCI device ID in APU GPU VBIOS file > (even though IO address change to 0x3000 might not required). > > I modified the IO address in the dGPU VBIOS files to the actual CB - > linux kernel provided (0x1000) address > > both prepared VBIOSes were put into CBFS > > Coreboot config: std. g505s build, but both run oprom & load oprom was > enabled (native mode), also display was set to FB, 1024x768 16.8M color > 8:8:8, legacy VGA → this provides console output even if eg. GRUB is the > payload). > > main payload Seabios (compiled as elf separately) > > I had to add my SPI chip driver for EN25QH32=0x7016 to CB > > I used version 0600111F AMD Fam 15h microcode (even though this was > later recalled by AMD to n-1 version 06001119). Nevertheless, Spectre V2 > RSB and IBPB mitigations are thus enabled. > > I enabled pci 00:02.0 for dGPU in devicetree.cb → according to the CB > logs this causes pci resource allocation problems, because the 256M address > window of the dGPU conficts with the APU GPU VRAM UMA memory window > (originally 512M). Solution (not really professional, but I gave up > understanding the whole AGESA and CB PCI allocation mechanism): I decreased > the UMA size in buildopts.c to 256M (0x1000) and patched amd_mtrr.c, > function setup_bsp_ramtop, to bring TOM down by 256M. So now the APU GPU > has an 256M PCI address window @0xd0000000 and the dGPU has also 256M from > 0xe0000000 without eventual resource conflict (there's an initial > allocation warning for pci:00:01.0 in linux log though). > > I modified pci_device.c, function pci_dev_init to only enable > pci_rom_probe and pci_rom load for the dGPU pci device (no oprom exec > needed for PCI_CLASS_DISPLAY_OTHER). > > I modified pci_rom.c, > > > > so the VBIOS of the dGPU is copied to 0xd0000 from CBFS > (..check_initialized..) > > and pci_rom_write_acpi_tables only run for PCI_CLASS_DEVICE_OTHER → dGPU > (ACPI VFCT fill is done from the previously prepared > 0xd0000=PCI_RAM_IMAGE_START address) > > > > Remark1: there could be one ACPI VFCT table containing both VBIOSes > present, but the APU GPU VBIOS is fully working via Oprom exec only. > > Remark2: in the stock v3 bios additional ACPI tables are present (SSDT, > DSDT) which contain VGA related methods and descriptions therefore, the > VFCT table itself (in EFI mode) is a lot smaller ca. 20K (vs. 65k). These > additional ACPI extentions allow eg. the vga_switcheroo to work under > Ubuntu in stock BIOS. WIth CB currently only offloading (DRI...) seems to > work. And as I checked I will need to understand the whole ACPI concept > before I can migrate the relevant ACPI tables from the stock BIOS to CB for > the switching to work. Also, it seems, that TurboCore (PowerNow?) is not > currently enabled entirely in CB --> also implemented via ACPI tables in > stock BIOS. > > Well, I’m not a coding expert (just a G505S enthusiast), this is the > reason I didn’t include patches. My goal was to describe a working > solution, and someone with proper coding skills and the possibility to > submit official patches for CB can get this committed. > > > > BR, > > HJK > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Update on G505S (dGPU init success)
by Mike Banon 03 Nov '18

03 Nov '18

Dear HJK, My sincere huge congratulations to you for your incredible breakthrough! :-) As you could see from http://mail.coreboot.org/pipermail/coreboot/2018-November/087679.html - I got stuck after loading both iGPU and dGPU OpROMs at kernel panic and thought its' only because of a broken PCI config. But after reading your good experience, it seems there were some other problems as well which you've successfully solved. Please could you clarify some details : 1) > I modified the IO address & the PCI device ID in APU GPU VBIOS file (even though IO address change to 0x3000 might not required). > I modified the IO address in the dGPU VBIOS files to the actual CB - linux kernel provided (0x1000) address 1a) Please confirm that you've modified the IO addresses as following: APU iGPU (integrated GPU) = 0x3000 dGPU (discrete GPU) = 0x1000 1b) Why these exact "IO address" values? How you came up with them, and why not any different addresses? 1c) At what address offsets (in relation to the beginnings of VBIOS files) these "IO address" values are situated? 1d) To what value you've changed the PCI device ID in APU iGPU VBIOS, and why this change is necessary? 2) > I had to add my SPI chip driver for EN25QH32=0x7016 to CB Why it was needed? My G505S also has this EN25QH32 chip and I never had to add any SPI chip drivers - this chip always "just worked" at coreboot. If this is indeed required (e.g. for the successful graphics initialization), where to get this SPI chip driver and how to add it? 3) > I enabled pci 00:02.0 for dGPU in devicetree.cb → according to the CB logs this causes pci resource allocation problems Do you still have any part of this log, for the reference? I don't remember any resource allocation problems in 8 level CB logs 4) > I modified pci_device.c, function pci_dev_init to only enable pci_rom_probe and pci_rom load for the dGPU pci device (no oprom exec needed for PCI_CLASS_DISPLAY_OTHER) Why OpROM exec is not needed for dGPU device? And what would happen if I will execute it there? (would it break the things, or just no difference) 5) > I modified pci_rom.c, so the VBIOS of the dGPU is copied to 0xd0000 from CBFS (..check_initialized..) Why this specific 0xd0000 address has been selected? Or it has been automatically chosen by coreboot when it wanted to load this OpROM to dGPU ? 6) > and pci_rom_write_acpi_tables only run for PCI_CLASS_DEVICE_OTHER → dGPU (ACPI VFCT fill is done from the previously prepared 0xd0000=PCI_RAM_IMAGE_START address) Why this should be done for dGPU only? (not for APU iGPU or any other devices) 7) I would like to refine your "hacks" and commit them to coreboot, while giving a full credit to you of course. But, if I would start doing it from scratch according to your instructions, there is always a chance that I'd misunderstand or forget something (or you forgot to mention some small but important technicality) and as result my attempt to reproduce your success could be problematic. It would be ideal if you could share: A*) your successful coreboot.rom (I'd like to check its' PCI state out of curiosity) B*) your coreboot's .config file for the reference purposes C*) upload your whole coreboot directory to some convenient place, either to GitHub or just archive it as .tar.gz (maybe as a multipart archive if it ends up too big) and upload it to some hosting website; or maybe even create a .torrent out of it and host it temporarily - whatever is most convenient to you. Hopefully you could share this stuff and I will be able to reproduce your results, initially "AS-IS" - but then I will try my best to refine it to the acceptable code quality (so that it could be officially accepted to coreboot) while checking from time to time if it is still working after my gradual changes. Hope to hear any news from you soon Best regards, Mike Banon On Sat, Nov 3, 2018 at 8:42 PM Hans Jürgen Kitter <hansjurgenj789(a)gmail.com> wrote: > > Hi All, > > I thought that I share with the G505S+Coreboot (+QubesOS) users that I finally managed to enable and use the dGPUs on the G505S boards. When mentioning boards, I mean, that both variants with its respective VBIOSes: dGPU=1002,6663 (ATI HD 8570M, Sun-Pro) and the dGPU=1002,6665 (ATI R5 M230, Jet-Pro) are working under Ubuntu Linux or Qubes 4.0 (no Windows testing was done or planned). > DRI_PRIME=1 seem to work, I use the radeon driver for the APU GPU (A10-5750m) and amdgpu for the dGPU. I'm currently investigating how to get the most out of this setup in Qubes (HW accel 2D in AppVMs). > > Problem statement: the dGPU was not initiated correctly and was not enabled by the radeon or amdgpu kernel module, VFCT header was corrupt/truncated (effectively was not corrupt, but only VFCT for the APU/iGPU was present). Trying to init the dGPU device through Oprom initialization failed all my attempts (radeon 0000:04:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x0000). This was true whether using Coreboot+GRUB or using Coreboot+Seabios, regardless of kernel version 4.x. > > Solution in short: Modify Coreboot, that the VFCT table is only created for the dGPU so it can be used by either the radeon or amdgpu KMS driver. > > Solution in more details: > > CB 4.8 latest, with SB latest 1.11.2 as payload > I modified the IO address & the PCI device ID in APU GPU VBIOS file (even though IO address change to 0x3000 might not required). > I modified the IO address in the dGPU VBIOS files to the actual CB - linux kernel provided (0x1000) address > both prepared VBIOSes were put into CBFS > Coreboot config: std. g505s build, but both run oprom & load oprom was enabled (native mode), also display was set to FB, 1024x768 16.8M color 8:8:8, legacy VGA → this provides console output even if eg. GRUB is the payload). > main payload Seabios (compiled as elf separately) > I had to add my SPI chip driver for EN25QH32=0x7016 to CB > I used version 0600111F AMD Fam 15h microcode (even though this was later recalled by AMD to n-1 version 06001119). Nevertheless, Spectre V2 RSB and IBPB mitigations are thus enabled. > I enabled pci 00:02.0 for dGPU in devicetree.cb → according to the CB logs this causes pci resource allocation problems, because the 256M address window of the dGPU conficts with the APU GPU VRAM UMA memory window (originally 512M). Solution (not really professional, but I gave up understanding the whole AGESA and CB PCI allocation mechanism): I decreased the UMA size in buildopts.c to 256M (0x1000) and patched amd_mtrr.c, function setup_bsp_ramtop, to bring TOM down by 256M. So now the APU GPU has an 256M PCI address window @0xd0000000 and the dGPU has also 256M from 0xe0000000 without eventual resource conflict (there's an initial allocation warning for pci:00:01.0 in linux log though). > I modified pci_device.c, function pci_dev_init to only enable pci_rom_probe and pci_rom load for the dGPU pci device (no oprom exec needed for PCI_CLASS_DISPLAY_OTHER). > I modified pci_rom.c, > > so the VBIOS of the dGPU is copied to 0xd0000 from CBFS (..check_initialized..) > and pci_rom_write_acpi_tables only run for PCI_CLASS_DEVICE_OTHER → dGPU (ACPI VFCT fill is done from the previously prepared 0xd0000=PCI_RAM_IMAGE_START address) > > Remark1: there could be one ACPI VFCT table containing both VBIOSes present, but the APU GPU VBIOS is fully working via Oprom exec only. > Remark2: in the stock v3 bios additional ACPI tables are present (SSDT, DSDT) which contain VGA related methods and descriptions therefore, the VFCT table itself (in EFI mode) is a lot smaller ca. 20K (vs. 65k). These additional ACPI extentions allow eg. the vga_switcheroo to work under Ubuntu in stock BIOS. WIth CB currently only offloading (DRI...) seems to work. And as I checked I will need to understand the whole ACPI concept before I can migrate the relevant ACPI tables from the stock BIOS to CB for the switching to work. Also, it seems, that TurboCore (PowerNow?) is not currently enabled entirely in CB --> also implemented via ACPI tables in stock BIOS. > Well, I’m not a coding expert (just a G505S enthusiast), this is the reason I didn’t include patches. My goal was to describe a working solution, and someone with proper coding skills and the possibility to submit official patches for CB can get this committed. > > BR, > HJK > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Update on G505S (dGPU init success)
by awokd 03 Nov '18

03 Nov '18

Hans Jürgen Kitter: > Hi All, > > I thought that I share with the G505S+Coreboot (+QubesOS) users that I > finally managed to enable and use the dGPUs on the G505S boards. Nice hacking! I know Mike Banon was working with some others on this too, hopefully you were able to compare notes. Any benefits to G505s owners who don't have the secondary GPU?

1 0

Re: [coreboot] Status Update of F2A85M
by Kinky Nekoboi 03 Nov '18

03 Nov '18

i have tried it, microcode is now updated, but this does not help with linux not wants to boot with iommu enabled Am 02.11.2018 um 21:29 schrieb Mike Banon: > For our Richland 15h family AMD CPUs (and for 16h also) , this > microcode update procedure - accessible from coreboot's configuration > "menuconfig" menu - is broken, I've observed this 0K problem too. You > should leave this "Include CPU microcode in CBFS" option as "Do not > include microcode updates" and just run a script from this wiki - > http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#AMD_microcode_upda… > - it will patch the AMD microcodes hardcoded inside .c source code > files as the arrays of hex values. After you'll patch your coreboot, > rebuild it and install to your motherboard, your microcode's patch > level should change from 0x0600110f to 0x0600111f (0f->1f) > > Best regards, > Mike Banon > On Fri, Nov 2, 2018 at 10:51 PM kinky_nekoboi > <kinky_nekoboi(a)bluetardis.de> wrote: >> I tried only the one included in current master tree. >> >> But CBFS reports me an 0KB blob as an output ... so that its mostlikele >> the reason it halts after boot (maybe updating an not working microcode >> to the cpu than ?) >> >> i have microcodes enabled per linux kernel update >> dmesg | grep microcode: >> [ 3.794585] microcode: CPU0: patch_level=0x0600110f >> [ 3.794588] microcode: CPU1: patch_level=0x0600110f >> [ 3.794595] microcode: CPU2: patch_level=0x0600110f >> [ 3.794602] microcode: CPU3: patch_level=0x0600110f >> [ 3.794653] microcode: Microcode Update Driver: v2.2. >> >> Am 02.11.2018 um 17:12 schrieb Mike Banon: >>> Which microcode gives you a brick? Have you tried those new 2018 >>> microcodes (not merged yet to coreboot) for 15h generation - >>> https://review.coreboot.org/c/coreboot/+/28273 ? If not, here is a >>> quick & secure way to get them - >>> http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#AMD_microcode_upda… >>> (although this script is at "Lenovo G505S hacking" page, the same >>> microcodes should work for desktop Richland CPUs as well) . By the >>> way, it could help you to get your hardware virtualization (IOMMU) >>> working >>> On Fri, Nov 2, 2018 at 7:06 PM kinky_nekoboi >>> <kinky_nekoboi(a)bluetardis.de> wrote: >>>> Hi Mike, i hope i can help u i am just a User of coreboot and noo skilled coreboot hacker yet lol. >>>> The A10-6800K should work as its the same CPU core/ gen. >>>> do not include microcode it makes the rom a brick mode. >>>> U have to add a VGA bios if u are using the Internal GPU. >>>> i am using a F2A85M rev 1.1 (not pro and not LE, they are quite rare) >>>> >>>> Am 2. November 2018 17:01:24 MEZ schrieb Mike Banon <mikebdp2(a)gmail.com>: >>>>> Nice report. Do you think A10-6800K CPU would have worked at this >>>>> motherboard? Or only A8-6600K is supported? Also, what hardware >>>>> revision of this motherboard do you have? (there were F2A85M / --//-- >>>>> PRO and some other revisions, so I'm a bit confused) . I am seriously >>>>> considering doing a similar build, but would like to get the fastest >>>>> available CPU you could install there >>>>> On Fri, Nov 2, 2018 at 4:29 AM kinky_nekoboi >>>>> <kinky_nekoboi(a)bluetardis.de> wrote: >>>>>> something like that happens if u connect anything to a USB2 Port >>>>>> >>>>>> [ 2600.001601] usb 7-1: new full-speed USB device number 3 using ohci-pci >>>>>> [ 2600.001612] ohci-pci 0000:00:12.0: dma_direct_map_page: overflow 0x00000001c52c2ea8+8 of device mask ffffffff >>>>>> [ 2600.001619] ohci-pci 0000:00:12.0: dma_direct_map_page: overflow 0x00000001c52c2ea8+8 of device mask ffffffff >>>>>> [ 2600.001624] ohci-pci 0000:00:12.0: dma_direct_map_page: overflow 0x00000001c52c2ea8+8 of device mask ffffffff >>>>>> [ 2600.185864] usb 7-1: device descriptor read/64, error -11 >>>>>> [ 2600.293659] ohci-pci 0000:00:12.0: dma_direct_map_page: overflow 0x00000001c52c2ea8+8 of device mask ffffffff >>>>>> [ 2600.293669] ohci-pci 0000:00:12.0: dma_direct_map_page: overflow 0x00000001c52c2ea8+8 of device mask ffffffff >>>>>> [ 2600.293674] ohci-pci 0000:00:12.0: dma_direct_map_page: overflow 0x00000001c52c2ea8+8 of device mask ffffffff >>>>>> [ 2600.477668] usb 7-1: device descriptor read/64, error -11 >>>>>> [ 2600.585647] usb usb7-port1: attempt power cycle >>>>>> [ 2601.090486] usb 7-1: new full-speed USB device number 4 using ohci-pci >>>>>> [ 2601.090494] ohci-pci 0000:00:12.0: dma_direct_map_page: overflow 0x00000001c52c2ea8+8 of device mask ffffffff >>>>>> [ 2601.301659] ohci-pci 0000:00:12.0: dma_direct_map_page: overflow 0x00000001c52c2ea8+8 of device mask ffffffff >>>>>> [ 2601.509672] usb 7-1: device not accepting address 4, error -11 >>>>>> [ 2601.693678] usb 7-1: new full-speed USB device number 5 using ohci-pci >>>>>> [ 2601.693693] ohci-pci 0000:00:12.0: dma_direct_map_page: overflow 0x00000001c52c2ea8+8 of device mask ffffffff >>>>>> [ 2601.901677] ohci-pci 0000:00:12.0: dma_direct_map_page: overflow 0x00000001c52c2ea8+8 of device mask ffffffff >>>>>> [ 2602.109672] usb 7-1: device not accepting address 5, error -11 >>>>>> [ 2602.109723] usb usb7-port1: unable to enumerate USB device >>>>>> >>>>>> >>>>>> Am 02.11.2018 um 02:01 schrieb kinky_nekoboi: >>>>>> >>>>>> heeey >>>>>> >>>>>> i am very happy that i have coreboot running now on my desktop machine... >>>>>> >>>>>> ADDON-GPU card works now >>>>>> >>>>>> Nvramcui works >>>>>> >>>>>> Optionrom execution works. >>>>>> >>>>>> IOMMU does not work .. debian has to boot with iommu=off. >>>>>> >>>>>> but KVM virtualsation works somehow. >>>>>> >>>>>> Suspend does not work. >>>>>> >>>>>> USB is still extremely buggy ... only the USB3 Ports are useable. >>>>>> >>>>>> >>>>>> here some output >>>>>> >>>>>> Architektur: x86_64 >>>>>> CPU Operationsmodus: 32-bit, 64-bit >>>>>> Byte-Reihenfolge: Little Endian >>>>>> CPU(s): 4 >>>>>> Liste der Online-CPU(s): 0-3 >>>>>> Thread(s) pro Kern: 2 >>>>>> Kern(e) pro Socket: 2 >>>>>> Sockel: 1 >>>>>> NUMA-Knoten: 1 >>>>>> Anbieterkennung: AuthenticAMD >>>>>> Prozessorfamilie: 21 >>>>>> Modell: 19 >>>>>> Modellname: AMD A8-6600K APU with Radeon(tm) HD Graphics >>>>>> Stepping: 1 >>>>>> CPU MHz: 2068.754 >>>>>> Maximale Taktfrequenz der CPU: 3900,0000 >>>>>> Minimale Taktfrequenz der CPU: 1900,0000 >>>>>> BogoMIPS: 7786.16 >>>>>> Virtualisierung: AMD-V >>>>>> L1d Cache: 16K >>>>>> L1i Cache: 64K >>>>>> L2 Cache: 2048K >>>>>> NUMA-Knoten0 CPU(s): 0-3 >>>>>> Markierungen: fpu vme de pse tsc msr pae mce cx8 apic >>>>>> sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx >>>>>> mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc >>>>>> cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 >>>>>> sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic >>>>>> cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt >>>>>> lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb cpb >>>>>> hw_pstate ssbd vmmcall bmi1 arat npt lbrv svm_lock nrip_save tsc_scale >>>>>> vmcb_clean flushbyasid decodeassists pausefilter pfthreshold >>>>>> >>>>>> >>>>>> 23 entries total: >>>>>> >>>>>> 0:1st timestamp 13,116 >>>>>> 1:start of romstage 13,477 (361) >>>>>> 2:before ram initialization 75,515 (62,038) >>>>>> 3:after ram initialization 1,308,025 (1,232,510) >>>>>> 4:end of romstage 1,319,893 (11,867) >>>>>> 8:starting to load ramstage 1,319,966 (73) >>>>>> 15:starting LZMA decompress (ignore for x86) 1,319,984 (18) >>>>>> 16:finished LZMA decompress (ignore for x86) 1,370,088 (50,103) >>>>>> 9:finished loading ramstage 1,370,357 (269) >>>>>> 10:start of ramstage 1,371,078 (720) >>>>>> 30:device enumeration 1,461,571 (90,493) >>>>>> 40:device configuration 1,470,758 (9,186) >>>>>> 50:device enable 1,501,692 (30,933) >>>>>> 60:device initialization 1,569,453 (67,761) >>>>>> 65:Option ROM initialization 1,769,162 (199,708) >>>>>> 65:Option ROM initialization 1,936,860 (167,697) >>>>>> 70:device setup done 2,011,094 (74,234) >>>>>> 75:cbmem post 2,366,967 (355,873) >>>>>> 80:write tables 2,371,915 (4,947) >>>>>> 85:finalize chips 2,750,289 (378,374) >>>>>> 90:load payload 2,755,411 (5,122) >>>>>> 15:starting LZMA decompress (ignore for x86) 2,797,472 (42,060) >>>>>> 16:finished LZMA decompress (ignore for x86) 2,823,100 (25,628) >>>>>> 99:selfboot jump 2,838,148 (15,048) >>>>>> >>>>>> Total Time: 2,825,023 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> coreboot mailing list: coreboot(a)coreboot.org >>>>>> https://mail.coreboot.org/mailman/listinfo/coreboot

2 1

Update on G505S (dGPU init success)
by Hans Jürgen Kitter 03 Nov '18

03 Nov '18

Hi All, I thought that I share with the G505S+Coreboot (+QubesOS) users that I finally managed to enable and use the dGPUs on the G505S boards. When mentioning boards, I mean, that both variants with its respective VBIOSes: dGPU=1002,6663 (ATI HD 8570M, Sun-Pro) and the dGPU=1002,6665 (ATI R5 M230, Jet-Pro) are working under Ubuntu Linux or Qubes 4.0 (no Windows testing was done or planned). DRI_PRIME=1 seem to work, I use the radeon driver for the APU GPU (A10-5750m) and amdgpu for the dGPU. I'm currently investigating how to get the most out of this setup in Qubes (HW accel 2D in AppVMs). Problem statement: the dGPU was not initiated correctly and was not enabled by the radeon or amdgpu kernel module, VFCT header was corrupt/truncated (effectively was not corrupt, but only VFCT for the APU/iGPU was present). Trying to init the dGPU device through Oprom initialization failed all my attempts (radeon 0000:04:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x0000). This was true whether using Coreboot+GRUB or using Coreboot+Seabios, regardless of kernel version 4.x. Solution in short: Modify Coreboot, that the VFCT table is only created for the dGPU so it can be used by either the radeon or amdgpu KMS driver. Solution in more details: - CB 4.8 latest, with SB latest 1.11.2 as payload - I modified the IO address & the PCI device ID in APU GPU VBIOS file (even though IO address change to 0x3000 might not required). - I modified the IO address in the dGPU VBIOS files to the actual CB - linux kernel provided (0x1000) address - both prepared VBIOSes were put into CBFS - Coreboot config: std. g505s build, but both run oprom & load oprom was enabled (native mode), also display was set to FB, 1024x768 16.8M color 8:8:8, legacy VGA → this provides console output even if eg. GRUB is the payload). - main payload Seabios (compiled as elf separately) - I had to add my SPI chip driver for EN25QH32=0x7016 to CB - I used version 0600111F AMD Fam 15h microcode (even though this was later recalled by AMD to n-1 version 06001119). Nevertheless, Spectre V2 RSB and IBPB mitigations are thus enabled. - I enabled pci 00:02.0 for dGPU in devicetree.cb → according to the CB logs this causes pci resource allocation problems, because the 256M address window of the dGPU conficts with the APU GPU VRAM UMA memory window (originally 512M). Solution (not really professional, but I gave up understanding the whole AGESA and CB PCI allocation mechanism): I decreased the UMA size in buildopts.c to 256M (0x1000) and patched amd_mtrr.c, function setup_bsp_ramtop, to bring TOM down by 256M. So now the APU GPU has an 256M PCI address window @0xd0000000 and the dGPU has also 256M from 0xe0000000 without eventual resource conflict (there's an initial allocation warning for pci:00:01.0 in linux log though). - I modified pci_device.c, function pci_dev_init to only enable pci_rom_probe and pci_rom load for the dGPU pci device (no oprom exec needed for PCI_CLASS_DISPLAY_OTHER). - I modified pci_rom.c, - so the VBIOS of the dGPU is copied to 0xd0000 from CBFS (..check_initialized..) - and pci_rom_write_acpi_tables only run for PCI_CLASS_DEVICE_OTHER → dGPU (ACPI VFCT fill is done from the previously prepared 0xd0000=PCI_RAM_IMAGE_START address) Remark1: there could be one ACPI VFCT table containing both VBIOSes present, but the APU GPU VBIOS is fully working via Oprom exec only. Remark2: in the stock v3 bios additional ACPI tables are present (SSDT, DSDT) which contain VGA related methods and descriptions therefore, the VFCT table itself (in EFI mode) is a lot smaller ca. 20K (vs. 65k). These additional ACPI extentions allow eg. the vga_switcheroo to work under Ubuntu in stock BIOS. WIth CB currently only offloading (DRI...) seems to work. And as I checked I will need to understand the whole ACPI concept before I can migrate the relevant ACPI tables from the stock BIOS to CB for the switching to work. Also, it seems, that TurboCore (PowerNow?) is not currently enabled entirely in CB --> also implemented via ACPI tables in stock BIOS. Well, I’m not a coding expert (just a G505S enthusiast), this is the reason I didn’t include patches. My goal was to describe a working solution, and someone with proper coding skills and the possibility to submit official patches for CB can get this committed. BR, HJK

1 0

FOSDEM 2019 Hardware Enablement Devroom Call for Participation
by Paul Kocialkowski 03 Nov '18

03 Nov '18

Hi, The Hardware Enablement devroom is back for a second year at FOSDEM! It will take place on Sunday 3 February 2019. # Call for Participation We are opening the call for participation to our devroom, with the deadline for talk proposals set to Saturday 1 December 2018. # Devroom Scope This devroom covers topics related to hardware support and enablement with free software. It includes the following topics: * peripheral/controller firmwares * boot software * kernel drivers and hardware interfaces * hardware-related adaptation in operating systems * tools for firmware flashing * tools for low-level development Despite this large scope, the focus of the devroom is set on highlighting the technical aspects of the hardware and its enablement in free projects, rather than the specific applications and use cases that benefit from it. We also want to avoid purely commercial vague talks with marketing content, which leave little place to technical aspects. This year, we are looking to particularly highlighting free software outside of the operating system boundaries, especially with boot software as well as controller and peripheral firmwares. # Talk Format Since no Embedded devroom is taking place this year (and our devroom also covers embedded devices), we are expecting a significant number of submissions. In order to cover as much ground as we can, a new talk will be scheduled every half-hour, so accepted talks will follow this format: 20 minutes for the talk + 5 minutes for questions + 5 minutes for speaker setup We ask speakers to be present in the room before their talk so that speaker setup can go smoothly. # Submission Talks that fit in our devroom's scope can be submitted to the FOSDEM Pentabarf interface at https://penta.fosdem.org/submission/FOSDEM19 We encourage reusing accounts from previous years instead of creating new ones: * lost password: https://penta.fosdem.org/user/forgot_password * new Account: https://penta.fosdem.org/user/new_account/FOSDEM19 Here are a few guidelines when submitting a talk: * select the Hardware Enablement devroom as track * include an abstract for every submission and optionally a full description * make sure your contact details are up to date # Video Talks will be streamed live during the event and recorded. They will be available under a Creative Commons Attribution (BY) license later. # Contact For more information or questions about the devroom and this CFP, feel free to email hardware-devroom-manager at fosdem.org We're looking forward to lots of interesting proposals and hoping to see you all in Brussels at the event! Cheers, Paul for the Hardware Enablement devroom

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2018