diff options
Diffstat (limited to 'docs/future/dumps/kernel312_irc')
| -rw-r--r-- | docs/future/dumps/kernel312_irc | 1590 |
1 files changed, 1590 insertions, 0 deletions
diff --git a/docs/future/dumps/kernel312_irc b/docs/future/dumps/kernel312_irc new file mode 100644 index 0000000..c04a00c --- /dev/null +++ b/docs/future/dumps/kernel312_irc @@ -0,0 +1,1590 @@ +<hr/> + + <h1 id="todo_cb5926_paulmenzel">Coreboot 5926 test for Paul Menzel</h1> + <p> + Coreboot log when running Video BIOS (grub payload) and <a href="http://review.coreboot.org/5926">http://review.coreboot.org/5926</a>. + </p> + <p> + Result (ThinkPad X60): <a href="dumps/coreboot_5296_oprom_grub_cbmemc">cbmem -c output</a><br/> + Config used on the X60 (grub payload and vbios): <a href="dumps/coreboot_5926_oprom_grub_config">.config</a> + </p> + + + + + + + + + + + + <h1 id="todo_cb5893_paulmenzel">Coreboot 5893 test for Paul Menzel</h1> + <p> + <a href="dumps/x60_5893_vbios.tar.gz">With VBIOS</a><br/> + <a href="dumps/x60_5893_native.tar.gz">With native graphics</a> (replay code). + </p> + <p> + Here is a crash dump from running native graphics (): <a href="dumps/x60_5893_native_crashdump">/sys/class/drm/card0/error</a>. + </p> + +<hr/> + +<h1 id="i945_stolenmem_fix">early attempt: i945 stolen memory fix (for kernel 3.12/later) (this attempt failed)</h1> +<p> +Back then we had no idea that GTT address was incorrect, and we had no idea what was causing the issue. + +<pre> +Note: see <a href="#i945_312fix">this fix</a> for the initial fix that was found. + +<b><font color="red">not working yet</font></b> +<a href="http://review.coreboot.org/#/c/5885/" target="_blank">http://review.coreboot.org/#/c/5885/</a> + +untested. will test this. +checkout 5320. cherry pick 5345 on top. +mannually apply changes from 5884/1 and 5885/3 +make backlight changes as in #x60_native_notes and #t60_native_notes +test this on X60 and T60. + +If it works, manually apply 5885 to 5320 alone and then push with 5320 as dependency. +Rebase that new change ID, and rebase 5345 (pushing it as new change ID). +Manually merge the rebased 5345 into the new patch, and then push that. + +Boot with grub (obviosly!) and kernel 3.14.4 as before (with 17fec8a left untouched!). + +Note: tidy these notes! (so others can follow) + +get those logs: +Make a copy of these files: + * /var/log/dmesg + * /var/log/kern.log + * /var/log/Xorg.0.log + * /var/log/Xorg.0.log.old (If you have to restart gdm) + * /proc/ioports + * /proc/iomem +Record these outputs: + * sudo intel_reg_dumper + * uname -r + * lspci -vvnn +Do this first: <b>$ sudo modprobe msr</b> (then do as below): + * sudo inteltool -a --> in coreboot/src/util/inteltool +Make a copy of: + * coreboot serial output log. + --> Get it from serial port, or get it like that: + --> <b>./cbmem -c</b> (under coreboot/util/cbmem) +Output from source tree: +$ git log -p | head -150 (localhost/x60gitlog) +$ git diff (localhost/x60gitdiff) +Make a copy of the .config from coreboot source tree + ^ (localhost/x60config) +3D acceleration test (test if 3.12+/stolenmem issue is fixed): + - Run openarena (1024x768 res), say if it works. (note: Press tilde, do <b>/cg_drawfps 1</b>) + - Run tuxcart (1024x768 res), say if it works. + - Run neverball (1024x768 res), say if it works. + - Run glxgears, report what you see. + +Some results on the X60 (3D still doesn't work, openarena and tuxkart were slow): +<a href="dumps/5885_logs.tar.gz">5885_logs.tar.gz</a> +git diff: http://paste.debian.net/102618/ + +In src/northbridge/intel/i945/raminit.c +PaulePanter: fchmmr: In your next step could you please add +PaulePanter: printk(BIOS_DEBUG, "BSM = 0x%08x\n", pci_read_config32(PCI_DEV(0,2,0), BSM)); +PaulePanter: before +PaulePanter: pci_write_config32(PCI_DEV(0,2,0), BSM, (tolud * MiB - 64 * MiB) & 0xfff00000); +done +Also removing the #if statement around those 2 lines above. +Also adding it after that line aswell, per advice from PaulePanter + +Some new results on the X60 after doing the above (3D still doesn't work, openarena and tuxkart were slow): +<a href="dumps/5885_logs_2.tar.gz">5885_logs_2.tar.gz</a> + +PaulePanter: fchmmr: No idea if you can write with `devmem2`. Never used it. +PaulePanter: fchmmr: It would indeed be interesting to know what value the BSM has with the vendor BIOS. +Note to self: do that. + +PaulePanter said: I have `& 0xfff00000` and phcoder uses `& 0xfffff000`, so it looks like I have the ordering incorrect. + + +Look at that discussion: +http://lists.freedesktop.org/archives/intel-gfx/2014-May/046309.html +http://lists.freedesktop.org/archives/intel-gfx/2014-May/046310.html +--> if BSM register is read-only, then is there something els ethat we might have missed? + +</pre> +</p> + + + + + + + + + + + <h2><a name="kernel312bugs">kernel 3.12+ bugs (X60/T60 native init)</a><a href="#pagetop">Back to top of page</a></h2> + <p> + Some further notes to refer to later (WARNING: long! These are collected IRC logs for later reference. Most of the + logs are not useful or relevant, and will be deleted later): + +<pre> +Note: see <a href="#i945_312fix">this fix</a> for the initial fix that was found. + +see: <a href="http://www.coreboot.org/Board:lenovo/x60#Problems_in_native_graphics_code_exposed_by_recent_kernels" target="_blank">http://www.coreboot.org/Board:lenovo/x60#Problems_in_native_graphics_code_exposed_by_recent_kernels</a> +see: <a href="http://www.coreboot.org/Lenovo_x60x_vgainit_todos" target="_blank">http://www.coreboot.org/Lenovo_x60x_vgainit_todos</a> + +Non-coreboot (not even i945) platforms also have issues with 3.12+ +see: <a href="https://bugs.freedesktop.org/show_bug.cgi?id=76520" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=76520</a> + +Is this relevant?: <a href="http://lists.freedesktop.org/archives/intel-gfx/2014-February/040771.html" target="_blank">http://lists.freedesktop.org/archives/intel-gfx/2014-February/040771.html</a> + + + +note: read below. +and note: on later kernels they also can't seem to init the GPU properly without vbios or native gfx, whereas older kernels could. + +PaulePanter: damo22: There is also a Linux and coreboot native graphics incompatibility documented in the Wiki (by samnob). +PaulePanter: http://www.coreboot.org/Board:lenovo/x60#Problems_in_native_graphics_code_exposed_by_recent_kernels +fchmmr: PaulePanter, that only exists with kernel 3.12 and above. +PaulePanter: fchmmr: Do you have time to report it to the Freedesktop Bugzilla? +funfunctor: patrickg: I think its related to recent changes we had done to toolchain.in +fchmmr: Yes. What info do you need ? +PaulePanter: fchmmr: It’s a regressions and these are normally not allowed with Linux’ no regression policy. +fchmmr: What do you think would happen then, after I made that report? +PaulePanter: fchmmr: https://01.org/linuxgraphics/documentation/how-report-bugs +fchmmr: You can look at it 2 ways: kernel broke, or kernel fixed a bug which broke coreboot. +PaulePanter: fchmmr: Hopefully they’ll fix it. +fchmmr: so: either coreboot is broken, or kernel is broken. +fchmmr: PaulePanter, kernel 3.12+ should work just fine on lenovo bios, so my opinion is that the native gfx in coreboot is what's buggy. +PaulePanter: fchmmr: You can also check with the developers in #intel-gfx. But first report the bug so you can reference it. +fchmmr: Do you think I should just copy what's in the coreboot wiki already? +PaulePanter: fchmmr: Does not matter. If it worked before 3.12, it should work afterward. +fchmmr: It seems pretty complete (as far as reporting it is concerned). +fchmmr: PaulePanter, my basic point is that I'm on the fence as to whether this is linux's problem, coreboot's problem, or both. +PaulePanter: fchmmr: That would probably help. If they need other information, the Intel folks will ask you for it. Daniel Vetter and the other Intel folks are very responsive in my experience. +fchmmr: So you think then that there would be a patch specifically for i915 + coreboot_native_init +PaulePanter: fchmmr: I do not know. They hopefully figure it out. +fchmmr: PaulePanter, I will do it. +PaulePanter: fchmmr: And as I wrote, it is a regression. As far as I understood it, even if the firmware/hardware is broken, Linux should not introduce regressions. +fchmmr: PaulePanter: at the very least, it might offer a new perspective. this whole issue has been very one-sided so far: it has only been coreboot community that talks about it. It has probably gone unobserved in kernel/intel community. +fchmmr: The intel/kernel people might even be able to (easily) spot a fix for coreboot. +fchmmr: I hadn't even considered this possibility before, I thought it was only a coreboot problem. Talking to those other people definitely makes sense. + +PaulePanter of #coreboot made the initial report to Freedesktop tracker: + +PaulePanter: fchmmr: Hi. Did you report the Linux regression to the Freedesktop bug tracker? +PaulePanter: fchmmr: Understood. Do you have an account for the Freedesktop bug tracker? +fchmmr: PaulePanter: I do not have an account for Freedesktop bug tracker, but I think I could get one? +PaulePanter: fchmmr: Yes, it is easy to register. +fchmmr: PaulePanter, there's reporting and there's reporting properly; I want to compile my report first, before I make it. +PaulePanter: fchmmr: As you do not know what they need, I think it is the wrong approach. +fchmmr: Since the people that I am reporting to will be unfamiliar with the issue, and might not even know about coreboot, or only vaguely know. +PaulePanter: fchmmr: I’ll report the issue and give you the URL. You can then add to it. +fchmmr: PaulePanter: Good point. I can make it brief describing it as best I can, and then I can answer any specific questions. +fchmmr: PaulePanter, you can use my notes at http://libreboot.org/howto.html#kernel312bugs if you like, it's a collection of insights plus links to those pages on the coreboot wiki that talk about the issue. +fchmmr: (in case there is anything in the notes that might be helpful) +fchmmr: PaulePanter, are the intel i915 devs of freedesktop also the ones working on the i915 code in kernel.org? (I'm slightly confused about this) + +THE REPORT: + +PaulePanter: fchmmr: The Wiki talks about crashes. +PaulePanter: fchmmr: https://bugs.freedesktop.org/show_bug.cgi?id=79038 + +PaulePanter: fchmmr: The Wiki talks about crashes. +PaulePanter: fchmmr: https://bugs.freedesktop.org/show_bug.cgi?id=79038 +fchmmr: PaulePanter, thanks. I'll add to it and help any way I can. +PaulePanter: fchmmr: Add `drm.debug=0x06` to the Linux command line (probably configuring in GRUB) and please add `/var/log/dmesg` to the bug report. (Or the output of `dmesg`.) +PaulePanter: fchmmr: They also need `/var/log/Xorg.0.log` and your distribution and exact Linux kernel version `uname -r`. +fchmmr: PaulePanter: there are basically 2 versions of native init: 3998 (based on replay, only works on X60 with XGA screen - also what libreboot currently uses) and 5320 (much better, works on more screens, 5345 can use it to enable T60 - not yet in libreboot) +fchmmr: PaulePanter: should I do this test on both versions? (libreboot and coreboot+5320+5345) + +fchmmr: PaulePanter: should I do this test on both versions? (libreboot and coreboot+5320+5345) +fchmmr: PaulePanter: nonetheless, I will do both, and make that report for you now. +fchmmr: Do I do this on pre-3.12 kernel or 3.12+ ? +PaulePanter: fchmmr: I’d say Linux 3.12+. +PaulePanter: fchmmr: Do you know which coreboot patches samnob used? + +fchmmr: PaulePanter: very well. http://jxself.org/linux-libre has latest kernels +fchmmr: I will install that. +fchmmr: I do not know what coreboot patches samnob used. Probably 3998 (this was a long time ago). +fchmmr: Definitely change ID 3998 (review.coreboot.org gerrit): http://review.coreboot.org/#/c/3998/ + + +fchmmr: PaulePanter: here is the information that you requested: http://libreboot.org/logs/3998_Xorg.0.log http://libreboot.org/logs/3998_dmesg http://libreboot.org/logs/3998_uname +fchmmr: PaulePanter: that bug in the report doesn't happen with the above -- it's an older kernel. +fchmmr: Do they want me to try 3.12+ instead? +fchmmr: PaulePanter: you should also give them these links to the lastest code for native graphics: +fchmmr: http://review.coreboot.org/#/c/5320/ + +PaulePanter: fchmmr: Thank you for getting the logs. Please register and upload the files yourself. +fchmmr: Yes, ok. I will also get the same logs again for a kernel that is broken (3.12+) +fchmmr: I will repeat both processes again for coreboot+5320+5345, as currently I am getting these on libreboot. +fchmmr: More logs can't hurt, the worst that can happen is they will ignore the ones they don't need. I want to make sure they have everything they need. + +samnob: fchmmr: samnoble.org/thinkpad/kernel/linux-image-3.14.4-gnuowen_1_i386.deb and http://samnoble.org/thinkpad/kernel/linux-image-3.14.4-gnu-stolenmem-owen_1_i386.deb latest linux-libre without and with 17fec8a reverted. +PaulePanter: fchmmr: Thanks. + +fchmmr: samnob, thanks. +fchmmr: but we are trying to get kernel 3.12+ to work without users having to patch it +fchmmr: either by fixing coreboot, or patching around coreboot in the kernel +fchmmr: eventually both +samnob: Yes, just providing you kernels for the bug. +fchmmr: ah right. +fchmmr: with and without. that is useful. i was going to use jxself kernels. that is useful. +fchmmr: I'll use yours then ;) +fchmmr: dpkg -i ? + +samnob: Though based on the devs comment in the bug I think you're hope of the driver working around it is unlikely. +fchmmr: can't hurt to try +samnob: dpkg -i will work fine. +samnob: (though gdebi is more fun.) +samnob: there's a version symlink_hook in that same folder that is handy for grub2 payload users too. +fchmmr: samnob we think it might be classed under linux "no regression" policy +fchmmr: PaulePanter's idea +samnob: can't hurt to try :) + +Here is the debugging results then: <a href="coreboot_native_3.12_bug.tar.gz" target="_blank">coreboot_native_3.12_bug.tar.gz</a> + +--- + +http://undeadly.org/cgi?action=article&sid=20131120060004 was suggested +(also refer back te the datasheet) + +---- + +I have since been alerted to this bug report, which is unrelated to us +but shows that 3.12 also breaks later systems on Lenovo BIOS (as far as I can tell): + +https://bugzilla.kernel.org/show_bug.cgi?id=71391 + +-- + +PaulePanter: fchmmr: If you run the Lenovo X60 right now, could you just paste it now. It should not change between all your tests. +PaulePanter: fchmmr: It would really be helpful to have it now. +fchmmr: My workstation X60 is running coreboot+5320 (and modification for backlight control support) +fchmmr: Shall I take iomem output from that? +fchmmr: kernel 3.2 is in use +PaulePanter: fchmmr: Yes. Please. +fchmmr: For you record: +fchmmr: $ uname -r +fchmmr: 3.2.0-56-generic-pae +fchmmr: distro: trisquel 6 +fchmmr: PaulePanter: http://paste.debian.net/101404/ + +PaulePanter linked to this: +http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/3rd-gen-core-desktop-vol-2-datasheet.pdf +--------------- + +PaulePanter: patrickg: As the resident i945 export, do you know where the register GBSM (Graphics Base of Stolen Memory) should be set? +PaulePanter: patrickg: Is the VGA Option ROM responsible for that? +PaulePanter: damo22: You do not see any problems with the VGA Option ROM, right? +damo22: PaulePanter: i am running vga rom with updated kernel (after the patch) and experience no problems with video +PaulePanter: damo22: Thank you for the confirmation. +PaulePanter: src/northbridge/intel/i945/northbridge.c: printk(BIOS_SPEW, "Base of stolen memory: 0x%08x\n", +patrickg: PaulePanter: what's that, 0x5c? +patrickg: h, no +PaulePanter: + /* Almost universally we can find the Graphics Base of Stolen Memory +PaulePanter: + * at offset 0x5c in the igfx configuration space. On a few (desktop)patrickg: PaulePanter: I think we never configured that but left it to vgabios +patrickg: PaulePanter: we only configured the RAM side +PaulePanter: patrickg: Thanks. So with native VGA init, coreboot needs to do that too. +<b><font color="red">damo22: we just need to write the gfxstolen base to gma config space at 0x5c</font></b> +damo22: that should fix it +damo22: because then the kernel will try to read that +damo22: hmm but if the generation of the gma is not >=3 it will assume it is above top of memory +patrickg: well, it is +damo22: patrickg: do you happen to know if the x60 gma is generation 2 or 3? how do i find out +PaulePanter: damo22: lspci ? +damo22: (rev 0x)? +PaulePanter: lspci -nn +damo22: never mind i will ctags the kernel tree +patrickg: but bbl +patrickg: damo22: code.metager.de applies openGrok on tons of open source projects. probably to linux, too +damo22: thanks patrickg +damo22: okay, i945g/gm is generation 3 +damo22: its nothing to do with the lscpi revision +PaulePanter: damo22: How did you check that? +PaulePanter: … it is 3rd gen? +damo22: PaulePanter: its in the i915_drv.c in the kernel +damo22: eg, i965g/gm is generation 4 +PaulePanter: Ok. +damo22: its also NOT valleyview +* pl4nkton is now known as pl4nkton`away +PaulePanter: damo22: ? +PaulePanter: Who said that? +damo22: im trying to figure out which path the kernel takes before and after the patch +damo22: it must be different +PaulePanter: damo22: https://bugs.freedesktop.org/show_bug.cgi?id=79038#c12 +PaulePanter: damo22: Before they calculate it manually and afterward they read out that register, which the firmware should program, right? +PaulePanter: src/northbridge/intel/i945/i945.h:#define TOLUD 0x9c /* Top of Low Used Memory */ +PaulePanter: Off topic, how do I make Vim and Ctags jump to the correct header definition. If I Ctrl + click on `TOLUD` in `src/northbridge/intel/i945/raminit.c` it jumps into the header of `intel/fsp_sandybridge/northbridge.h` instead of `src/northbridge/intel/i945/i945.h`. +PaulePanter: ? +damo22: i have the same problem, there is a way to configure it to pop up a list of matches so you can select the right one but i dont know how +PaulePanter: damo22: Ok. Good to know I am not the only one. +<b><font color="red"> +damo22: okay, so for gen 3 i915, (i945/m) we can do what i said above and it should work +PaulePanter: Is “graphics datastolen memory size (PCI Device 0 offset 52 bits 7:4)” configurable and programmed by the firmware or is it fixed if the IGP is enabled and can just be read? +PaulePanter: damo22: Yes. +damo22: its just a matter of setting the base address in the register +damo22: i think the only difference is that in the kernel it is assumed that it is aligned to 0x100000 +damo22: kernel does this: base &= ~((1<<20) - 1); +damo22: but coreboot does this: pci_read_config32(dev, 0x5c) & ~0xf, +damo22: possibly a one liner +damo22: change ~0xf to ~0xfffff lol +samnob: fchmmr: samnoble.org/thinkpad/kernel/linux-image-3.14.4-gnu-stolenmem-owen_2_i386.deb and linux-image-3.14.4-gnuowen_2_i386.deb with CONFIG_STRICT_DEVMEM unset. No PAE as always. +samnob: damo22: thanks for looking into this. +</font></b> +fchmmr: damo22: you are the most awesome person ever. I'm stilll preparing my dev/debugging environment and you speculate this already. I will try it soon. +fchmmr: samnob: thank you for confirming. +fchmmr: samnob: ok, /dev/mem support and non-PAE. excellent! +samnob: fchmmr: don't overlook that revision 2 those, are new debs with STRICT_DEVMEM unset +damo22: fchmmr: its much quicker to read and compare code than to compile kernels and flash firmware +PaulePanter: fchmmr: I think your testing is not needed until you get a patch. +PaulePanter: damo22: TOLUD (PCI Device 0 offset BCh bits 31:20) +fchmmr: PaulePanter ? +fchmmr: Yes I understand that. I was about to debug, but now we will test damo22's advice first. +damo22: PaulePanter: i think intel_gma_init is being called with unaligned physical address for graphics mem + +PaulePanter: fchmmr: BDSM—Base Data of Stolen Memory Register +PaulePanter: http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/3rd-gen-core-desktop-vol-2-datasheet.pdf + +PaulePanter: fchmmr: The methods you try just read it out and never set it. +PaulePanter: This register contains the base address of graphics data stolen DRAM memory. BIOS determines the base of graphics data stolen memory by subtracting the graphics data stolen memory size (PCI Device 0 offset 52 bits 7:4) from TOLUD (PCI Device 0 offset BCh bits 31:20). +damo22: PaulePanter: im pretty sure BDSM is only present in core iX cpus +fchmmr: PaulePanter, yes my method was to go about to be sure where it is set, and then try to set it properly in 5320. +PaulePanter: fchmmr: The problem is already present with native graphics in coreboot master, isn’t it? +fchmmr: damo22 took a shorter method to get the same result (hopefully. like you, i wait for him to confirm or deny success) +fchmmr: PaulePanter, yes the 3.12+ glitches exist in 5320 changeset aswell as 3998 (the old replay version, which 5320 is a re-write of) +PaulePanter: fchmmr: Sorry, I claim your tests would have never gotten any solution for the problem. +* martinr (~martin@8.36.227.227) has joined #coreboot +fchmmr: PaulePanter, that is quite possible, but it was a test anyway. +PaulePanter: damo22: Chris Wilson and the Linux commit say that the BDSM is present, don’t they? +PaulePanter: + if (INTEL_INFO(dev)->gen >= 3) { +PaulePanter: + /* Read Graphics Base of Stolen Memory directly */ +fchmmr: I actually did find where the stolen memory address was set, in /var/log/kern.log after using drm.debug=0x06 in those previous results i uploaded to freedesktop.org, but that was on coreboot/5320 with the address set incorrectly. +fchmmr: just search for the word "stolen" in the log and you'll find it on one of the lines. + +PaulePanter: fchmmr: It’s not *set* it is *read* in there. +fchmmr: Oh right. +fchmmr: But I thought when reading it, it has to know the address. So the address I saw must have been what was set? +fchmmr: What am I missing? +damo22: okay so there is something to clarify, i915 driver is the same for all intel gpus even some that are physically located in cpu + +PaulePanter: fchmmr: As it is not explicitely set beforehand it contains some incorrect value, which is then read. +PaulePanter: fchmmr: That is the whole problem. +fchmmr: I see. +fchmmr: So, +fchmmr: my tests would have been useless, then. + +<b><font color="red">damo22: it didnt work</font></b> +(note: can still try to make other changes: see testing notes below) + +damo22: oh wait, X just didnt detect the LVDS +damo22: in fact nothing did +damo22: but there were no errors +damo22: ok so when i plug external monitor X freezes and gives errors +damo22: and internal display isnt active +damo22: wierd, when i rebooted i got vga fine +damo22: i think linux kernel i915 is trying to do something with vgarom because it says "invalid rom contents" as first boot line +damo22: no i need to find out if the kernel is doing something bad without rom present +damo22: and then figure out how to enable lvds, because vga is working +fchmmr: drivers/pci/rom.c: dev_err(&pdev->dev, "Invalid ROM contents\n"); +fchmmr: in that: size_t pci_get_rom_size(struct pci_dev *pdev, void __iomem *rom, size_t size) +fchmmr: /* Standard PCI ROMs start out with these bytes 55 AA */ +fchmmr: if (readb(image) != 0x55) { +fchmmr: dev_err(&pdev->dev, "Invalid ROM contents\n"); +fchmmr: break; +fchmmr: } +damo22: i guess i should focus on the fact that coreboot did not initialise the gfx at grub screen +damo22: i mean seabios +damo22: its difficult because linux does some reinitialisation of gfx +damo22: i thought i had this one in the bag +CareBear\: damo22 : it does complete reinit +damo22: i flicked throught the kernel i915 driver and it looks like it reads VBT tables from romheaders or something +damo22: if we are using native gfx init, those are not present right? +samnob: damo22: I think you need to be using grub2 to test native gfx init, seabios needs at least a stub of a vgarom. +CareBear\: damo22 : correct +CareBear\: samnob damo22 : if you want to use SeaBIOS you can use the SeaVGABIOS which will pick up a native framebuffer initialized by coreboot +damo22: does SeaVGABIOS install VBT stuff in the vgarom area? +CareBear\: damo22 : probably not the kind the framebuffer driver looks for +damo22: then it will fail with linux +CareBear\: damo22 : yes +damo22: CareBear\: can we write a vgabios stub that passes the signature tests and also has native VBT tables, but executes nothing? +damo22: otherwise we need to patch the linux kernel to ignore certain models that have no vgabios +CareBear\: damo22 : let's first find out what information is used in those tables +damo22: i have the code in front of me +damo22: drivers/gpu/drm/i915/intel_bios.c (kernel) +damo22: fchmmr: no, i am trawling through linux driver code +fchmmr: damo22: are you aware that certain kernels can initialize the GPU on X60 without the native gfx or oprom? (you don't see payloads, but kernel/X11 shows display +damo22: i have a feeling the linux kernel currently tries to load the vgarom regardless of PCH existance + +damo22: i think there are two problems with native gfx init, one problem is that the lvds isnt coming up (coreboot issue), the other is is with the linux kernel i915 driver that tries to read the vgarom that isnt there + +fchmmr: damo22, what hardware are you testing your changes on? +fchmmr: Did you try 5320 without your changes? +fchmmr: (hardware: X60 or T60) + +Peter on 5320 talks about vga pipe not being enabled: this means that payload doesn't appear +on vga (only on lvds). OS can output on vga or lvds. so we need to get 5320 to output (during payload) on vga + +damo22: i just slept on it, and i think i know what the problem is + + * LVDS discovery: + * 1) check for EDID on DDC + * 2) check for VBT data + * 3) check to see if LVDS is already on + * if none of the above, no panel + + +1) it cant find the EDID because the i2c is failing to read with NAK +2) there is no VBT data because there is no vga option rom +3) coreboot is still not doing native init properly so the panel is still off + +Therefore linux assumes there is no LVDS. + +damo22: how do i enable cbmem console? i enabled it in menuconfig, do i need cbmem dynamically growing? +damo22: [*] Send console output to a CBMEM buffer\ +damo22: but i got nothing + +Guest-FR: Hi +Guest-FR: would you please check +Guest-FR: src/northbridge/intel/i945/gma.c +Guest-FR: function gma_func0_disable +Guest-FR: pci_write_config16(dev, GCFC, 0xa00) , sound wrong isn't it? + +damo22: Guest-FR: what do you think is wrong about it? +Guest-FR: per the datasheet (intel, so probably it is also wrong!) , the value should be "0x1b" +Guest-FR: page 74 +damo22: Guest-FR: can you link me to the datasheet +Guest-FR: damo22: congig16 is expecting 0x && 4 digits isn't it? +Guest-FR: damo22: e.i.: 0x1234 +damo22: Guest-FR: 0xa00 === 0x0a00 +damo22: same thing +Guest-FR: ok + +Guest-FR: here is the link for tha datasheet http://www.intel.com/Assets/PDF/datasheet/307502.pdf + +damo22: ty +damo22: Guest-FR: i am also working on this gma +damo22: Guest-FR: i am trying to figure out why native gfx init is not working on my X60 tablet + +Guest-FR: per gma.h, GCFC is 0xf0 /* Graphics Clock Frequency & Gating Control */ +damo22: Guest-FR: GCFC is missing from the datasheet +damo22: so how do you know its wrong +Guest-FR: it is my mistake.... I'm expecting to see 4 digits for conf16 +damo22: Guest-FR: ok, i would have expected GCFC to be on page 62 at the bottom but its missing +Guest-FR: probably we should make a dump to see the value we have with an original bios. what you think ? is it possible? +damo22: Guest-FR: however, GGC is mismatching between that datasheet and in coreboot gma +Guest-FR: intel is a fu*** company +damo22: ahh no, i looked up the wrong file +damo22: it matches +damo22: Guest-FR: i am assuming you are using patched gma to test? +Guest-FR: damo22: no, I use the original one +damo22: Guest-FR: http://review.coreboot.org/#/c/5320/ +Guest-FR: I try to port my board to coorboot https://github.com/coreboot-for-945g-m4/945g-m4 +Guest-FR: thx damo22 +damo22: Guest-FR: you need extra config in devicetree.cb with that +Guest-FR: damo22: http://review.coreboot.org/#/c/5762/ +damo22: Guest-FR: i cant view it +Guest-FR: oops, it is draft +Guest-FR: may I add you as a reviewer ? +damo22: Guest-FR: sure +Guest-FR: damo at zamodio? +damo22: correct +Guest-FR: done +Guest-FR: please feel free put comments (and be verbos, I'm not a developper :p ) +Guest-FR: probably my devicetree is not good, +damo22: it still wont load +Guest-FR: damien at zamaudio.com ? +damo22: yes +damo22: ok better +Guest-FR: probably you got an email ? +Guest-FR: for a review +damo22: Guest-FR: i dont see native gfx init +damo22: are you using vgarom? +Guest-FR: I'm using a PCIE card (Radeon X300) +damo22: dont you want to try to initialise the onboard gfx? +Guest-FR: why not, I'll give it a go :) +damo22: you showed me a whole bunch of code, but what is the problem? +Guest-FR: the serial is working, but it hang on "setting up static southbridge register ..." +Guest-FR: and some times, it went to "setting up Root Complex Topology" +damo22: Guest-FR: well, look for that message in the code and find the next message that should be displayed and you know the problem is between the two messaged +Guest-FR: there is some thing unstable +damo22: messages* +Guest-FR: ok +damo22: Guest-FR: if its too hard to find, add some printk's +damo22: i could really use a tip on how to enable cbmem console +damo22: im running blind + +Guest-FR: the msg ih at " src/northbridge/intel/i945/early_init.c " i945_setup_bars function +Guest-FR: so my problem is between "Setting up static southbridge registers..." and "Done" :) + +damo22: cat .config|grep CBMEM ===> http://paste.debian.net/101541/ why do i still not have any cbmem console? "No console found in coreboot table." +content of debian paste: +CONFIG_EARLY_CBMEM_INIT=y +# CONFIG_DYNAMIC_CBMEM is not set +CONFIG_CONSOLE_CBMEM=y +CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x20000 +damo22: No coreboot CBMEM area found! +* Guest-FR (d5f5ab0b@gateway/web/freenode/ip.213.245.171.11) has joined #coreboot +Guest-FR: I'd like to understand: is there any difference betweent: pci_write_config16(LPC_DEV, 0x84, 0x0a01); + pci_write_config16(LPC_DEV, 0x86, 0x00fc); vs pci_write_config32(LPC_DEV, 0x84, 0x00fc0a01); +Guest-FR: for exemple: lenovo/x60/romstage.c we have: pci_write_config16(PCI_DEV(0, 0x1f, 0), 0x84, 0x1601); however in the ich7 datasheet page 364 it is a conf32 + +phcoder-screen: damo22: for C segment. boot with oprom, then dd if=/dev/mem bs=64k of=seg_cdef.bin skip=12 count=4 +damo22: ok +damo22: is that the VBT table? +phcoder-screen: part of it is +damo22: phcoder-screen: http://www.zamaudio.com/mbox2/seg_cdef.bin +damo22: it looks correct because it mentions calistoga +damo22: phcoder-screen: as a general solution, would it be possible to write a script that takes a vgarom as input and outputs a vgarom stub that will have no executable code but still have the VBT stuff and signatures to fool the OS that real vgarom is there, and will detect panels etc +damo22: or is there a better way? + +phcoder-screen: damo22: there is a better way: generate it in coreboot. I have a tool to partially parse the roms. Trying it with yours. +damo22: cool + +phcoder-screen: damo22: http://pastebin.com/GsYhSaNB +Content of that paste: +signature: <$VBT CALISTOGA > +version: 1.00 +VBT size: 0xea0 +VBT checksum: 0x0 +BDB version: 1.29 +section type 254, size 0xea + type: 0 + relstage: 64 + chipset: 1 + LVDS + No TV + rsvd3[0]: 0x8 + rsvd3[1]: 0x3 + rsvd3[2]: 0x31 + rsvd3[3]: 0x33 + Signon: 13Intel(r)Calistoga PCI Accelerated SVGA BIOS +Build Number: 1313d.dal PC 14.20 Dev 10/17/2006 0:22:30 +DECOMPILATION OR DISASSEMBLY PROHIBITED + + Copyright: + Code segment: a + DOS Boot mode: 0 + Bandwidth percent: c0 + rsvd4: 0x3 + Bandwidth percent: 8 + rsvd5: 0x4 +section type 1, size 0x5 +General features: + panel_fitting = 0x3 + flexaim = 0x1 + download_ext_vbt = 0x1 + *enable_ssc = 0x1 + *ssc_freq = 0x1 + *display_clock_mode = 0x0 + disable_smooth_vision = 0x0 + *fdi_rx_polarity_inverted = 0x0 + legacy_monitor_detect = 0x1 + *int_crt_support = 0x1 + *int_tv_support = 0x0 +section type 254, size 0x20 +section type 2, size 0xcb + *CRT DDC GMBUS pin: 2 + DPMS ACPI: 0 + Skip boot CRT detect: 0 + DPMS aim: 1 + boot_display: { 0, 0 } + 6 devices + *device type: 1009 (TV) + *dvo_port: 5 + *i2c_pin: 0 + *slave_addr: 0 + *ddc_pin: 0 + *dvo_wiring: 0 + edid_ptr: 0 + *device type: 1022 (flat panel) + *dvo_port: 4 + *i2c_pin: 0 + *slave_addr: 0 + *ddc_pin: 3 + *dvo_wiring: 0 + edid_ptr: 0 + *device type: 0 (Empty) + *device type: 0 (Empty) + *device type: 0 (Empty) + *device type: 0 (Empty) +section type 3, size 0x1 +section type 4, size 0x1c +section type 254, size 0x69 +section type 6, size 0x16d +section type 7, size 0x7 +section type 8, size 0x3d +section type 10, size 0xcb +section type 11, size 0xc7 +section type 12, size 0xf + *LVDS config: 1 + *Dual frequency: 1 +section type 13, size 0x3 +section type 14, size 0x9 +section type 15, size 0x8b +section type 16, size 0x84 +section type 17, size 0x8 +section type 18, size 0xc +section type 19, size 0x20 +section type 20, size 0x9e +section type 22, size 0x15 + *Panel type: 3 +section type 23, size 0x48 +section type 24, size 0x28 +section type 25, size 0x28 +section type 26, size 0x2 +section type 40, size 0x8 +section type 41, size 0x91 +section type 42, size 0x4a0 +section type 43, size 0x61 +section type 44, size 0x15 +damo22: phcoder-screen: does that mean for every supported board, an extra step will be needed to parse the roms so that the port can be done +damo22: *CRT DDC GMBUS pin: 2 +damo22: i think it is trying pin 3 +phcoder-screen: damo22: CRT is VGA +phcoder-screen: ddc_pin is 3 under lvds section +damo22: oh yeah +phcoder-screen: damo22: we already need some info in device tree to init. I think we can reuse it +phcoder-screen: I can upload my parser if you want +damo22: sure, i can parse my T60 and X60t +damo22: and eventually T61 +phcoder-screen: CL 5842 +damo22: thanks + +damo22: phcoder-screen: do you think the EDID is failing to read in linux because the VBT is missing? + +phcoder-screen: damo22: it's a likely explanation. I'd reput first 64k of your dump back to place +damo22: where does it belong in the flash? +damo22: c0000? +phcoder-screen: damo22: nowhere. c0000 is in RAM +damo22: so how do i ensure it gets loaded into ram at c0000 +phcoder-screen: damo22: memcpy +damo22: im convinced it will work if i do that +damo22: thats like loading the vgarom +damo22: but without executing it +phcoder-screen: damo22: yes +damo22: couldnt i just select it in menuconfig, but comment out the code that runs it? +phcoder-screen: yes +phcoder-screen: and keep in mind that oprom is self-modifying +damo22: yes so i need the final dump to load not the original +phcoder-screen: yes + + + +-- + +Side discussion (in #libreboot, not #coreboot as above): + +fchmmr: damo22: what was the problem? +damo22: EDID is not being read in linux +damo22: well it is, but it fails +damo22: probably because the VBT signature is missing from the oprom +fchmmr: oprom? +fchmmr: You mean native init code? +fchmmr: that it doesn't put the proper data in vbt +damo22: there is some special metadata in the oprom that native init doesnt put in +damo22: linux looks for it +damo22: thats how it knows where to read the EDID from +damo22: otherwise it uses a default address that could be wrong +damo22: in some cases it works +damo22: other cases like my X60t it fails +fchmmr: that would explain why "read-edid" utility deosn't work on natisev gfx at the mament +fchmmr: moment +fchmmr: Basstard` ^ + +damo22: fchmmr: phcoder wrote an experimental utility to parse some of the VBT tables from a vgarom +fchmmr: Did he share it with you? +damo22: yes +fchmmr: Did he upload it publicly? +damo22: http://review.coreboot.org/#/c/5842/ +fchmmr: Ok cool. +fchmmr: Do you think I should try it? + +damo22: you could use it to get more info from all your known boards, collect the parsed tables in a folder correctly named with the type of panel and the type of laptop +fchmmr: So as per #coreboot, my understanding is: move to new stolen memory address, find that metadata and how it's calculated and write that (memcpy/write32) in native init, get VBT tables parsed from ROM, replicate that in native gfx (stub code, just the addresses and pointers to the native init code) +fchmmr: Should this be run an a vgabios.bin, or on a system where vga bios is running (parse it in memory) ? +fchmmr: or both? +damo22: we havent got a solution for native init yet, but we do need to collect info from different models +damo22: to see how they compare +fchmmr: yes so, vgabios.bin (file) or running vga bios? +damo22: and also we can add it to devicetree.cb somehow later +damo22: preferably the running vgabios +fchmmr: ok +damo22: you can dump it with this command: +damo22: sudo dd if=/dev/mem bs=64k of=runningvga.bin skip=12 count=1 + +damo22: coreboot/util/intelvbttool + +damo22: gcc intelvbttool.c -o intelvbttool + +fchmmr: it would be good for you to run intelvbttool on vgabios.bin and runningvgabios.bin. (where vgabios.bin is extracted from lenovo rom, and runningvgabios.bin is dd'd from memory after it executed) +fchmmr: right? +fchmmr: (I will do the same) +fchmmr: just runningvgabios.bin ? +damo22: its useless in the factory bios +damo22: for the purposes of this test +fchmmr: ok +fchmmr: Can't hurt though (might be useful later). +damo22: not really, it might be modified at runtime and we wont know anything about it +damo22: we need final values +damo22: the rest is irrelevant +fchmmr: Yes. I was saying to run it on final dump, and factory dump. +fchmmr: but ok, i will only do it for final dump + +-- + +further discussion, continued in #coreboot: + +damo22:we could generate fake_vbt arrays for each model +damo22:fchmmr: whats the link to the vbt stuff again +fchmmr: http://review.coreboot.org/#/c/5396 for X230 +damo22:fchmmr: no on libreboot +fchmmr: I also added this to the notes at http://libreboot.org/howto.html#i945_vbt and http://libreboot.org/howto.html#intelvbttool_results for future reference. +fchmmr: on libreboot? I don't understand. +damo22:its possible that the VBT is modified by the vgarom depending on the panel it detects, assuming it can do that +damo22:only problem is, you need info from the VBT to know where to read the EDID, so how does the vgarom do it? +damo22:maybe its safe to assume that the EDID i2c will be the same for all panels +fchmmr: Might be hardcoded (what CareBear calls "stupid magic numbers") +damo22:so we should check all VBTs of the same laptop model and verify that the EDID i2c or ddc pin is the same for all panel types +fchmmr: Sorry, when you say VBT do you mean the runningvga.bin dump taken with dd when vgarom is running? +damo22:then we can hardcode that value into the coreboot devicetree.cb + +fchmmr: I see. it's an i2c bus that connects lvds/vga/vga out +kmalkki:damo22: in your opinion, where is this EDID eeprom physically located? +damo22:kmalkki: on the panel, or the transformer for the panel +kmalkki:damo22: what do you think is a transformer for the panel? +damo22:some circuitry that interfaces between the lvds connector and the panel itself +damo22:on the T60 there is a separate module afaik +damo22:on other models it might be incorporated into the panel idk +damo22:kmalkki: i believe that the VBT has information regarding which pin of the i2c to read for the EDID eeprom/storage +damo22:and it varies panel to panel +kmalkki:would it surprise you DDC signals are often not on the panel connector +damo22:hmm + +kmalkki:like, x60 schematics is easily available, do check on some alternative ways how these are done +damo22:ok + +kmalkki:damo22: for t60 however... LCD connector does have EDID lines +damo22:kmalkki: well it would be nice to have a general solution to EDID reading +damo22:i need to understand the wiring more and the VBT +kmalkki:DDC signals originate from the graphics device +kmalkki:that will be Intel for some, ATI for some T60 ? + +damo22:kmalkki: linux expects the VBT to be in the vgarom memory area, because it uses it to identify when a panel exists, so coreboot should provide VBT like a vendor bios ? + +damo22:when vgarom is used with coreboot there is no problem , but for native gfx init it doesnt always work +kmalkki:ok.. so we can ignore ATI case for now +damo22:kmalkki: is that because no native init will be done for that case? +damo22:so the vgarom will always work +kmalkki:ok.. so do you know VBT format? +damo22:kmalkki: phcoder has done lots of work on it already +kmalkki:and.. is there a problem in reading the EDID? +damo22:kmalkki: idk yet, i need to test +damo22:im having trouble building a coreboot rom that uses coreboots native framebuffer so i can see if it worked +damo22:linux reinits the gfx so its not a good test +damo22:but in any case, without the VBT, linux cant reinit my gfx +damo22:it fails to read the EDID +damo22:and without a dock, and cbmem console isnt working, i cant get the coreboot log to check what actually happened +kmalkki:what do you mean cbmem console not working? +damo22:kmalkki: i enabled it in menuconfig and built a rom, but when i run it on my X60t cbmem -c reports No console found +kmalkki:we should get it fixed then +kmalkki:paste your .config +damo22:http://paste.debian.net/101644/ + +kmalkki:git hash is from local tree.. it does work on master, right? +damo22:idk +damo22:i just cherry picked some native gfx patches +damo22:why would it affect cbmem console +kmalkki:mess up MTRRs or memory space mapping or UMA region... +damo22:ok +kmalkki:are those patches on gerrit you picked? +damo22:well i need these patches because that is why i need the console +damo22:yes +damo22:actually i did minor changes too +damo22::S +kmalkki:yep.. which patches exactly +damo22:5320 +damo22:then i changed 2 lines +damo22:a minor devicetree.cb line and this: +damo22:- intel_gma_init(conf, pci_read_config32(dev, 0x5c) & ~0xf, +damo22:+ intel_gma_init(conf, pci_read_config32(dev, 0x5c) & ~0xfffff, +kmalkki:ok.. also paste 'git log' so I find common hash from master +damo22:http://paste.debian.net/101645/ + +damo22:does anyone have better google xen than me, i cant seem to find a pdf of x60 schematics +Basstard' damo22: Do you mean this? http://www.computerservice.es/wp-content/uploads/2013/05/IBM-X60.pdf + +damo22:yep thanks +kmalkki:and now that I am awake, I see DDC signals on x60 LCD too +kmalkki:just.. no DDC or I2C in the signal name but EDID +damo22:yeah +damo22:what bus does the lvds connector use +damo22:is that i2c? +damo22:or should i say, how standard is that lcd connector they are using on the X60 +kmalkki:mainboard side is completely non-standard AFAIK +damo22:ohhh +kmalkki:panel side has a few variants on the LVDS input +damo22:ok +damo22:this is not easy to generalise then +damo22:SPWG_EDID_CLK and SPWG_EDID_DATA are the signals i found on the connector + +kmalkki:yes. and it looks like phcoder-screen has done all the work to read the EDID +damo22:yes but the address and pins required are stored in the VBT i think +kmalkki:solve your CBMEM console, please +damo22:yea +Basstard' damo22: Here's a cleaner one: http://pdf.datasheetarchive.com/indexerfiles/Datasheets-USER/DSAUPLD00006054.pdf +kmalkki:just verify 1315730 works +damo22:1315730? + +GNUtoo-irssi: fchmmr: hi, 0x58BF58BE works fine --- cool. (not related to these discussions, but GNUtoo is happy). + +<a name="gnutoo_gtt"></a> +GNUtoo-irssi: phcoder-screen: if you're still working on native GPU init for i945(it seems so), I've an observation: +GNUtoo-irssi: gtt is not setup correctly anymore with your versions, the kenrel complains +GNUtoo-irssi: it was with a replay version, so if you're still working on it it may be an usefull hint +GNUtoo-irssi: I've added the code that works inside git, so if you want/need it, ping me +phcoder-screen:damo22: yes +GNUtoo-irssi: beside the kernel warning, the effect is slow 3D with a 3.10 lts kernel +damo22:GNUtoo-irssi: can you push it as a notformerge? +GNUtoo-irssi: ok, good idea +GNUtoo-irssi: ah sigh, again... +GNUtoo-irssi: ! [remote rejected] HEAD -> refs/for/master/NOTFORMERGE-reference-i915_gpu_init-x60 (change 3992 closed) +GNUtoo-irssi: I'll change the IDs +damo22:GNUtoo-irssi: have you seen 5230? +damo22:5320* +phcoder-screen:damo22: rank 0 of either channel is configured but not rank 1 +GNUtoo-irssi: let me look +GNUtoo-irssi: I've tried some recent branch for the t60 +GNUtoo-irssi: it works well, beside the gtt init issue I just described +damo22:GNUtoo-irssi: given that you were working on 3992 which is closed are you able to rebase your changes on top of 5320? +damo22:hmm 3992 was merged +damo22:phcoder-screen: my dimms are dual rank +<stefanct> GNUtoo-irssi: i am not too familiar with gerrit, but that error message seems to indicate that you should not try to push 3992 again because it is already merged... rebasing the remains of your changes on top of that (or origin/master) should fix that *i guess* + +URL to topic: http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+topic:NOTFORMERGE-reference-i915_gpu_init-x60,n,z +(note: this is old code, not *directly* useful but might be useful later. put this somewhere else in howto.html later) + +GNUtoo-irssi: done, NOTFORMERGE-reference-i915_gpu_init-x60 +GNUtoo-irssi: yes, I've removed the Ids +GNUtoo-irssi: so they were regenerated +GNUtoo-irssi: the goal is not to rebase at all here +GNUtoo-irssi: that's a reference code +GNUtoo-irssi: it's not for merge either +GNUtoo-irssi: If I start modifying it, I'll need to spend time testing it again +GNUtoo-irssi: I've no time right now +GNUtoo-irssi: maybe I'll have later in theses two weeks +GNUtoo-irssi: but not right now +damo22:GNUtoo-irssi: mainboard/lenovo/x60/i915* has been removed in favour of northbridge/intel/i945/gma.c in 5320 +damo22:i thought you had changes for that +GNUtoo-irssi: yes, I know +GNUtoo-irssi: what I just pushed is a *reference code* where the GTT setup works +GNUtoo-irssi: it's old +GNUtoo-irssi: it's not meant to be merged +GNUtoo-irssi: it's not rebased +GNUtoo-irssi: it's just frozen code where it's known to work +GNUtoo-irssi: that's all + +damo22:ok +GNUtoo-irssi: it doesn't even handle backlight +GNUtoo-irssi: even with devmem2... +damo22:i'll see if i can find the gtt stuff and compare to 5320 +damo22:could be a one liner +damo22:physbase -> uma_memory_base+256*KiB +phcoder-screen:damo22: yes and rank 1 config failed +damo22:phcoder-screen: ok, so i'll get you that mchbar dump +phcoder-screen:damo22: no need yet. I found out that in another ram config my X230 fails as well. I'll investigate this first + +kmalkki:GNUtoo-irssi: please abandon the duplicates in your gerrit space +kmalkki:also any microcode files will not be removed until working copies are in 3rdparty/ + +kmalkki:we probably want to keep the old version in gerrit, with all the comments made previously + +damo22:kmalkki: all those patches are noformerge +damo22:not* +kmalkki:damo22: still they are duplicates of already reviewed patches +kmalkki:why the heck the new change-ids +damo22:maybe a git diff to a pastebin would have been better + +GNUtoo-irssi: ls +GNUtoo-irssi: oops +<uberushaximus> hunter2 +kmalkki:GNUtoo-irssi: please explain your motivation to push that stuff on gerrit +kmalkki:it is not even rebased to current but 6 months old HEAD +GNUtoo-irssi: GTT is setup badly on x60 +GNUtoo-irssi: with the recent changes from phcoder +GNUtoo-irssi: what I pushed is a version that is known to have the GTT setup correctly +GNUtoo-irssi: it's for reference +GNUtoo-irssi: so people working on i945 native GPU init would use it to fix that issue faster +GNUtoo-irssi: like diff both +GNUtoo-irssi: or something like that +GNUtoo-irssi: kmalkki: do you have a better description for the topic branch name that describe what I just said? +kmalkki:well gerrit is not for the purpose of storing references +kmalkki:most of those patches already had Change-IDs +kmalkki:now we have duplicates.. and comments can end up in either place +kmalkki:it was already a havoc with native init before +GNUtoo-irssi: ok, so instead I should remove that branch, and push on gitorious? +kmalkki:all of You working on it, try to work a setup that suits you all well +GNUtoo-irssi: briefly: it's for tracking a regression + +kmalkki:well I do not do i915 gfx stuff.. but clearly you have a lot of problems trying to keep and follow each others work +kmalkki:and what works and where the regressions have happened +PaulePanter: GNUtoo-irssi: Hi. Do you know if the amount memory reserved for i945 IGD is always constant or if that is configurable? +PaulePanter: GNUtoo-irssi: I did not see a table in the 3rd Gen datasheet. +PaulePanter: http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/3rd-gen-core-family-mobile-vol-2-datasheet.pdf +GNUtoo-irssi: PaulePanter: you mean the GSM? +GNUtoo-irssi: (Graphics stolen memory) +PaulePanter: GNUtoo-irssi: Yes. + +PaulePanter: Section 2.5.33 BDSM—Base Data of Stolen Memory Register +GNUtoo-irssi: If I remmeber well it's configurable, but we use the values advised by the datasheet +GNUtoo-irssi: which are derived from the ammount of RAM +PaulePanter: This register contains the base address of graphics data stolen DRAM memory. BIOS determines the base of graphics data stolen memory by subtracting the graphics data stolen memory size (PCI Device 0 offset 52 bits 7:4) from TOLUD (PCI Device 0 offset BCh bits 31:20). +PaulePanter: GNUtoo-irssi: Yes, I am unable to find the advised values. +damo22:PaulePanter: are you sure thats the right datasheet for the cpu inside the X60? + +GNUtoo-irssi: ok +GNUtoo-irssi: I can look +PaulePanter: damo22: Not 100 %. +damo22:afaik, BSDM is something kinky in the core iX processors +GNUtoo-irssi: uma_size = 1024; +PaulePanter: Chris Wilson from the Intel graphics Linux driver team said that BDSM ist incorrectly set up. +PaulePanter: … on the i945. +PaulePanter: … by coreboot. +PaulePanter: This is Volume 2 of the Datasheet for the following products: +PaulePanter: Mobile 3rd Generation Intel ® CoreTM processor family +GNUtoo-irssi: in pci_domain_set_resources in northbridge.c +PaulePanter: Mobile Intel ® Pentium ® processor family +GNUtoo-irssi: ok +PaulePanter: Mobile Intel ® Celeron ® processor family +PaulePanter: GNUtoo-irssi: Thanks. So it is constant for now. +PaulePanter: GNUtoo-irssi: So just 1 MB graphics memory? + +damo22:i dont remember him mentioning BDSM in the bug report, but he did say the GTT was incorrectly set up? +damo22:graphics stolen stuff +GNUtoo-irssi: no it's not +GNUtoo-irssi: read the function +PaulePanter: “Stolen memory has been set up incorrectly by coreboot.” +PaulePanter: GNUtoo-irssi: Ok. +PaulePanter: GNUtoo-irssi: No idea, if you are aware of https://bugs.freedesktop.org/show_bug.cgi?id=79038 . +GNUtoo-irssi: http://paste.debian.net/101662/ +[ 0.764084] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input3 +[ 0.771023] pci 0000:00:00.0: Intel 945GM Chipset +[ 0.771075] pci 0000:00:00.0: detected gtt size: 262144K total, 262144K mappable +[ 0.771669] pci 0000:00:00.0: detected 8192K stolen memory +[ 0.771738] [drm] Memory usable by graphics device = 256M +[ 0.772124] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). +[ 0.772126] [drm] Driver supports precise vblank timestamp query. +[ 0.772133] i915 0000:00:02.0: Invalid ROM contents +[ 0.772141] [drm] failed to find VBIOS tables +[ 0.772192] [drm] GPU crash dump saved to /sys/class/drm/card0/error +[ 0.772196] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. +[ 0.772198] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel +[ 0.772200] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. +[ 0.772202] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. +[ 0.772207] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem +[ 0.772217] i915: render error detected, EIR: 0x00000010 +[ 0.772224] i915: page table error +[ 0.772227] i915: PGTBL_ER: 0x00000012 +[ 0.772233] [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking +[ 0.772247] i915: render error detected, EIR: 0x00000010 +[ 0.772252] i915: page table error +[ 0.772255] i915: PGTBL_ER: 0x00000012 +[ 0.924707] [drm] initialized overlay support +[ 1.126501] fbcon: inteldrmfb (fb0) is primary device +[ 1.360027] tsc: Refined TSC clocksource calibration: 1828.749 MHz +[ 1.482148] Console: switching to colour frame buffer device 175x65 +[ 1.490507] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device +[ 1.490510] i915 0000:00:02.0: registered panic notifier +[ 1.490522] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 +[ 1.491931] console [netcon0] enabled +[ 1.491933] netconsole: network logging started +[ 1.494021] ACPI: bus type USB registered +GNUtoo-irssi: that is the regression ^^^^ +GNUtoo-irssi: See PGTBL_ER +GNUtoo-irssi: The bits are documented +damo22:i have compared GNUtoo-irssi's patchset with the 5320 stuff that phcoder did, and i found that 1 line needs to be changed +GNUtoo-irssi: (I don't remember where, probably in the datasheet that applies to the more recent GPUs (sic)) + +damo22:its the base address of the gma init call + +PaulePanter: damo22: Are you going to push a patch for testing? + +damo22:but in order for it to work you need vgarom with native init, it doesnt run the rom just uses it for VBT +PaulePanter: damo22: I still not see how that should fix the error, but we’ll see. +damo22:how do i squash my commits into one patch that can be applied to 5320? +PaulePanter: damo22: Is that patch really dependent on 5320? I thought it is also needed for the current native graphics init in the tree? + +PaulePanter: damo22: `git rebase -i +PaulePanter: ` +PaulePanter: damo22: git rebase -i commit-hash-of-5320 +damo22:thanks +PaulePanter: damo22: To squash you will need to change `pick` to `f` or `s` for `fixup` or `squash`. + +damo22:i have a patch that could be tested on X60: http://review.coreboot.org/#/c/5868/ +PaulePanter: damo22: On Nehalem: +PaulePanter: src/northbridge/intel/nehalem/gma.c: intel_gma_init(conf, gtt_res->base, physbase, pio_res->base, +PaulePanter: src/northbridge/intel/nehalem/gma.c- lfb_res->base); +damo22:PaulePanter: i fail to see relevance of nehalem in i945 +PaulePanter: damo22: Hopefully the code can be written in a way that common paths are written the same. +PaulePanter: damo22: Let’s first see if the patch fixes it. + +PaulePanter: damo22: By the way, which datasheet do you think is correct for the Intel 945 IGD in the Lenovo T60 and X60? + +damo22:whichever datasheet includes 945PM (Calistoga) Graphics +damo22:is it PM or GM? +PaulePanter: damo22: I thought GM. +damo22:PM has no integrated graphics so it must be GM +PaulePanter: damo22: Document Number: 309219-006 +damo22:PaulePanter: this must be the datasheet: http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/mobile-945-express-chipset-datasheet.pdf + +PaulePanter: Mobile Intel® 945 Express Chipset Family +PaulePanter: damo22: ;-) + +damo22:309219-006 is correct +PaulePanter: Graphics Stolen Memory and TSEG are within DRAM space defined under TOLUD. From +kmalkki:PaulePanter: did you go through the list of patches in your gerrit space that I suggested needed rebase? +PaulePanter: the top of low used DRAM, (G)MCH claims 1 to 64 MBs of DRAM for internal graphics if +PaulePanter: enabled. +PaulePanter: kmalkki: I thought I did go through most of them. +kmalkki:do you have the list +kmalkki:I did not keep copy :/ +kmalkki:5388 +kmalkki:that is AMR +PaulePanter: kmalkki: Don’t waste you time with it. I have a copy of your list somewhere and will go through it in the next days. +kmalkki:PaulePanter: +1 5388 +damo22:PaulePanter: its an integrated GMA 950 afaik +idwer: oh... 5388 has no priority whatsover to me +idwer: not anymore ;) + +damo22:does GM45 support in coreboot have ddr2 AND ddr3 support? + +damo22:well that means X200 could be ported with ME disabled +phcoder-screen:damo22: that's my next fun project after raminit for ivy. +* thomasg_ is now known as thomasg + +damo22:fchmmr: LTN150XG-L08 is my T60 EDID string (for his T60 15" -- this is already noted below in intelvbttool results) + +fchmmr: damo22: ok, i should test 5868? I understand it puts the vgarom inside but without running it (just for getting VBT tables) but latre we could replace it with something like what the X230 "Deploy VBT" does +damo22:yeah +fchmmr: Let me read backlog... +damo22:fchmmr: you dont need backlog, everything you need is in the 5868 commit +fchmmr: how did your X60t unbricking go, damo22? +damo22:havent bothered finding my screwdrivers yet +fchmmr: I need to.... tidy myself up. Back in an hour or so. +fchmmr: damo22: upload a ROM for me, with 5868 and grub payload +fchmmr: I'll test it for you +damo22:im not good with grub payloads +damo22:i can give you one with seabios +fchmmr: ok give me that, +fchmmr: also hm ok, give me your .config. I'll add grub myself +damo22:ok +damo22:fchmmr: http://paste.debian.net/plain/101692 +# +# Automatically generated make config: don't edit +# coreboot version: 4.0-5614-gdb77532 +# Mon May 26 00:11:44 2014 +# + +# +# General setup +# +CONFIG_EXPERT=y +CONFIG_LOCALVERSION="" +CONFIG_CBFS_PREFIX="fallback" +CONFIG_COMPILER_GCC=y +# CONFIG_COMPILER_LLVM_CLANG is not set +# CONFIG_SCANBUILD_ENABLE is not set +# CONFIG_CCACHE is not set +# CONFIG_SCONFIG_GENPARSER is not set +CONFIG_USE_OPTION_TABLE=y +CONFIG_COMPRESS_RAMSTAGE=y +CONFIG_INCLUDE_CONFIG_FILE=y +CONFIG_EARLY_CBMEM_INIT=y +# CONFIG_DYNAMIC_CBMEM is not set +# CONFIG_COLLECT_TIMESTAMPS is not set +# CONFIG_USE_BLOBS is not set +# CONFIG_COVERAGE is not set + +# +# Mainboard +# +# CONFIG_VENDOR_AAEON is not set +# CONFIG_VENDOR_ABIT is not set +# CONFIG_VENDOR_ADLINK is not set +# CONFIG_VENDOR_ADVANSUS is not set +# CONFIG_VENDOR_ADVANTECH is not set +# CONFIG_VENDOR_AMD is not set +# CONFIG_VENDOR_AOPEN is not set +# CONFIG_VENDOR_ARIMA is not set +# CONFIG_VENDOR_ARTECGROUP is not set +# CONFIG_VENDOR_ASI is not set +# CONFIG_VENDOR_ASROCK is not set +# CONFIG_VENDOR_ASUS is not set +# CONFIG_VENDOR_A_TREND is not set +# CONFIG_VENDOR_AVALUE is not set +# CONFIG_VENDOR_AXUS is not set +# CONFIG_VENDOR_AZZA is not set +# CONFIG_VENDOR_BACHMANN is not set +# CONFIG_VENDOR_BCOM is not set +# CONFIG_VENDOR_BIFFEROS is not set +# CONFIG_VENDOR_BIOSTAR is not set +# CONFIG_VENDOR_BROADCOM is not set +# CONFIG_VENDOR_COMPAQ is not set +# CONFIG_VENDOR_CUBIETECH is not set +# CONFIG_VENDOR_DIGITALLOGIC is not set +# CONFIG_VENDOR_DMP is not set +# CONFIG_VENDOR_EAGLELION is not set +# CONFIG_VENDOR_ECS is not set +# CONFIG_VENDOR_EMULATION is not set +# CONFIG_VENDOR_GETAC is not set +# CONFIG_VENDOR_GIGABYTE is not set +# CONFIG_VENDOR_GIZMOSPHERE is not set +# CONFIG_VENDOR_GOOGLE is not set +# CONFIG_VENDOR_HP is not set +# CONFIG_VENDOR_IBASE is not set +# CONFIG_VENDOR_IBM is not set +# CONFIG_VENDOR_IEI is not set +# CONFIG_VENDOR_INTEL is not set +# CONFIG_VENDOR_IWAVE is not set +# CONFIG_VENDOR_IWILL is not set +# CONFIG_VENDOR_JETWAY is not set +# CONFIG_VENDOR_KONTRON is not set +# CONFIG_VENDOR_LANNER is not set +CONFIG_VENDOR_LENOVO=y +# CONFIG_VENDOR_LINUTOP is not set +# CONFIG_VENDOR_LIPPERT is not set +# CONFIG_VENDOR_MITAC is not set +# CONFIG_VENDOR_MSI is not set +# CONFIG_VENDOR_NEC is not set +# CONFIG_VENDOR_NEWISYS is not set +# CONFIG_VENDOR_NOKIA is not set +# CONFIG_VENDOR_NVIDIA is not set +# CONFIG_VENDOR_PCENGINES is not set +# CONFIG_VENDOR_RCA is not set +# CONFIG_VENDOR_RODA is not set +# CONFIG_VENDOR_SAMSUNG is not set +# CONFIG_VENDOR_SIEMENS is not set +# CONFIG_VENDOR_SOYO is not set +# CONFIG_VENDOR_SUNW is not set +# CONFIG_VENDOR_SUPERMICRO is not set +# CONFIG_VENDOR_TECHNEXION is not set +# CONFIG_VENDOR_TECHNOLOGIC is not set +# CONFIG_VENDOR_TELEVIDEO is not set +# CONFIG_VENDOR_TI is not set +# CONFIG_VENDOR_THOMSON is not set +# CONFIG_VENDOR_TRAVERSE is not set +# CONFIG_VENDOR_TYAN is not set +# CONFIG_VENDOR_VIA is not set +# CONFIG_VENDOR_WINENT is not set +# CONFIG_VENDOR_WYSE is not set +CONFIG_BOARD_SPECIFIC_OPTIONS=y +CONFIG_MAINBOARD_DIR="lenovo/x60" +CONFIG_MAINBOARD_PART_NUMBER="ThinkPad X60 / X60s" +CONFIG_IRQ_SLOT_COUNT=18 +CONFIG_MAINBOARD_VENDOR="Lenovo" +CONFIG_MAX_CPUS=2 +CONFIG_RAMTOP=0x200000 +CONFIG_HEAP_SIZE=0x4000 +CONFIG_RAMBASE=0x100000 +CONFIG_VGA_BIOS_ID="8086,27a2" +CONFIG_DRIVERS_PS2_KEYBOARD=y +CONFIG_ONBOARD_VGA_IS_PRIMARY=y +CONFIG_VGA_BIOS=y +# CONFIG_CONSOLE_POST is not set +# CONFIG_UDELAY_IO is not set +CONFIG_DCACHE_RAM_BASE=0xffdf8000 +CONFIG_DCACHE_RAM_SIZE=0x8000 +CONFIG_SERIAL_CPU_INIT=y +CONFIG_ACPI_SSDTX_NUM=0 +CONFIG_VGA_BIOS_FILE="vgabios.bin" +# CONFIG_PCI_64BIT_PREF_MEM is not set +CONFIG_MMCONF_BASE_ADDRESS=0xf0000000 +CONFIG_ID_SECTION_OFFSET=0x80 +# CONFIG_BOARD_EMULATION_QEMU_X86_I440FX is not set +# CONFIG_BOARD_EMULATION_QEMU_X86_Q35 is not set +# CONFIG_BOARD_EMULATION_QEMU_ARMV7 is not set +CONFIG_STACK_SIZE=0x1000 +CONFIG_XIP_ROM_SIZE=0x10000 +CONFIG_MMCONF_SUPPORT_DEFAULT=y +# CONFIG_VGA is not set +CONFIG_BOARD_LENOVO_X60=y +# CONFIG_BOARD_LENOVO_X201 is not set +# CONFIG_BOARD_LENOVO_X230 is not set +# CONFIG_BOARD_LENOVO_T60 is not set +CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="LENOVO" +CONFIG_SEABIOS_PS2_TIMEOUT=3000 +CONFIG_MAINBOARD_VERSION="1.0" +CONFIG_CPU_ADDR_BITS=32 +CONFIG_CACHE_ROM_SIZE_OVERRIDE=0 +# CONFIG_POWER_BUTTON_FORCE_ENABLE is not set +CONFIG_LOGICAL_CPUS=y +CONFIG_IOAPIC=y +CONFIG_SMP=y +CONFIG_DEFAULT_CONSOLE_LOGLEVEL=8 +# CONFIG_USBDEBUG is not set +CONFIG_MAXIMUM_SUPPORTED_FREQUENCY=0 +CONFIG_BOARD_ROMSIZE_KB_2048=y +# CONFIG_COREBOOT_ROMSIZE_KB_64 is not set +# CONFIG_COREBOOT_ROMSIZE_KB_128 is not set +# CONFIG_COREBOOT_ROMSIZE_KB_256 is not set +# CONFIG_COREBOOT_ROMSIZE_KB_512 is not set +# CONFIG_COREBOOT_ROMSIZE_KB_1024 is not set +CONFIG_COREBOOT_ROMSIZE_KB_2048=y +# CONFIG_COREBOOT_ROMSIZE_KB_4096 is not set +# CONFIG_COREBOOT_ROMSIZE_KB_8192 is not set +# CONFIG_COREBOOT_ROMSIZE_KB_12288 is not set +# CONFIG_COREBOOT_ROMSIZE_KB_16384 is not set +CONFIG_COREBOOT_ROMSIZE_KB=2048 +CONFIG_ROM_SIZE=0x200000 +CONFIG_MAINBOARD_SERIAL_NUMBER="123456789" +CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME="ThinkPad X60 / X60s" +CONFIG_ARCH_X86=y +# CONFIG_ARCH_ARMV7 is not set + +# +# Architecture (x86) +# +CONFIG_X86_ARCH_OPTIONS=y +CONFIG_AP_IN_SIPI_WAIT=y +# CONFIG_SIPI_VECTOR_IN_ROM is not set +CONFIG_MAX_REBOOT_CNT=3 +CONFIG_NUM_IPI_STARTS=2 +CONFIG_X86_BOOTBLOCK_SIMPLE=y +# CONFIG_X86_BOOTBLOCK_NORMAL is not set +CONFIG_BOOTBLOCK_SOURCE="bootblock_simple.c" +# CONFIG_UPDATE_IMAGE is not set +# CONFIG_ROMCC is not set +CONFIG_PC80_SYSTEM=y +CONFIG_BOOTBLOCK_NORTHBRIDGE_INIT="northbridge/intel/i945/bootblock.c" +CONFIG_HAVE_CMOS_DEFAULT=y +CONFIG_CMOS_DEFAULT_FILE="src/mainboard/$(MAINBOARDDIR)/cmos.default" +CONFIG_BOOTBLOCK_SOUTHBRIDGE_INIT="southbridge/intel/i82801gx/bootblock.c" +CONFIG_IOAPIC_INTERRUPTS_ON_FSB=y +# CONFIG_IOAPIC_INTERRUPTS_ON_APIC_SERIAL_BUS is not set +CONFIG_HPET_ADDRESS=0xfed00000 +CONFIG_HAVE_ARCH_MEMSET=y +CONFIG_HAVE_ARCH_MEMCPY=y +CONFIG_HAVE_ARCH_MEMMOVE=y +# CONFIG_MAINBOARD_HAS_CHROMEOS is not set + +# +# Chipset +# + +# +# CPU +# +CONFIG_SOCKET_SPECIFIC_OPTIONS=y +# CONFIG_CPU_AMD_AGESA is not set +CONFIG_HAVE_INIT_TIMER=y +CONFIG_HIGH_SCRATCH_MEMORY_SIZE=0x0 +CONFIG_CPU_INTEL_MODEL_6EX=y +CONFIG_CPU_INTEL_MODEL_6FX=y +CONFIG_SMM_TSEG_SIZE=0 +CONFIG_CPU_INTEL_SOCKET_MFCPGA478=y +CONFIG_SSE2=y +# CONFIG_CPU_INTEL_FIRMWARE_INTERFACE_TABLE is not set +# CONFIG_CPU_INTEL_TURBO_NOT_PACKAGE_SCOPED is not set +CONFIG_UDELAY_LAPIC=y +CONFIG_LAPIC_MONOTONIC_TIMER=y +# CONFIG_UDELAY_TSC is not set +# CONFIG_UDELAY_TIMER2 is not set +# CONFIG_TSC_CALIBRATE_WITH_IO is not set +# CONFIG_TSC_SYNC_LFENCE is not set +CONFIG_TSC_SYNC_MFENCE=y +# CONFIG_SMM_TSEG is not set +# CONFIG_SMM_MODULES is not set +# CONFIG_X86_AMD_FIXED_MTRRS is not set +# CONFIG_PARALLEL_MP is not set +# CONFIG_BACKUP_DEFAULT_SMM_REGION is not set +CONFIG_CACHE_AS_RAM=y +CONFIG_AP_SIPI_VECTOR=0xfffff000 +CONFIG_MMX=y +CONFIG_SSE=y +CONFIG_SUPPORT_CPU_UCODE_IN_CBFS=y +CONFIG_CPU_MICROCODE_ADDED_DURING_BUILD=y +CONFIG_CPU_MICROCODE_CBFS_GENERATE=y +# CONFIG_CPU_MICROCODE_CBFS_EXTERNAL is not set +# CONFIG_CPU_MICROCODE_CBFS_NONE is not set + +# +# Northbridge +# +CONFIG_VIDEO_MB=0 +# CONFIG_NORTHBRIDGE_AMD_AGESA is not set +# CONFIG_AMD_NB_CIMX is not set +# CONFIG_NORTHBRIDGE_AMD_CIMX_RD890 is not set +CONFIG_NORTHBRIDGE_SPECIFIC_OPTIONS=y +CONFIG_NORTHBRIDGE_INTEL_I945=y +# CONFIG_NORTHBRIDGE_INTEL_SUBTYPE_I945GC is not set +CONFIG_NORTHBRIDGE_INTEL_SUBTYPE_I945GM=y +CONFIG_CHANNEL_XOR_RANDOMIZATION=y +# CONFIG_OVERRIDE_CLOCK_DISABLE is not set +# CONFIG_CHECK_SLFRCS_ON_RESUME is not set +CONFIG_CBFS_SIZE=0x200000 +CONFIG_HPET_MIN_TICKS=0x80 +CONFIG_MAX_PIRQ_LINKS=4 + +# +# Southbridge +# +CONFIG_EHCI_BAR=0xfef00000 +# CONFIG_AMD_SB_CIMX is not set +# CONFIG_SOUTHBRIDGE_AMD_CIMX_SB800 is not set +# CONFIG_SOUTHBRIDGE_AMD_CIMX_SB900 is not set +CONFIG_AMD_SB_SPI_TX_LEN=4 +# CONFIG_SPI_FLASH is not set +CONFIG_SOUTHBRIDGE_INTEL_COMMON=y +CONFIG_SOUTHBRIDGE_INTEL_I82801GX=y +CONFIG_SOUTHBRIDGE_RICOH_RL5C476=y + +# +# Super I/O +# +CONFIG_SUPERIO_NSC_PC87382=y +CONFIG_SUPERIO_NSC_PC87392=y + +# +# Embedded Controllers +# +CONFIG_EC_ACPI=y +CONFIG_EC_LENOVO_H8=y +CONFIG_H8_DOCK_EARLY_INIT=y +CONFIG_EC_LENOVO_PMH7=y + +# +# SoC +# + +# +# Devices +# +CONFIG_MAINBOARD_HAS_NATIVE_VGA_INIT=y +# CONFIG_MAINBOARD_HAS_NATIVE_VGA_INIT_TEXTMODECFG is not set +CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT=y +# CONFIG_VGA_ROM_RUN is not set +# CONFIG_ON_DEVICE_ROM_RUN is not set +# CONFIG_MULTIPLE_VGA_ADAPTERS is not set +CONFIG_PCI=y +# CONFIG_HYPERTRANSPORT_PLUGIN_SUPPORT is not set +CONFIG_PCIX_PLUGIN_SUPPORT=y +CONFIG_PCIEXP_PLUGIN_SUPPORT=y +CONFIG_AGP_PLUGIN_SUPPORT=y +CONFIG_CARDBUS_PLUGIN_SUPPORT=y +# CONFIG_AZALIA_PLUGIN_SUPPORT is not set +# CONFIG_PCIEXP_COMMON_CLOCK is not set +# CONFIG_PCIEXP_ASPM is not set +CONFIG_PCI_BUS_SEGN_BITS=0 + +# +# VGA BIOS +# + +# +# Display +# + +# +# PXE ROM +# +# CONFIG_PXE_ROM is not set +CONFIG_SUBSYSTEM_VENDOR_ID=0x0000 +CONFIG_SUBSYSTEM_DEVICE_ID=0x0000 + +# +# Generic Drivers +# +# CONFIG_DRIVERS_I2C_RTD2132 is not set +CONFIG_DRIVERS_ICS_954309=y +# CONFIG_INTEL_DP is not set +# CONFIG_INTEL_DDI is not set +CONFIG_INTEL_EDID=y +# CONFIG_IPMI_KCS is not set +# CONFIG_DRIVER_MAXIM_MAX77686 is not set +# CONFIG_DRIVERS_OXFORD_OXPCIE is not set +# CONFIG_DRIVER_PARADE_PS8625 is not set +# CONFIG_TPM is not set +# CONFIG_RTL8168_ROM_DISABLE is not set +# CONFIG_DRIVERS_SIL_3114 is not set +# CONFIG_DRIVER_TI_TPS65090 is not set +CONFIG_HAVE_UART_IO_MAPPED=y +# CONFIG_HAVE_UART_MEMORY_MAPPED is not set +# CONFIG_HAVE_UART_SPECIAL is not set +# CONFIG_DRIVER_XPOWERS_AXP209 is not set +CONFIG_MMCONF_SUPPORT=y + +# +# Console +# +CONFIG_EARLY_CONSOLE=y +CONFIG_SQUELCH_EARLY_SMP=y +CONFIG_CONSOLE_SERIAL=y +CONFIG_CONSOLE_SERIAL8250=y +CONFIG_CONSOLE_SERIAL_COM1=y +# CONFIG_CONSOLE_SERIAL_COM2 is not set +# CONFIG_CONSOLE_SERIAL_COM3 is not set +# CONFIG_CONSOLE_SERIAL_COM4 is not set +CONFIG_TTYS0_BASE=0x3f8 +CONFIG_CONSOLE_SERIAL_115200=y +# CONFIG_CONSOLE_SERIAL_57600 is not set +# CONFIG_CONSOLE_SERIAL_38400 is not set +# CONFIG_CONSOLE_SERIAL_19200 is not set +# CONFIG_CONSOLE_SERIAL_9600 is not set +CONFIG_TTYS0_BAUD=115200 +CONFIG_TTYS0_LCS=3 +# CONFIG_SPKMODEM is not set +CONFIG_HAVE_USBDEBUG=y +# CONFIG_HAVE_USBDEBUG_OPTIONS is not set +# CONFIG_CONSOLE_NE2K is not set +# CONFIG_CONSOLE_CBMEM is not set +CONFIG_DEFAULT_CONSOLE_LOGLEVEL_8=y +# CONFIG_DEFAULT_CONSOLE_LOGLEVEL_7 is not set +# CONFIG_DEFAULT_CONSOLE_LOGLEVEL_6 is not set +# CONFIG_DEFAULT_CONSOLE_LOGLEVEL_5 is not set +# CONFIG_DEFAULT_CONSOLE_LOGLEVEL_4 is not set +# CONFIG_DEFAULT_CONSOLE_LOGLEVEL_3 is not set +# CONFIG_DEFAULT_CONSOLE_LOGLEVEL_2 is not set +# CONFIG_DEFAULT_CONSOLE_LOGLEVEL_1 is not set +# CONFIG_DEFAULT_CONSOLE_LOGLEVEL_0 is not set +# CONFIG_NO_POST is not set +# CONFIG_CMOS_POST is not set +CONFIG_IO_POST=y +CONFIG_IO_POST_PORT=0x80 +CONFIG_HAVE_ACPI_RESUME=y +# CONFIG_HAVE_ACPI_SLIC is not set +CONFIG_HAVE_HARD_RESET=y +CONFIG_HAVE_MONOTONIC_TIMER=y +# CONFIG_TIMER_QUEUE is not set +CONFIG_HAVE_OPTION_TABLE=y +# CONFIG_PIRQ_ROUTE is not set +CONFIG_HAVE_SMI_HANDLER=y +# CONFIG_PCI_IO_CFG_EXT is not set +CONFIG_USE_WATCHDOG_ON_BOOT=y +CONFIG_GFXUMA=y +# CONFIG_RELOCATABLE_MODULES is not set +# CONFIG_HAVE_REFCODE_BLOB is not set +CONFIG_HAVE_ACPI_TABLES=y +CONFIG_HAVE_MP_TABLE=y +CONFIG_HAVE_PIRQ_TABLE=y + +# +# System tables +# +CONFIG_GENERATE_ACPI_TABLES=y +CONFIG_GENERATE_MP_TABLE=y +CONFIG_GENERATE_PIRQ_TABLE=y +CONFIG_GENERATE_SMBIOS_TABLES=y + +# +# Payload +# +# CONFIG_PAYLOAD_NONE is not set +# CONFIG_PAYLOAD_ELF is not set +# CONFIG_PAYLOAD_LINUX is not set +CONFIG_PAYLOAD_SEABIOS=y +# CONFIG_PAYLOAD_FILO is not set +# CONFIG_PAYLOAD_GRUB2 is not set +# CONFIG_PAYLOAD_TIANOCORE is not set +CONFIG_SEABIOS_STABLE=y +# CONFIG_SEABIOS_MASTER is not set +CONFIG_PAYLOAD_FILE="$(obj)/seabios/out/bios.bin.elf" +CONFIG_COMPRESSED_PAYLOAD_LZMA=y + +# +# Debugging +# +# CONFIG_GDB_STUB is not set +# CONFIG_DEBUG_CBFS is not set +CONFIG_HAVE_DEBUG_RAM_SETUP=y +# CONFIG_DEBUG_RAM_SETUP is not set +# CONFIG_HAVE_DEBUG_CAR is not set +# CONFIG_DEBUG_PIRQ is not set +# CONFIG_HAVE_DEBUG_SMBUS is not set +# CONFIG_DEBUG_SMI is not set +# CONFIG_DEBUG_SMM_RELOCATION is not set +# CONFIG_DEBUG_MALLOC is not set +# CONFIG_DEBUG_ACPI is not set +# CONFIG_TRACE is not set +# CONFIG_ENABLE_APIC_EXT_ID is not set +CONFIG_WARNINGS_ARE_ERRORS=y +# CONFIG_POWER_BUTTON_DEFAULT_ENABLE is not set +# CONFIG_POWER_BUTTON_DEFAULT_DISABLE is not set +# CONFIG_POWER_BUTTON_FORCE_DISABLE is not set +# CONFIG_POWER_BUTTON_IS_OPTIONAL is not set + +damo22:you need to still add the vgabios filename +damo22:CONFIG_VGA_BIOS_FILE="vgabios.bin" is the current setting +damo22:# CONFIG_CONSOLE_CBMEM is not set woops + +fchmmr: damo22 » register "gpu_lvds_is_dual_channel" = "1" +fchmmr: on x60/devicetree.cb +damo22:fchmmr: well check your VBT i think its correct though +fchmmr: so 0 was wrong? +damo22:it might depend on panel + +fchmmr: Oh +fchmmr: I get it now. +fchmmr: I didn't see any code in 5868 that executes anything from the vgarom but, +fchmmr: you set coreboot to load it into memory, but not execute it. +fchmmr: I thought "load" only meant put it in cbfs +fchmmr: is this a correct assessment? +fchmmr: To let kernel find vbt tables. +fchmmr: And then we "fake" it later (withotu vga rom loaded). +fchmmr: damo22: are you testing 5868 on your X60t? +damo22:fchmmr: its to make linux kernel detect lvds after native init, but if you can also test coreboot native framebuffer with grub too, that would be handy + +fchmmr: So, vgarom has nothing to do with that patch. +fchmmr: ? +fchmmr: All I see is a change of stolen memory address, and the backlight values added +damo22:fchmmr: its tricky because the final vgabios in memory changes depending on the panel, because vgarom is self modifying + +fchmmr: So should I include the vgarunning.bin instead of vgabios.bin ? +damo22:yes + +damo22:fchmmr: if you can load grub as payload and you see something, its a success +fchmmr: damo22: the problem is, without that patch I just use 5320 as-is, and I see grub as payload already. +fchmmr: Hence my question above. +damo22:fchmmr: also, if you can boot into linux after that and dont get any error messages from drm module, its a double success +fchmmr: Which error messages (besides "Invalid ROM contents") am I looking for? +damo22:fchmmr: stuff like, page fault +fchmmr: And should I enable any specific debugging options (such as drm.debug=0x06) +damo22:yes that would help +fchmmr: Ok: which logs do you want? +fchmmr: I'll upload it for your reference +damo22:fchmmr: kernel boot log and Xorg.0.log, coreboot log if possible +fchmmr: probably kern.log and Xorg.0.log +fchmmr: coreboot log is possible, i have dock. +fchmmr: anything else? +damo22:that is all, thanks +fchmmr: ok. will do. + +fchmmr: damo22: I could test this on T60 aswell by cherry picking 5345, right? +damo22:fchmmr: idk +fchmmr: (and addinf backlight value to deivcetree) +fchmmr: We should devise a way to test this on T60 aswell. +damo22:fchmmr: lets just see if the x60 fix works + +damo22:it still needs work if the test passes +fchmmr: Ok but, you just have that one line changed in gma.c, and backlight value changed it x60/devicetree.cb +damo22:yes +damo22:phcoder did most of the work +fchmmr: So, I could run this same test on T60 by cherry picking 5345 on top of 5868, changing t60/devicetree.cb's backlight value and including T60 runningvga.bin and having that load (but not execute) +damo22:its a small bug i think +fchmmr: I will do that above, after X60 is tested. +damo22:fchmmr: youre always talking about more and more combinations of tests, lets just get one right +fchmmr: Yes. Just a thought. We'll test X60 exclusively. T60 can easily be tested later. +fchmmr: Ok..... back soon. I'll get you the results you wanted. I'll be using 3.14.4 (the one samnob made). +damo22:thanks + +fchmmr: We should do this with the latest runningvga.bin (from extracting with dd on the latest vgabios.bin) +fchmmr: My one is older +damo22:fchmmr: version number of vgabios is irrelevant if it was taken from a lenovo bios that used to run on your machine, and since pulled from ram +damo22:ie, it should have the correct VBT values +damo22:for your machine + + + +</pre> +</p> + |