coreboot May 2016

coreboot@coreboot.org

65 participants
149 discussions

Query regarding coreboot for new intel customized board
by Mayuri Tendulkar 23 May '16

23 May '16

Hi team I am working on building coreboot for one of our customized board. This is based on Intel ISX board reference design, reference can be taken as Minnowboard or BayleyBay CRB. As per documentation given under coreboot, I created folder with my board name under src/intel/mainboard/xxx and did changes required. If I tried the coreboot with these changes on minnowboard, it got stuck at FSP MRC Cache not found. But if the same code changes I copied under src/intel/mainboard/minnowmax and built, it booted fine. I would like to know what is the importance of these board names, SMBIOS table name, serial no which are defined for Minnowmax. Is there some master registry where all these are stored, and if any new entry comes, how we should add it. Regards Mayuri "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

1 0

Re: [coreboot] ThinkPad x220 - Status
by Patrick Rudolph 23 May '16

23 May '16

On 2016-05-23 05:20 PM, Nuno Moreira wrote: > Hi Iru, Arian and Alexander. > Thanks a lot for your feedback :) > > Trying to reply to your input and presenting some questions emerging > from it: > > [IRU] "X220 has been supported for years :)" > [/ME] Indeed. My mistake. After a better Internet search, I can see > support at least since 2013. Thanks for the correction, Iru ;) > > [IRU] "To unlock RAM speed in coreboot, you can see my article, but I > haven't tested it yet." > [/ME] Thanks a lot for this. I think I'll take the "risk" ant try to > get 1866Mhz speed (fingers crossed). > > [IRU] "tp-smapi depends on the proprietary firmware, and you can set > the battery threshold with ectool." > [/ME] Oh, this is great. I was not aware of this tool. I was looking > to tpacpi-bat as an alternative. Gotta check what fits me&scripts > better. > > [ARIAN] "If you had damaged the ME firmware, you would not reach > coreboot or any other firmware - the blob is signed" > [ARIAN] "If you had damaged the NIC firmware, ethernet would probably > be broken, so that's clearly defined." > [/ME] That's good to know. Everything should be ok then, since BIOS > can boot and Ethernet is working fine :) > > [ARIAN] "refining the wiki would be a good thing to do" > [/ME] Indeed. I'll try to update the Wiki after I finished my testing. > > [ARIAN] "That's RAM _clock_ not data rate which is double the clock > rate (-> DDR) - you're not any worse off than with the original > firmware." > [/ME] Also good news. This means the current speed is the default > maximum of 1333 MHz. The problem in dmidecode info presentation is > probably related with the issue Alexander presents below then. > Should we put the DDR frequency or real frequency here ? >From users point of view DDR frequency does make more sense. It looks like some vendors put DDR frequency and others the real frequency here... > [ALEXANDER] "we might written the wrong value into dmidata. (dmidecode > reads a description written by the firmware, has nothing to do with > the real values)." > [/ME] This is the most "logical" possibility I think. DO YOU GUYS KNOW > ABOUT ANY OTHER METHOD TO GET/READ THE "REAL" RAM CLOCK SPEED? I would > like to apply the RAM speed unlock patch presented by Iru and check > the speed with different RAM modules (2x4G 1333Mhz and 2x8GB 1866Mhz) > in order to confirm if the max speed is really unlocked. But if > dmidecode always presents 667MHz as RAM speed I will never know if it > is working or not :( > The "real" frequency is the value reported by dmidecode. It is the frequency the ram is running at, it isn't hardcoded to 667Mhz. You can use it to verify the current RAM speed. I don't think there's another linux tool to get real values. > [ALEXANDER] "tp smapi depends on lot of SMM/SMI code. So tp-smapi > kernel module asked the Lenovo BIOS to tell the EC to do something. > coreboot don't want to support SMM/SMI APIs, because they are quite > dangerous. But there is another way to get those features back. We > know how to enable it, but we haven't yet create a way to control this > by the user. One thing could be a userspace tool executed as root or > we add another CMOS configuration for it. Any idea?" > [/ME] Thanks for the clarification, Alexander. Well, in my user > perspective, I think a user-space tool will be better because it can > be used to update the thresholds more easily. If we only rely on CMOS > config we would need to re-flash it every time we want to change the > thresholds. (AFAIK, x220 only supports HW flash. We cannot re-flash > from OS). > > [ALEXANDER] "It looks you're using the native graphics init instead of > the binary blob VGABIOS. The last time I tried it, I had a lot of > problems." > [/ME] Yes, I'm using NGI. I did not suffer from the well-know "one > color blur image" problem yet. > > [ALEXANDER] "Thanks for your feedback. Feel free to create tickets or > updating the x220 wiki page." > [/ME] You're welcome and Thanks for your support. I'll definitely try > to update the Wiki after I finished my testing. > > --sigkill > > On Mon, May 23, 2016 at 3:02 PM, Alexander Couzens <lynxis(a)fe80.eu> > wrote: > >> hey, >> >> nice you made it! >> >>> *3) Coreboot rocks but... Current Open issues:* >>> --------------------------------------------- >>> I decided to use coreboot-4.4 release instead of git-master. >>> As payload I'm using SeaBIOS (booting Archlinux with Syslinux as >>> bootloader). >> That's ok. >> >>> Before, with dmidecode -t 17 the speed was 1333Mhz and now it is >> just >>> 667Mhz... >> we might written the wrong value into dmidata. (dmidecode reads a >> description written by the firmware, has nothing to do with the real >> values). >> >>> *3.2) TP-SMAPI: * >>> -------------- >> tp smapi depends on lot of SMM/SMI code. So tp-smapi kernel module >> asked the Lenovo BIOS to tell the EC to do something. coreboot don't >> want to support SMM/SMI APIs, because they are quite dangerous. >> But there is another way to get those features back. >> We know how to enable it, but we haven't yet create a way to control >> this by the user. >> >> One thing could be a userspace tool executed as root or we add >> another >> CMOS configuration for it. Any idea? >> >>> *3.3) Config files:* >>> ------------------ >>> coreboot - http://pastebin.com/9ymtxLBW >> It looks you're using the native graphics init instead of the binary >> blob VGABIOS. The last time I tried it, I had a lot of problems. [3] >> >> Thanks for your feedback. Feel free to create tickets or updating >> the >> x220 wiki page. >> >> Best, >> lynxis >> >> [3] https://ticket.coreboot.org/issues/37 >> -- >> Alexander Couzens >> >> mail: lynxis(a)fe80.eu >> jabber: lynxis(a)fe80.eu >> mobile: +4915123277221 [1] >> gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604 > > > > Links: > ------ > [1] tel:%2B4915123277221 Regards, Patrick

2 1

Re: [coreboot] ThinkPad x220 - Status
by Alexander Couzens 23 May '16

23 May '16

hey, nice you made it! > *3) Coreboot rocks but... Current Open issues:* > --------------------------------------------- > I decided to use coreboot-4.4 release instead of git-master. > As payload I'm using SeaBIOS (booting Archlinux with Syslinux as > bootloader). That's ok. > Before, with dmidecode -t 17 the speed was 1333Mhz and now it is just > 667Mhz... we might written the wrong value into dmidata. (dmidecode reads a description written by the firmware, has nothing to do with the real values). > *3.2) TP-SMAPI: * > -------------- tp smapi depends on lot of SMM/SMI code. So tp-smapi kernel module asked the Lenovo BIOS to tell the EC to do something. coreboot don't want to support SMM/SMI APIs, because they are quite dangerous. But there is another way to get those features back. We know how to enable it, but we haven't yet create a way to control this by the user. One thing could be a userspace tool executed as root or we add another CMOS configuration for it. Any idea? > *3.3) Config files:* > ------------------ > coreboot - http://pastebin.com/9ymtxLBW It looks you're using the native graphics init instead of the binary blob VGABIOS. The last time I tried it, I had a lot of problems. [3] Thanks for your feedback. Feel free to create tickets or updating the x220 wiki page. Best, lynxis [3] https://ticket.coreboot.org/issues/37 -- Alexander Couzens mail: lynxis(a)fe80.eu jabber: lynxis(a)fe80.eu mobile: +4915123277221 gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604

2 1

Re: [coreboot] ThinkPad x220 - Status
by arian 23 May '16

23 May '16

Hi Huno, not terribly knowledgeable and speaking from T420-experience > I've read and used the blobs from the "damaged" custom BIOS. I'm not sure if this can affect the functionality of Coreboot. Apparently, it does not. If you had damaged the ME firmware, you would not reach coreboot or any other firmware - the blob is signed If you had damaged the NIC firmware, ethernet would probably be broken, so that's clearly defined. > /(Let me know if anyone of you need details/help about/with the HW flashing in this type of chip (MX25L6406E/MX25L6408E)). refining the wiki would be a good thing to do > *3.1) RAM speed:* > --------------- > *=> So, if I'm understanding it correctly, current 667 Mhz is not the maximum ***speed *supported. > Any idea on how I can get higher speeds?* That's RAM _clock_ not data rate which is double the clock rate (-> DDR) - you're not any worse off than with the original firmware.

1 0

ThinkPad x220 - Status
by Nuno Moreira 23 May '16

23 May '16

Hello, everyone. First of all, I would like to thanks and to congratulate all the community who helps to develop and to optimize this great project. Keep it up :) I would appreciate if you can give me some opinions or point me to someone who will, regarding the Open Issues I present below (3.1 and 3.2). Trying to give you a brief contextualization of my status before and after Coreboot. *1) Init:* -------- Recently I bought a refurbished x220 and flashed it with a custom BIOS (Lenovo ThinkPad x220_1.40-(8DET70WW)-8duj26us_NWL_ADV_AES_PM_Speedo) because I wanted to unlock the RAM speed to be 1866MHz (max RAM speed is locked to 1333Mhz in official BIOS), white-list some Wi-Fi cards, Advanced Chipset Config menu, etc. This custom BIOS worked perfectly until I changed some settings related with Intel VT-x. If I recall correctly, I activated SR-IOV for PCI-E, saved and exited and after that x220 = BRICKED. I tried every typical troubleshooting/workaround (Removing as much HW as possible, unplug BIOS battery for hours, etc), nothing worked. x220 BIOS never booted again and the machine was in a constant boot loop. Don't know why/how this happened in the first place, but since it is a custom BIOS and it is very hard to reach the developer, I knew I could never get it to work without an intrusive method... *2) Coreboot as Salvation:* ------------------------- I started to look for alternatives, and luckily, Coreboot supports x220 since a couple of months ago :) After dealing with all the learning curve to understand the minimal requirements to compile and install Coreboot (tricky part is basically the need for HW flashing) I managed to get a working BIOS and x220 is now (almost 100%) operational :) I've read and used the blobs from the "damaged" custom BIOS. I'm not sure if this can affect the functionality of Coreboot. Apparently, it does not. *(Let me know if anyone of you need details/help about/with the HW flashing in this type of chip (MX25L6406E/MX25L6408E)).* *3) Coreboot rocks but... Current Open issues:* --------------------------------------------- I decided to use coreboot-4.4 release instead of git-master. As payload I'm using SeaBIOS (booting Archlinux with Syslinux as bootloader). *3.1) RAM speed:* --------------- I've 2 x 8GB DRR3-1866MHz installed. The 16GB are detected but the speed reported is just 667MHz. With the official BIOS, the max speed was 1333Mhz. Don't know how Coreboot is handling this subject in this particular main-board... DDR timings are a little bit confusing to me, I guess... Before, with dmidecode -t 17 the speed was 1333Mhz and now it is just 667Mhz... This 667MHz speed I get with coreboot is 2x667=1333Mhz or in reality is 2x333MHz? In "northbridge/intel/sandybridge/raminit.c" we can see the following statement: /* Maximum supported DDR3 frequency is 1066MHz (DDR3 2133) so make sure * we cap it if we have faster DIMMs. * Then, align it to the closest JEDEC standard frequency */ *=> So, if I'm understanding it correctly, current 667 Mhz is not the maximum * *speed supported.Any idea on how I can get higher speeds?* *3.2) TP-SMAPI: * -------------- Looks like tp-smapi is not available using Coreboot. It was OK with the official and custom BIOS before. >From what I've read, this is not a Coreboot limitation... Not sure if the blobs/EC are not ok for tp-smapi now... I use tp-smapi for battery threshold, etc. TLP <http://linrunner.de/en/tlp/tlp.html>also uses tp-smapi. So it is kinda of important to me. *=> Anyone using tp-smapi with no problems out there?* *3.3) Config files:* ------------------ coreboot - http://pastebin.com/9ymtxLBW seabios - http://pastebin.com/rUU7ajRH cmos.default - http://pastebin.com/Pm5vS15R Thanks in advance, guys. All the best \o --sigkill

1 0

Re: [coreboot] UEFI Payload in coreboot for Intel Minnowboard or Bayley bay
by Mayuri Tendulkar 23 May '16

23 May '16

Hi Zoran I tried Minnowboard max bios file available on intel firmware site. With this file, I am able to boot to UEFI bios setup. But I don’t see any option to change CSM off. When I am booting thru coreboot, I don’t see any option to change this CSM mode. Regards Mayuri From: Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com] Sent: 21 May 2016 12:47 To: Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com> Cc: coreboot <coreboot(a)coreboot.org> Subject: Re: [coreboot] UEFI Payload in coreboot for Intel Minnowboard or Bayley bay Mayuri, > Zoran writes in last email: "...UEFI payload will not find EFI32 /boot/EFI directory created..." My bad (right thinking, but too fast hands): should read FAT32 instead EFI32. > Sorry, but I am not able to understand what you have mentioned. Please, read carefully the following article: https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-w… I have no time explaining the written. You need to spend maybe whole day analyzing it, trying to understand what Adam writes about. Bottom line, your Tiano Core works perfectly as payload, but you have CSM ON formatted HDD (must have CSM OFF). Zoran On Fri, May 20, 2016 at 10:41 AM, Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com<mailto:mayuri.tendulkar@aricent.com>> wrote: Hi Zoran Sorry, but I am not able to understand what you have mentioned. Can you please help me explain little detail? Sorry, but I am new to this coreboot environment. Regards Mayuri From: Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com<mailto:zoran.stojsavljevic@gmail.com>] Sent: 20 May 2016 13:39 To: Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com<mailto:mayuri.tendulkar@aricent.com>> Cc: coreboot <coreboot(a)coreboot.org<mailto:coreboot@coreboot.org>> Subject: Re: [coreboot] UEFI Payload in coreboot for Intel Minnowboard or Bayley bay Hello Mayuri, Not sure if I am right, but to bring GRUB 2.0 from CSM OFF and CSM ON modes, you must have two distinct HDDs, one created with CSM ON, other with CSM OFF. If you are using one with CSM ON (seems the case), your UEFI payload will not find EFI32 /boot/EFI directory created, and it does not understand MBR). Does this (what I wrote) make sense? Zoran On Fri, May 20, 2016 at 7:21 AM, Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com<mailto:mayuri.tendulkar@aricent.com>> wrote: Hi Zoran Currently we are using FSP 3. But it works fine with seabios payload. Only when I include UEFI, I am getting this issue. So I am not sure if this is related to FSP3 or 4. My query is there any additional configurations required in UEFI Payload to make it work for Minnowboard max. I see difference in addresses for UEFI and Seabios payload. Not sure where are they set. Seabios payload (working) CBFS provider active. CBFS @ 500000 size 2ff9c0 CBFS: Locating 'fallback/payload' CBFS: Found @ offset 76b40 size f782 'fallback/payload' located at offset: 576b78 size: f782 Loading segment from rom address 0xffd76b78 code (compression=1) New segment dstaddr 0xe2780 memsize 0x1d880 srcaddr 0xffd76bb0 filesize 0xf74a Loading segment from rom address 0xffd76b94 Entry Point 0x000ff06e Payload being loaded below 1MiB without region being marked as RAM usable. Bounce Buffer at 7ac50000, 451744 bytes Loading Segment: addr: 0x00000000000e2780 memsz: 0x000000000001d880 filesz: 0x000000000000f74a lb: [0x0000000000100000, 0x0000000000137250) Post relocation: addr: 0x00000000000e2780 memsz: 0x000000000001d880 filesz: 0x000000000000f74a using LZMA [ 0x000e2780, 00100000, 0x00100000) <- ffd76bb0 dest 000e2780, end 00100000, bouncebuffer 7ac50000 Loaded segments BS: BS_PAYLOAD_LOAD times (us): entry 0 run 130526 exit 0 FspNotify(EnumInitPhaseReadyToBoot) fsp_header_ptr: fffc0094 FSP Header Version: 1 FSP Revision: 3.3 Returned from FspNotify(EnumInitPhaseReadyToBoot) POST: 0x7b Jumping to boot code at 000ff06e(7acbf000) POST: 0xf8 CPU0: stack: 0012e000 - 0012f000, lowest used address 0012eb10, stack used: 1264 bytes entry = 0x000ff06e lb_start = 0x00100000 lb_size = 0x00037250 buffer = 0x7ac50000 SeaBIOS (version rel-1.9.0-127-gc8e105a) UEFI Payload logs (not working) CBFS provider active. CBFS @ 500000 size 2ff9c0 CBFS: Locating 'fallback/payload' CBFS: Found @ offset 56ec0 size 90b92 'fallback/payload' located at offset: 556ef8 size: 90b92 Loading segment from rom address 0xffd56ef8 code (compression=1) New segment dstaddr 0x800000 memsize 0x410000 srcaddr 0xffd56f30 filesize 0x90b5a Loading segment from rom address 0xffd56f14 Entry Point 0x008002c0 Bounce Buffer at 7ac34000, 437408 bytes Loading Segment: addr: 0x0000000000800000 memsz: 0x0000000000410000 filesz: 0x0000000000090b5a lb: [0x0000000000100000, 0x0000000000135650) Post relocation: addr: 0x0000000000800000 memsz: 0x0000000000410000 filesz: 0x0000000000090b5a using LZMA [ 0x00800000, 00c10000, 0x00c10000) <- ffd56f30 dest 00800000, end 00c10000, bouncebuffer 7ac34000 Loaded segments BS: BS_PAYLOAD_LOAD times (us): entry 0 run 507070 exit 0 FspNotify(EnumInitPhaseReadyToBoot) fsp_header_ptr: fffc0094 FSP Header Version: 1 FSP Revision: 3.3 Returned from FspNotify(EnumInitPhaseReadyToBoot) POST: 0x7b Jumping to boot code at 008002c0(7ac9f000) POST: 0xf8 CPU0: stack: 0012c000 - 0012d000, lowest used address 0012cb10, stack used: 1264 bytes entry = 0x008002c0 lb_start = 0x00100000 lb_size = 0x00035650 buffer = 0x7ac34000 From: Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com<mailto:zoran.stojsavljevic@gmail.com>] Sent: 20 May 2016 10:44 To: Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com<mailto:mayuri.tendulkar@aricent.com>>; coreboot <coreboot(a)coreboot.org<mailto:coreboot@coreboot.org>> Subject: Re: [coreboot] UEFI Payload in coreboot for Intel Minnowboard or Bayley bay Hello Mayuri, If I am not mistaken (I often mix BYT Coreboot @ threads in my head), you are using BYT FSP Version 3. > fsp_header_ptr: fffc0094 <== correct > FSP Header Version: 1 > FSP Revision: 3.3 <== please, use Version 4 Please, try to use the latest public BYT FSP Version 4 posted at: www.intel.com/fsp<http://www.intel.com/fsp> BAYTRAIL_FSP_GOLD_004_22-MAY-2015.fd BAYTRAIL_FSP_GOLD_004_22-MAY-2015_DEBUG.fd Don't remember deltas between V3 and V4, I thing something was wrong in V3 with MTRRs' setup, if I do not mix data in my head. INTEL also has Version 5 for a quite some time, but this one for some reasons never got publicly released. Please, report if this solved your problems. Zoran On Wed, May 18, 2016 at 6:56 AM, Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com<mailto:mayuri.tendulkar@aricent.com>> wrote: Hi While booting my Minnomboard with coreboot and UEFI, it hangs at below point while loading the payload. I followed the procedure to download latest EDK2 tree and built UEFIPAYLOAD.fd and copied it to coreboot/payloads/external/tianocore folder and gave this path in make menuconfig. Has anybody come across this? BS: BS_PAYLOAD_LOAD times (us): entry 0 run 507070 exit 0 FspNotify(EnumInitPhaseReadyToBoot) fsp_header_ptr: fffc0094 FSP Header Version: 1 FSP Revision: 3.3 Returned from FspNotify(EnumInitPhaseReadyToBoot) POST: 0x7b Jumping to boot code at 008002c0(7ac9f000) POST: 0xf8 CPU0: stack: 0012c000 - 0012d000, lowest used address 0012cb10, stack used: 1264 bytes entry = 0x008002c0 lb_start = 0x00100000 lb_size = 0x00035650 buffer = 0x7ac34000 Regards Mayuri From: Mayuri Tendulkar Sent: 17 May 2016 14:13 To: 'Zoran Stojsavljevic' <zoran.stojsavljevic(a)gmail.com<mailto:zoran.stojsavljevic@gmail.com>>; coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> Subject: RE: [coreboot] UEFI Payload in coreboot for Intel Minnowboard or Bayley bay Hi Zoran and Martin Today I was able to build UEFIPAYLOAD separately. I included .fd file while building coreboot.rom. But while booting, getting some errors , so debugging those. Need to check what more customizations to be done in UEFI for Minnowmax. Has anybody tried it? Regards Mayuri From: Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com] Sent: 16 May 2016 21:04 To: Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com<mailto:mayuri.tendulkar@aricent.com>>; coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> Subject: Re: [coreboot] UEFI Payload in coreboot for Intel Minnowboard or Bayley bay OK, Mayuri, You brought an interesting point. And this point is to be not only investigated by you, rather also by me and, perhaps, Coreboot community. Since here, in Bayern/Deutschland is Holiday Day, I went to buy a beer in Munchen HBf, and while walking there I was thinking about your use case. Thinking deeper. I know that you are using some INTEL CPU/SoC (do not remember which one, if you said one). But, while recapping how BIOS looks like, I did notice that SEC and PEI phases have nothing to do with UEFI EDK2. EDK 2 comes to play in DXE phase, where EDK2 actually takes place/overtakes control... It says to me one major thing I did not notice while ago: that ARM SoCs are also eligible to run on UEFI compliant OSes, namely WIN 8.1+ (including WIN 10 and WIN 10 Athens/RT WIN 10). Which makes very interesting IOT case namely for ARM, allowing it also to compete in WIN space. Interestingly enough, this idea did not come to my mind till few hours ago... I guess, Vincent (Zimmer) already thought about that. ;-) _______ Martin (Roth) just replied, to solve this immediate mystery. probably for the beginning only for INTEL SoCs, but, I really hope, ARM will also integrate in this concept seamlessly! :-) Zoran _______ On Mon, May 16, 2016 at 2:29 PM, Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com<mailto:mayuri.tendulkar@aricent.com>> wrote: Hi Zoran I have checked that site and downloaded EDK2 code. I am trying to build it on Linux but facing some issues. But if I generate payload file separately, I need to integrate it in coreboot separately. So I am checking if there is way to build the payload in coreboot itself. Regards Mayuri From: Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com<mailto:zoran.stojsavljevic@gmail.com>] Sent: 16 May 2016 17:57 To: Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com<mailto:mayuri.tendulkar@aricent.com>> Cc: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> Subject: Re: [coreboot] UEFI Payload in coreboot for Intel Minnowboard or Bayley bay Hello Mayuri, You should check payload called: Tiano Core (true UEFI payload). Zoran On Mon, May 16, 2016 at 2:12 PM, Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com<mailto:mayuri.tendulkar@aricent.com>> wrote: Hi Is there any mechanism to build UEFI payload directly in coreboot similar like seabios? Regards Mayuri "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." -- coreboot mailing list: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> https://www.coreboot.org/mailman/listinfo/coreboot "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

1 0

Re: [coreboot] openbios in config?
by David Griffith 22 May '16

22 May '16

On Mon, 23 May 2016, Zoran Stojsavljevic wrote: > Hello David, Martin, Peter, > > I would like to ask few quick questions about payload called OpenBIOS. Since > I know something about SeaBIOS, but nothing about OpenBIOS. > > Quick questions: > [1] What is OpenBIOS? Something similar as SeaBIOS? > [2] If [1] is YES, what are differences, and when to use SeaBIOS, when > OpenBIOS payloads? > [3] Does OpenBIOS simulates CSM ON only (I expect yes, butt not CSM OFF)? > [4] Any net pointer/web pages I can read more on OpenBIOS? [1] OpenBIOS is a GPL2 licensed implementation of OpenFirmware. It's more akin to OpenBoot on a Sparc machine whereas SeaBIOS is akin to a PC's traditional BIOS. [2] OpenBIOS provides a command-line and Forth programming interface to setting up and booting a computer. As-is, OpenBIOS is rather spartan. See http://www.tldp.org/HOWTO/SPARC-HOWTO-14.html for a rundown of what can be done with a Sparc machine's OpenBoot environment. [3] If you're asking if it provides legacy BIOS compatibility, then no. [4] http://www.openfirmware.info/ -- David Griffith dave(a)661.org A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?

1 0

Re: [coreboot] openbios in config?
by Zoran Stojsavljevic 22 May '16

22 May '16

Hello David, Martin, Peter, I would like to ask few quick questions about payload called OpenBIOS. Since I know something about SeaBIOS, but nothing about OpenBIOS. Quick questions: [1] What is OpenBIOS? Something similar as SeaBIOS? [2] If [1] is YES, what are differences, and when to use SeaBIOS, when OpenBIOS payloads? [3] Does OpenBIOS simulates CSM ON only (I expect yes, butt not CSM OFF)? [4] Any net pointer/web pages I can read more on OpenBIOS? Thank you, Zoran On Tue, May 17, 2016 at 10:19 PM, Martin Roth <gaumless(a)gmail.com> wrote: > I agree that downloading at build time shouldn't be a requirement, and > that there should be the ability for building on a machine that isn't > connected to the internet. So I'd say that it's important for the > number of *REQUIRED* downloads at build time to be zero. > > Adding another payload option that downloads at build time isn't an > issue though - for people who don't want to use it, they can select > 'no payload' or 'elf payload'. > > Martin > > On Tue, May 17, 2016 at 1:47 PM, Peter Stuge <peter(a)stuge.se> wrote: > > David Griffith wrote: > >> Is there any interest in having the Coreboot build process downliad > > > > In general I think it's important to reduce the number of downloads > > during coreboot builds to zero. > > > > Downloading needs to be managed separately from building. > > > > > > //Peter > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > https://www.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] SeaBios serial(RX) is not running.
by 김유석 책임연구원 22 May '16

22 May '16

Dear Sir. Thank's your work. Enable the bi-direction serial console is done. 2016-05-20 오후 8:36에 Kyösti Mälkki 이(가) 쓴 글: > > > On Tue, May 17, 2016 at 10:46 PM, Martin Roth <gaumless(a)gmail.com > <mailto:gaumless@gmail.com>> wrote: > > Hi, > If you want bi-directional serial port in SeaBIOS, I think you need > to stick with the version from Sage. As far as I know, it's never been > supported in the upstream SeaBIOS version. > > > I have pulled this serial to keyboard mapping change from SageBIOS and > posted on the seabios list today. Hitting ESC and changing boot media > seemed to work. > > BR, > Kyösti >

2 1

Re: [coreboot] Coreboot, supporting this Dell laptop motherboard?
by Jonathan Neuschäfer 21 May '16

21 May '16

On Sat, May 21, 2016 at 09:14:49PM +0000, thejapanscout . wrote: > I want to see if coreboot could support an old Latitude D510 I have from > late 2005. It's suitable for low-end operations such as running Firefox and > computations, and I'm currently running Lubuntu on this thing. > > Vendor: Dell Coreboot currently doesn't support any Dell hardware. > Motherboard ID: 3TZKF91, according to dmidecode -s system-seriel-number > CPU: Pentium M, Type 0, Family 6, Model 13, Stepping 8 > Northbridge/Southbridge: likely 82915GM(?), ICH6/M Southbridge Coreboot supports GM45 northbridges, and a few others, I'm not sure if this northbridge is supported. Coreboot supports the 82801Ex (ICH5) and Gx (ICH7), but apparently no ICH6. > lspci -tvnn output: > -[0000:00]-+-00.0 Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller [8086:2590] > +-02.0 Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2592] > +-02.1 Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2792] > +-1d.0 Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 [8086:2658] > +-1d.1 Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 [8086:2659] > +-1d.2 Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 [8086:265a] > +-1d.3 Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 [8086:265b] > +-1d.7 Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller [8086:265c] > +-1e.0-[02-06]--+-00.0 Broadcom Corporation BCM4401-B0 100Base-TX [14e4:170c] > | +-01.0 Texas Instruments PCI6515 Cardbus Controller [104c:8036] > | +-01.2 Texas Instruments Device [104c:8037] > | \-03.0 Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller [14e4:4318] > +-1e.2 Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller [8086:266e] > +-1e.3 Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Modem Controller [8086:266d] > +-1f.0 Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge [8086:2641] > \-1f.2 Intel Corporation 82801FBM (ICH6M) SATA Controller [8086:2653] > > There is no Super I/O chip on the mainboard, nor one can be detected by > superiotool. Sadly, this is where my venture ends here as flashrom refuses > to identify the motherboard because it halts if it finds an unsupported > laptop, so I can't identify the flash chip. SPI, maybe? SPI flashing is pretty inevitable during coreboot development anyway (in most cases), because internal flashing requires a booted system and coreboot won't boot at first. Overall, I guess this wouldn't be an easy port. And given that this laptop is quite old, it's probably not worth it. (If you want to port a laptop that can run without the Intel ME, I'd recommend one with GM45 and ICH9.) Regards, Jonathan

1 0

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot May 2016