coreboot November 2014

coreboot@coreboot.org

43 participants
82 discussions

转发: Coreboot with Intel FSP on BayleyBay Help
by mengqiaohui＠mindray.com 04 Nov '14

04 Nov '14

Hi，expert. Now Coreboot with Intel FSP ,can load Linux on my BayleyBay.I tried to use Seabios 1.7.5 load Win7 64bit,but i got a blue screen issue,stop at A5(0x1000,0x000,0x105a23a1,0x100).Obviously I think this trouble was called by ACPI.Am I wrong? So I modify src/soc/intel/fsp_baytrail/acpi/southcluster.asl as follows.My serial ports message is attached.Then I can load Win7 64bit normaly,but the ACPI Table is not completed. Scope (\_SB) { // GPIO Devices #include "gpio.asl" #if INCLUDE_LPSS // LPSS Devices #include "lpss.asl" #endif #if INCLUDE_SCC // SCC Devices //#include "scc.asl" -----Commented out code 1 #endif #if INCLUDE_LPE // LPE Device //#include "lpe.asl"-----Commented out code 2 #endif } But I'm not quite understand ,I change the asl code is how to take effect?Looking for help to load win7 64bit normaly.How to modify the ACPI asl coed? Thanks in advance. This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of such information or any action taken in reliance on this e-mail is strictly prohibited. 发件人: Werner Zeh via coreboot <coreboot(a)coreboot.org> 收件人: Gailu Singh <gailu96(a)gmail.com>, coreboot(a)coreboot.org 日期: 2014-11-04 03:24 主题: Re: [coreboot] Coreboot with Intel FSP on BayleyBay Help 发件人： "coreboot" <coreboot-bounces(a)coreboot.org> Hi. Now you have coreboot running. coreboot searches for FSP, finds it and executes the first call into it. FSP returns with an error and what you see is this (taken from src/drivers/intel/fsp/cache_as_ram.inc): /* * Failures for postcode 0xBB - failed in the FSP: * * 0x00 - FSP_SUCCESS: Temp RAM was initialized successfully. * 0x02 - FSP_INVALID_PARAMETER: Input parameters are invalid. * 0x0E - FSP_NOT_FOUND: No valid microcode was found in the microcode region. * 0x03 - FSP_UNSUPPORTED: The FSP calling conditions were not met. * 0x07 - FSP_DEVICE_ERROR: Temp RAM initialization failed * 0x14 - FSP_ALREADY_STARTED: Temp RAM initialization has been invoked */ So what you actually see is error code 0x07 from FSP. This can mean that your CPU is not supported by this FSP version. If you use GOLD1 or GOLD2, then a D0 stepping is not supported and if you have in advance a D0 stepping installed on your board, than you have to use GOLD3 FSP release as it was already mentioned. I had the same issue and it was due to missing D0-Support in GOLD1 release. So, I would suggest to try the right FSP-release from Intel. Bye Werner Am 03.11.2014 um 17:23 schrieb Gailu Singh via coreboot: > With the changed TXE/descriptor, it moved ahead but now toggling > between POST codes 0x66 and 0x07. I checked > ./src/include/console/post_codes.h and these POST codes are not > defined there so I doubt that these are coming from coreboot code. Are > these post codes coming from FSP code? If yes, How do I interpret > them? Do I need to ask Intel? Any pointers please? > > On Sun, Nov 2, 2014 at 6:50 PM, Sean McNeil <seanmcneil3(a)gmail.com > <mailto:seanmcneil3@gmail.com>> wrote: > > You mentioned just copying the .fd file, so I assumed it was being > used directly in your coreboot image. FSP needs to be incorporated > into flash, yes. It should, however, be patched with the BCT > program as what is provided in the .fd is usually not patched with > the a configuration that you desire. Thus you should run bct and > configure/patch the .fd and generate a .bin to include into coreboot. > > I am a little confused by your email below. You state that you are > not using the .fd directly then contradict yourself in the next > sentence. Bottom line is I would not include any .fd file from the > FSP archive directly. Use BCT to patch it and do not name it .fd. > This avoids any confusion regarding whether you are including a > patched FSP or not. Just because there is a bsf file included in > the GOLD release doesn't mean that the .fd was patched with those > settings and that it is valid. > > Best of luck to you. There are many issues you will have to > resolve dealing with new hardware. I've gone through the process > with a lot of support from Intel and it is not that easy. > Especially when certain components found on the CRB are not > provided on custom hardware. > > Cheers, > Sean > > > On 11/02/2014 08:01 PM, Gailu Singh wrote: >> Hi Sean, >> >> 1. This is not for a real project and we are trying to understand >> FSP interaction with coreboot to look at feasibility for >> considering coreboot in our future projects. Unfortunately I do >> not have board documentation so was not able to determine which >> one is serial port 0 though I know that port 0 is specified in >> coreboot config. That was the reason I was trying on all 3 >> available ports. >> 2. I am not using .fd directly. I believe that FSP need to be >> included in bootloader (coreboot in this case) and we are >> providing path to coreboot so that it can be included in >> coreboot. In my original post I only said that I copied .fd to a >> path expected by coreboot configuration. May I know how did you >> conclude that I am using it directly? May be that can give me >> some pointer. >> 3. I had checked the bsf file in the FSP kit with BCT tool and it >> is configured for non-ECC RAM, so I believe that no change is >> required in .fd. Am I wrong? >> 4. Yes, I agree that there is no documentation available on how >> to create entire 8MB binary with Firmware Description, TXE, >> coreboot etc so for safe route I only touched upper 2 MB as >> recommended in one of the initial commit for baytrail FSP >> integration and some posts related to similar discussion. >> >> >> >> On Sun, Nov 2, 2014 at 3:49 PM, Sean McNeil >> <seanmcneil3(a)gmail.com <mailto:seanmcneil3@gmail.com>> wrote: >> >> Coreboot and FSP are not as easy to understand as you can >> see. I also would suggest that you seek assistance from >> either Sage (who has good experience that I understand serves >> the USA and Europe markets and contributed the current >> Coreboot+FSP code) or perhaps a company in Asia such as Zien >> Solutions (of Vietnam). There are a number of issues that you >> are failing to understand: >> >> 1) As stated, the first serial port is actually connected to >> a USB->Serial converter and delivered out of the microUSB >> connector on the CRB. >> 2) You need to configure the FSP with Intels program to >> create a ROMable image and not use the .fd file directly. >> 3) BayleyBay needs to be configured for non-ECC RAM whereas >> Bakersport needs to be configured for ECC. >> 4) You don't necessarily need the TXE security module, but >> you could very well cause problems if it is partially >> overwritten. Best is to create a correct 8MB image to flash >> that has the proper Intel Firmware Description block at the >> beginning. >> >> Regards, >> Sean >> >> >> On 11/02/2014 02:25 AM, Gaumless via coreboot wrote: >> >> First, the serial ports: The serial console is on the >> first serial port on the micro-USB connection. >> >> The 0x0000 on the post code display means that it's not >> actually starting to boot - it's probably hanging in the >> TXE. There are known issues with upgrading to coreboot >> from some of the bayleybay roms. I thought Intel was >> going to document that, but I don't know if they did. >> >> The Gold 2 FSP doesn't support D0 parts, so if you have a >> D0, you need the Gold 3. Also, the FSP is targeted at >> the embedded sku Baytrail-I. It might work with M/D >> parts, I haven't tested that. >> >> Assuming all that is ok, you probably need to start from >> a different rom. It might be failing because of the TXE >> security. You'll probably need to talk to your Intel >> contact to get that update. >> >> Finally, if this is not a personal project, you might be >> interested in contacting Sage and look at purchasing a >> BSP to get up and running. Either way, let us know >> whether you make progress or need more help. >> >> Martin >> >> >> On Nov 1, 2014, at 11:48 AM, Gailu Singh via coreboot >> <coreboot(a)coreboot.org >> <mailto:coreboot@coreboot.org>> wrote: >> >> Hi Experts, >> >> I am trying to boot BayleyBay CRB Rev 3 using >> coreboot and have no success so far. I have serial >> port (DB9) connected and using 115200 Baud Rate. No >> message comes on serial at all. Here is the procedure >> I followed. >> >> 1. Pulled latest coreboot from git. >> 2. Pulled following from BAY_TRAIL_FSP_KIT. The >> reason for doing it is that BAYTRAIL_FSP.fd is not >> in git and .config refers to it. Also .config refers >> to ../intel/cpu/baytrail/microcode >> a) created intel directory parallel to coreboot >> and copied BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014.fd >> in to intel/fsp/baytrail/BAYTRAIL_FSP.fd >> b) Copied *.h from Microcode folder in the kit >> to intel/cpu/baytrail/microcode. >> 3. Configured the coreboot for mainboard as intel >> bayleybay. My .config is attached. >> 4. Build Coreboot. Below is the prints from cbfstool. >> cmos_layout.bin 0x0 cmos_layout 1132 >> fallback/romstage 0x4c0 stage >> 27813 >> fallback/ramstage 0x71c0 stage >> 67431 >> fallback/payload 0x17980 payload 268859 >> config 0x59400 raw 4363 >> (empty) 0x5a540 null 744088 >> cpu_microcode_blob.bin 0x110000 microcode 104448 >> (empty) 0x129840 null 157528 >> mrc.cache 0x14ffc0 (unknown) 65536 >> (empty) 0x160000 null 393112 >> fsp.bin 0x1bffc0 (unknown) 229376 >> (empty) 0x1f8000 null 31640 >> 5. Flashed the coreboot.rom in upper 2MB >> (0X0600000-0x07FFFFF) >> 6. Reboot the board >> 7. Nothing comes on Serial Console (DB9). Also tried >> to connect Micro usb cable which detects two serial >> ports but no output to any of them as well. >> 8. Before flashing coreboot.rom, 4 digit display was >> displaying something on two digits and rest two were >> zero. Now all 4 digits stays at zeros. >> >> Looking for help to get at least serial working so >> that I can get some logs to debug it. I do not have >> copy of original BIOS that was there in Flash and >> forgot to make a copy using programmer though I >> ensured that I only touch upper 2MB. I am stuck and >> have no logs to debug it. >> >> Thanks in advance. >> <my.config> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> <mailto:coreboot@coreboot.org> >> http://www.coreboot.org/mailman/listinfo/coreboot >> >> >> > > > > -- coreboot mailing list: coreboot(a)coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

1 0

disable from: rewrite?
by Rudolf Marek 04 Nov '14

04 Nov '14

Hi all, Is there a mailman option on our ml to stop rewriting the From header of the email? It is quite retarded... Thanks Coreboot <coreboot(a)coreboot.org>

3 2

Fwd: [Intel-gfx] i915.fastboot bug report - not working on coreboot
by Charles Devereaux 04 Nov '14

04 Nov '14

Hello The issues with i915.fastboot have been explained by Jesse Barnes, unfortunately I do not think I can help any further with that. Could someone from the list help him pinpoint why coreboot is using a different mode? This would make native video init compatible with i915.fastboot=1, to further reduce bootime. I guesstimate about 0.8 seconds could be shaved, which would be quite significant. My reply was: (IIRC, there is no VBT or INT 10H support yet in coreboot native video init) Regarding EDID, it's handled from intel_gma_init in coreboot/src/northbridge/ intel/i945/gma.c. The only thing I see that could be linked to a preferred mode is in decode_edid from coreboot/src/lib/edid.c : if (edid[0x18] & 0x02) { printk(BIOS_SPEW, "First detailed timing is preferred timing\n"); has_preferred_timing = 1; } (...) /* detailed timings */ printk(BIOS_SPEW, "Detailed timings\n"); has_valid_detailed_blocks = detailed_block(out, edid + 0x36, 0); if (has_preferred_timing && !did_detailed_timing) has_preferred_timing = 0; /* not really accurate... */ Maybe disabling has_preferred_timing if there are no did_detailed_timing is wrong? ---------- Forwarded message ---------- From: Jesse Barnes <jbarnes(a)virtuousgeek.org> Date: Thu, Oct 30, 2014 at 5:34 PM Subject: Re: [Intel-gfx] i915.fastboot bug report - not working on coreboot To: Charles Devereaux <intelgfx(a)guylhem.net> Cc: intel-gfx(a)lists.freedesktop.org, Paul Menzel < paulepanter(a)users.sourceforge.net> On Thu, 23 Oct 2014 16:44:26 -0400 Charles Devereaux <intelgfx(a)guylhem.net> wrote: > [ 0.529733] [drm:intel_set_config_compute_mode_changes], modes are > different, full mode set > [ 0.529736] [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 54167 > 1024 1048 1184 1344 768 771 777 806 0x0 0xa > [ 0.529740] [drm:drm_mode_debug_printmodeline], Modeline 11:"1024x768" > 60 65000 1024 1048 1184 1344 768 771 777 806 0x48 0xa This looks like the issue. The BIOS programs a slightly different 1024x768 mode than what the kernel tries to apply. Looks like reduced vs non-reduced blanking approximately. We could adjust the fastboot code to handle that, or change coreboot to use the preferred mode from the EDID of the display or make the VBT match, which is presumably what the kernel is using. -- Jesse Barnes, Intel Open Source Technology Center

1 0

Re: [coreboot] More Fn+key on X60T
by Garreau, Alexandre 04 Nov '14

04 Nov '14

Le 03/11/2014 à 05h29, Charles Devereaux a écrit : > Hello > > On Sun, Nov 2, 2014 at 8:26 AM, Garreau, Alexandre <galex-713(a)galex-713.eu> > wrote: > >> Where do come from the numbers used in the two scripts you showed? I >> suppose there’s a code for each XFree86 keysym, right? >> > > IIRC, it's just a linear function of the keysym: there is a difference by > about 80 Ok… any example anywhere? like a wiki page? >> Talking about /sys/devices/platform/thinkpad_acpi: do you have the file >> “hotkey_tablet_mode”? I need it to detect when the screen is turned in >> tablet mode so that I can automatically rotate the screen. Do it need to >> be implemented in coreboot too? > > No, this is due to missing DSDT entries in coreboot that thinkpad-acpi uses: > > 2058 static int hotkey_get_tablet_mode(int *status) > 2059 { > 2060 int s; > 2061 > 2062 if (!acpi_evalf(hkey_handle, &s, "MHKG", "d")) > 2063 return -EIO; > 2064 > 2065 *status = ((s & TP_HOTKEY_TABLET_MASK) != 0); > 2066 return 0; > 2067 } > > However, with the latest patch from φcoder, you should have the ACPI events > directly Ok, so just upgrade should fix it right? > Fn+F6 and F8 show up in cat /dev/input/event4, Not here. > More problematic, Fn+F10, Fn+insert, Fn+delete are dead as can be - > regardless of the /sys/devices/platform/thinkpad_acpi/hotkey_mask Yeah, that’s the problem. > According to <http://www.thinkwiki.org/wiki/How_to_get_special_keys_to_work#Triggering_ke…>: >> By disassembling and editing the DSDT, more events can be added. HKEY >> events are triggered by calls to the MKHQ function, e.g. >> \_SB.PCI0.LPC.EC.HKEY.MHKQ(0Ã—1007) will trigger "ibm/hotkey HKEY 00000080 >> 00001007". Most of these can be found in _Qxx methods within the DSDT, >> which are executed on embedded controller events, e.g. _Q10 is triggered by >> pressing Fn-F7. You can add a call to MKHQ into an existing _Qxx method to >> get it recognized by thinkpad-acpi as well as creating new _Qxx methods, >> which if you're lucky will correspond to an EC event that IBM never used >> (e.g. A 770 will send Fn-Home/End/PgUp/PgDn to thinkpad-acpi if hacked in >> this fashion). For example, this is a modified block of DSDT for a G40 >> <http://www.wormnet.eu/ibm-g40/morebuttons.dsl>. > My best idea at the moment is that the EC gives different Q codes than > those in the DSDT for the keys that do not generate ACPI events. What’s a DSDT? I’m not sure of what’s HKEY, and I’m sure I don’t understand what’s MKHQ, _Qxx, Q code, EC and G40. > Yet in src/ec/lenovo/h8/acpi/ec.asl, I do see Fn+10, Fn+Insert, Fn+Delete > and also Fn+Backspace, ie everything has been added, but thinkpad-acpi > shows nothing in /dev/input/event4 > Am I missing something? Even Fn+Insert and Delete? :D /me’s wondering if maybe the trick Fn+<numpad> would be possible with some hack… > PS: Do you have a PGP key? > > I do, but for public communication (ex: mailing list) I don't use it. Even for signature?

2 1

Re: [coreboot] Coreboot with Intel FSP on BayleyBay Help
by Sean McNeil 03 Nov '14

03 Nov '14

You mentioned just copying the .fd file, so I assumed it was being used directly in your coreboot image. FSP needs to be incorporated into flash, yes. It should, however, be patched with the BCT program as what is provided in the .fd is usually not patched with the a configuration that you desire. Thus you should run bct and configure/patch the .fd and generate a .bin to include into coreboot. I am a little confused by your email below. You state that you are not using the .fd directly then contradict yourself in the next sentence. Bottom line is I would not include any .fd file from the FSP archive directly. Use BCT to patch it and do not name it .fd. This avoids any confusion regarding whether you are including a patched FSP or not. Just because there is a bsf file included in the GOLD release doesn't mean that the .fd was patched with those settings and that it is valid. Best of luck to you. There are many issues you will have to resolve dealing with new hardware. I've gone through the process with a lot of support from Intel and it is not that easy. Especially when certain components found on the CRB are not provided on custom hardware. Cheers, Sean On 11/02/2014 08:01 PM, Gailu Singh wrote: > Hi Sean, > > 1. This is not for a real project and we are trying to understand FSP > interaction with coreboot to look at feasibility for considering > coreboot in our future projects. Unfortunately I do not have board > documentation so was not able to determine which one is serial port 0 > though I know that port 0 is specified in coreboot config. That was > the reason I was trying on all 3 available ports. > 2. I am not using .fd directly. I believe that FSP need to be included > in bootloader (coreboot in this case) and we are providing path to > coreboot so that it can be included in coreboot. In my original post I > only said that I copied .fd to a path expected by coreboot > configuration. May I know how did you conclude that I am using it > directly? May be that can give me some pointer. > 3. I had checked the bsf file in the FSP kit with BCT tool and it is > configured for non-ECC RAM, so I believe that no change is required in > .fd. Am I wrong? > 4. Yes, I agree that there is no documentation available on how to > create entire 8MB binary with Firmware Description, TXE, coreboot etc > so for safe route I only touched upper 2 MB as recommended in one of > the initial commit for baytrail FSP integration and some posts related > to similar discussion. > > > > On Sun, Nov 2, 2014 at 3:49 PM, Sean McNeil <seanmcneil3(a)gmail.com > <mailto:seanmcneil3@gmail.com>> wrote: > > Coreboot and FSP are not as easy to understand as you can see. I > also would suggest that you seek assistance from either Sage (who > has good experience that I understand serves the USA and Europe > markets and contributed the current Coreboot+FSP code) or perhaps > a company in Asia such as Zien Solutions (of Vietnam). There are a > number of issues that you are failing to understand: > > 1) As stated, the first serial port is actually connected to a > USB->Serial converter and delivered out of the microUSB connector > on the CRB. > 2) You need to configure the FSP with Intels program to create a > ROMable image and not use the .fd file directly. > 3) BayleyBay needs to be configured for non-ECC RAM whereas > Bakersport needs to be configured for ECC. > 4) You don't necessarily need the TXE security module, but you > could very well cause problems if it is partially overwritten. > Best is to create a correct 8MB image to flash that has the proper > Intel Firmware Description block at the beginning. > > Regards, > Sean > > > On 11/02/2014 02:25 AM, Gaumless via coreboot wrote: > > First, the serial ports: The serial console is on the first > serial port on the micro-USB connection. > > The 0x0000 on the post code display means that it's not > actually starting to boot - it's probably hanging in the TXE. > There are known issues with upgrading to coreboot from some of > the bayleybay roms. I thought Intel was going to document > that, but I don't know if they did. > > The Gold 2 FSP doesn't support D0 parts, so if you have a D0, > you need the Gold 3. Also, the FSP is targeted at the > embedded sku Baytrail-I. It might work with M/D parts, I > haven't tested that. > > Assuming all that is ok, you probably need to start from a > different rom. It might be failing because of the TXE > security. You'll probably need to talk to your Intel contact > to get that update. > > Finally, if this is not a personal project, you might be > interested in contacting Sage and look at purchasing a BSP to > get up and running. Either way, let us know whether you make > progress or need more help. > > Martin > > > On Nov 1, 2014, at 11:48 AM, Gailu Singh via coreboot > <coreboot(a)coreboot.org <mailto:coreboot@coreboot.org>> wrote: > > Hi Experts, > > I am trying to boot BayleyBay CRB Rev 3 using coreboot and > have no success so far. I have serial port (DB9) connected > and using 115200 Baud Rate. No message comes on serial at > all. Here is the procedure I followed. > > 1. Pulled latest coreboot from git. > 2. Pulled following from BAY_TRAIL_FSP_KIT. The reason for > doing it is that BAYTRAIL_FSP.fd is not in git and > .config refers to it. Also .config refers to > ../intel/cpu/baytrail/microcode > a) created intel directory parallel to coreboot and > copied BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014.fd in to > intel/fsp/baytrail/BAYTRAIL_FSP.fd > b) Copied *.h from Microcode folder in the kit to > intel/cpu/baytrail/microcode. > 3. Configured the coreboot for mainboard as intel > bayleybay. My .config is attached. > 4. Build Coreboot. Below is the prints from cbfstool. > cmos_layout.bin 0x0 cmos_layout 1132 > fallback/romstage 0x4c0 stage 27813 > fallback/ramstage 0x71c0 stage 67431 > fallback/payload 0x17980 payload 268859 > config 0x59400 raw 4363 > (empty) 0x5a540 null 744088 > cpu_microcode_blob.bin 0x110000 microcode 104448 > (empty) 0x129840 null 157528 > mrc.cache 0x14ffc0 (unknown) 65536 > (empty) 0x160000 null 393112 > fsp.bin 0x1bffc0 (unknown) 229376 > (empty) 0x1f8000 null 31640 > 5. Flashed the coreboot.rom in upper 2MB (0X0600000-0x07FFFFF) > 6. Reboot the board > 7. Nothing comes on Serial Console (DB9). Also tried to > connect Micro usb cable which detects two serial ports but > no output to any of them as well. > 8. Before flashing coreboot.rom, 4 digit display was > displaying something on two digits and rest two were zero. > Now all 4 digits stays at zeros. > > Looking for help to get at least serial working so that I > can get some logs to debug it. I do not have copy of > original BIOS that was there in Flash and forgot to make a > copy using programmer though I ensured that I only touch > upper 2MB. I am stuck and have no logs to debug it. > > Thanks in advance. > <my.config> > -- > coreboot mailing list: coreboot(a)coreboot.org > <mailto:coreboot@coreboot.org> > http://www.coreboot.org/mailman/listinfo/coreboot > > >

2 1

Re: [coreboot] ASUS F2A85-M questions
by HacKurx 03 Nov '14

03 Nov '14

On Fri Oct 31 03:25:55 CET 2014, Patrick 'P. J.' McDermott wrote: > Hi, Hi, > I'm interested in running coreboot on the ASUS F2A85-M, and I have a few > questions. > The wiki page for the board says that hardware virtualization is > untested. Has anyone tested this since the page was created in 2012? > Or could someone with this board please test this? KVM works very well for me. > How reliable is the hack for supporting Richland CPUs? No problems with this. I always use it without problems :) > Are other variants of the F2A85-M (e.g. F2A85-M2) supported? I don't know. Probably need make a patch for this. -- Best regards, HacKurx

1 0

Re: [coreboot] More Fn+key on X60T
by Charles Devereaux 03 Nov '14

03 Nov '14

Hello On Sun, Nov 2, 2014 at 8:26 AM, Garreau, Alexandre <galex-713(a)galex-713.eu> wrote: > Where do come from the numbers used in the two scripts you showed? I > suppose there’s a code for each XFree86 keysym, right? > IIRC, it's just a linear function of the keysym: there is a difference by about 80 > Talking about /sys/devices/platform/thinkpad_acpi: do you have the file > “hotkey_tablet_mode”? I need it to detect when the screen is turned in > tablet mode so that I can automatically rotate the screen. Do it need to > be implemented in coreboot too? > No, this is due to missing DSDT entries in coreboot that thinkpad-acpi uses: 2058 static int hotkey_get_tablet_mode(int *status) 2059 { 2060 int s; 2061 2062 if (!acpi_evalf(hkey_handle, &s, "MHKG", "d")) 2063 return -EIO; 2064 2065 *status = ((s & TP_HOTKEY_TABLET_MASK) != 0); 2066 return 0; 2067 } However, with the latest patch from φcoder, you should have the ACPI events directly Nothing more :/ I already did the “echo 0xffffffff”, it did active some > things like Fn+Space or Fn+PgUP (ThinkLight) within acpi, but nothing > else. There’s still no way to access Fn+Print or Fn+Pause… I think we > need coreboot to implement it, so we can detect it with acpi, right? > Yes, some function key seem to be missing. I do not understand why even after I investigated a bit more. Basically, after checking up with more buttons, I can't get Fn+F6, Fn+F8, Fn+F10, Fn+insert, Fn+delete to generate acpi events, even if I use a kernel supporting /proc/acpi/event (or acpid with input support flag) Fn+F6 and F8 show up in cat /dev/input/event4, give me keysyms with xev (199 XF86TouchpadToggle and 220 XF86WebCam), but no acpi event, which makes me believe it's something that could be fixed. More problematic, Fn+F10, Fn+insert, Fn+delete are dead as can be - regardless of the /sys/devices/platform/thinkpad_acpi/hotkey_mask According to http://www.thinkwiki.org/wiki/How_to_get_special_keys_to_work#Triggering_ke… : "By disassembling and editing the DSDT, more events can be added. HKEY events are triggered by calls to the MKHQ function, e.g. \_SB.PCI0.LPC.EC.HKEY.MHKQ(0Ã—1007) will trigger "ibm/hotkey HKEY 00000080 00001007". Most of these can be found in _Qxx methods within the DSDT, which are executed on embedded controller events, e.g. _Q10 is triggered by pressing Fn-F7. You can add a call to MKHQ into an existing _Qxx method to get it recognized by thinkpad-acpi as well as creating new _Qxx methods, which if you're lucky will correspond to an EC event that IBM never used (e.g. A 770 will send Fn-Home/End/PgUp/PgDn to thinkpad-acpi if hacked in this fashion). For example, this is a modified block of DSDT for a G40 <http://www.wormnet.eu/ibm-g40/morebuttons.dsl>." (dead link, cf http://jamie.lentin.co.uk/computers/ibm-g40/add_buttons.dsl.diff) Yet in src/ec/lenovo/h8/acpi/ec.asl, I do see Fn+10, Fn+Insert, Fn+Delete and also Fn+Backspace, ie everything has been added, but thinkpad-acpi shows nothing in /dev/input/event4 Am I missing something? My best idea at the moment is that the EC gives different Q codes than those in the DSDT for the keys that do not generate ACPI events. Thanks Charles PS: Do you have a PGP key? > I do, but for public communication (ex: mailing list) I don't use it. You can get it with: host -t TXT charles._pka.devereaux.org (it's also published in various key servers)

1 0

Re: [coreboot] Coreboot with Intel FSP on BayleyBay Help
by Jiming Sun 02 Nov '14

02 Nov '14

Post code 0x0000 could also be the case the you do not have the latest microcode patches. Please double check. Jiming > Message: 1 > Date: Sun, 2 Nov 2014 18:31:59 +0530 > From: Gailu Singh <gailu96(a)gmail.com> > To: Sean McNeil <seanmcneil3(a)gmail.com> > Cc: coreboot <coreboot(a)coreboot.org> > Subject: Re: [coreboot] Coreboot with Intel FSP on BayleyBay Help > Message-ID: > < > CAOifn+2aM5FE6J_Vs0a_t+9YOdi1ZSZvhtSW6Jf04HUnQhPmBA(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Sean, > > 1. This is not for a real project and we are trying to understand FSP > interaction with coreboot to look at feasibility for considering coreboot > in our future projects. Unfortunately I do not have board documentation so > was not able to determine which one is serial port 0 though I know that > port 0 is specified in coreboot config. That was the reason I was trying on > all 3 available ports. > 2. I am not using .fd directly. I believe that FSP need to be included in > bootloader (coreboot in this case) and we are providing path to coreboot so > that it can be included in coreboot. In my original post I only said that I > copied .fd to a path expected by coreboot configuration. May I know how > did you conclude that I am using it directly? May be that can give me some > pointer. > 3. I had checked the bsf file in the FSP kit with BCT tool and it is > configured for non-ECC RAM, so I believe that no change is required in .fd. > Am I wrong? > 4. Yes, I agree that there is no documentation available on how to create > entire 8MB binary with Firmware Description, TXE, coreboot etc so for safe > route I only touched upper 2 MB as recommended in one of the initial commit > for baytrail FSP integration and some posts related to similar discussion. > > > > On Sun, Nov 2, 2014 at 3:49 PM, Sean McNeil <seanmcneil3(a)gmail.com> wrote: > > > Coreboot and FSP are not as easy to understand as you can see. I also > > would suggest that you seek assistance from either Sage (who has good > > experience that I understand serves the USA and Europe markets and > > contributed the current Coreboot+FSP code) or perhaps a company in Asia > > such as Zien Solutions (of Vietnam). There are a number of issues that > you > > are failing to understand: > > > > 1) As stated, the first serial port is actually connected to a > USB->Serial > > converter and delivered out of the microUSB connector on the CRB. > > 2) You need to configure the FSP with Intels program to create a ROMable > > image and not use the .fd file directly. > > 3) BayleyBay needs to be configured for non-ECC RAM whereas Bakersport > > needs to be configured for ECC. > > 4) You don't necessarily need the TXE security module, but you could very > > well cause problems if it is partially overwritten. Best is to create a > > correct 8MB image to flash that has the proper Intel Firmware Description > > block at the beginning. > > > > Regards, > > Sean > > > > > > On 11/02/2014 02:25 AM, Gaumless via coreboot wrote: > > > >> First, the serial ports: The serial console is on the first serial port > >> on the micro-USB connection. > >> > >> The 0x0000 on the post code display means that it's not actually > starting > >> to boot - it's probably hanging in the TXE. There are known issues with > >> upgrading to coreboot from some of the bayleybay roms. I thought Intel > was > >> going to document that, but I don't know if they did. > >> > >> The Gold 2 FSP doesn't support D0 parts, so if you have a D0, you need > >> the Gold 3. Also, the FSP is targeted at the embedded sku Baytrail-I. > It > >> might work with M/D parts, I haven't tested that. > >> > >> Assuming all that is ok, you probably need to start from a different > >> rom. It might be failing because of the TXE security. You'll probably > >> need to talk to your Intel contact to get that update. > >> > >> Finally, if this is not a personal project, you might be interested in > >> contacting Sage and look at purchasing a BSP to get up and running. > Either > >> way, let us know whether you make progress or need more help. > >> > >> Martin > >> > >> > >> On Nov 1, 2014, at 11:48 AM, Gailu Singh via coreboot < > >>> coreboot(a)coreboot.org> wrote: > >>> > >>> Hi Experts, > >>> > >>> I am trying to boot BayleyBay CRB Rev 3 using coreboot and have no > >>> success so far. I have serial port (DB9) connected and using 115200 > Baud > >>> Rate. No message comes on serial at all. Here is the procedure I > followed. > >>> > >>> 1. Pulled latest coreboot from git. > >>> 2. Pulled following from BAY_TRAIL_FSP_KIT. The reason for doing it is > >>> that BAYTRAIL_FSP.fd is not in git and .config refers to it. Also > .config > >>> refers to ../intel/cpu/baytrail/microcode > >>> a) created intel directory parallel to coreboot and copied > >>> BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014.fd in to > >>> intel/fsp/baytrail/BAYTRAIL_FSP.fd > >>> b) Copied *.h from Microcode folder in the kit to > >>> intel/cpu/baytrail/microcode. > >>> 3. Configured the coreboot for mainboard as intel bayleybay. My .config > >>> is attached. > >>> 4. Build Coreboot. Below is the prints from cbfstool. > >>> cmos_layout.bin 0x0 cmos_layout 1132 > >>> fallback/romstage 0x4c0 stage 27813 > >>> fallback/ramstage 0x71c0 stage 67431 > >>> fallback/payload 0x17980 payload 268859 > >>> config 0x59400 raw 4363 > >>> (empty) 0x5a540 null 744088 > >>> cpu_microcode_blob.bin 0x110000 microcode 104448 > >>> (empty) 0x129840 null 157528 > >>> mrc.cache 0x14ffc0 (unknown) 65536 > >>> (empty) 0x160000 null 393112 > >>> fsp.bin 0x1bffc0 (unknown) 229376 > >>> (empty) 0x1f8000 null 31640 > >>> 5. Flashed the coreboot.rom in upper 2MB (0X0600000-0x07FFFFF) > >>> 6. Reboot the board > >>> 7. Nothing comes on Serial Console (DB9). Also tried to connect Micro > >>> usb cable which detects two serial ports but no output to any of them > as > >>> well. > >>> 8. Before flashing coreboot.rom, 4 digit display was displaying > >>> something on two digits and rest two were zero. Now all 4 digits stays > at > >>> zeros. > >>> > >>> Looking for help to get at least serial working so that I can get some > >>> logs to debug it. I do not have copy of original BIOS that was there in > >>> Flash and forgot to make a copy using programmer though I ensured that > I > >>> only touch upper 2MB. I am stuck and have no logs to debug it. > >>> > >>> Thanks in advance. > >>> <my.config> > >>> -- > >>> coreboot mailing list: coreboot(a)coreboot.org > >>> http://www.coreboot.org/mailman/listinfo/coreboot > >>> > >> > > >

1 0

Re: [coreboot] Coreboot with Intel FSP on BayleyBay Help
by Gaumless 02 Nov '14

02 Nov '14

First, the serial ports: The serial console is on the first serial port on the micro-USB connection. The 0x0000 on the post code display means that it's not actually starting to boot - it's probably hanging in the TXE. There are known issues with upgrading to coreboot from some of the bayleybay roms. I thought Intel was going to document that, but I don't know if they did. The Gold 2 FSP doesn't support D0 parts, so if you have a D0, you need the Gold 3. Also, the FSP is targeted at the embedded sku Baytrail-I. It might work with M/D parts, I haven't tested that. Assuming all that is ok, you probably need to start from a different rom. It might be failing because of the TXE security. You'll probably need to talk to your Intel contact to get that update. Finally, if this is not a personal project, you might be interested in contacting Sage and look at purchasing a BSP to get up and running. Either way, let us know whether you make progress or need more help. Martin > On Nov 1, 2014, at 11:48 AM, Gailu Singh via coreboot <coreboot(a)coreboot.org> wrote: > > Hi Experts, > > I am trying to boot BayleyBay CRB Rev 3 using coreboot and have no success so far. I have serial port (DB9) connected and using 115200 Baud Rate. No message comes on serial at all. Here is the procedure I followed. > > 1. Pulled latest coreboot from git. > 2. Pulled following from BAY_TRAIL_FSP_KIT. The reason for doing it is that BAYTRAIL_FSP.fd is not in git and .config refers to it. Also .config refers to ../intel/cpu/baytrail/microcode > a) created intel directory parallel to coreboot and copied BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014.fd in to intel/fsp/baytrail/BAYTRAIL_FSP.fd > b) Copied *.h from Microcode folder in the kit to intel/cpu/baytrail/microcode. > 3. Configured the coreboot for mainboard as intel bayleybay. My .config is attached. > 4. Build Coreboot. Below is the prints from cbfstool. > cmos_layout.bin 0x0 cmos_layout 1132 > fallback/romstage 0x4c0 stage 27813 > fallback/ramstage 0x71c0 stage 67431 > fallback/payload 0x17980 payload 268859 > config 0x59400 raw 4363 > (empty) 0x5a540 null 744088 > cpu_microcode_blob.bin 0x110000 microcode 104448 > (empty) 0x129840 null 157528 > mrc.cache 0x14ffc0 (unknown) 65536 > (empty) 0x160000 null 393112 > fsp.bin 0x1bffc0 (unknown) 229376 > (empty) 0x1f8000 null 31640 > 5. Flashed the coreboot.rom in upper 2MB (0X0600000-0x07FFFFF) > 6. Reboot the board > 7. Nothing comes on Serial Console (DB9). Also tried to connect Micro usb cable which detects two serial ports but no output to any of them as well. > 8. Before flashing coreboot.rom, 4 digit display was displaying something on two digits and rest two were zero. Now all 4 digits stays at zeros. > > Looking for help to get at least serial working so that I can get some logs to debug it. I do not have copy of original BIOS that was there in Flash and forgot to make a copy using programmer though I ensured that I only touch upper 2MB. I am stuck and have no logs to debug it. > > Thanks in advance. > <my.config> > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

3 2

rfkill explanation
by Charles Devereaux 02 Nov '14

02 Nov '14

Hello After studying thinkpad-acpi.c subdrivers, here are the ACPI entries which are missing in src/ec/lenovo/h8/acpi/ec.asl to enable a proper rfkill support on a X60 (which will be created by thinkpad-acpi) : - GWAN - SWAN - GBDC - SBDC Why? Because for example with thinkpad-acpi bluetooth subdriver, bluetooth_init will do: acpi_evalf(hkey_handle, &status, "GBDC", "qd"); If GBDC does not return the proper status, bluetooth is supposed to not be present. If it returns the correct status, the proper rfkill entry will be created: res = tpacpi_new_rfkill(TPACPI_RFK_BLUETOOTH_SW_ID, &bluetooth_tprfk_ops, RFKILL_TYPE_BLUETOOTH, TPACPI_RFK_BLUETOOTH_SW_NAME, true); As these 4 ACPI entries are missing, bluetooth rfkill is provided by the bluetooth driver instead of thinkpad-acpi. Why is that bad? Because thinkpad-acpi would use SBDC to set the status and actually save power (also toggling the bluetooth led which is nice) The same thing applies to WWAN, only with GBDC/SBDC. Also, it's then much more important, as a GPS module consume more power than Bluetooth. All that is quite clear. The next part is not so clear, as it came from my understanding of the original DSDT. The ACPI entries seem to be handled this way: GWAN: get wwan status -> WGFL and WPWS-> H8DR-> _SB.PCI0.LPC.EC.DCWW || ShiftRight (And (\RBEC (0x3A), 0x40), 0x06) SWAN: set wwan status -> WPWC (and the power-on default is stored in NVRAM: WGSV) GBDC: get bluetooth status -> WGFL and BPWS-> H8DR-> _SB.PCI0.LPC.EC.DCBD || ShiftRight (And (\RBEC (0x3A), 0x10), 0x04) SBDC: set bluetooth status -> BPWC (and the power-on default is stored in NVRAM: BLTH) WGFL seems to be some bitmask for bluetooth (0x20) and wwan (0x02), maybe to store their current status? It affects _SB.PCI0.LPC.EC.HKEY.BPWC and _SB.PCI0.LPC.EC.HKEY.WPWC The function of _SB.PCI0.LPC.EC.HKEY.BPWC/_SB.PCI0.LPC.EC.HKEY.WPWC and _SB.PCI0.LPC.EC.DCWW/_SB.PCI0.LPC.EC.DCBD is unclear to be. I guess it control the module power and the LED state. I hope the above can be useful to someone to fix src/ec/lenovo/h8/acpi/ec.asl BTW, the KBLT entry is present in ec.asl, but shouldn't be always on, as there is no thinklight on the x60t (only on the X60 proper IIRC)

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

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 2014