Fixed.
Best I can tell it was due to a clean build as all the other parameters are the same.
I had gone back to v4.4 to rebuild and check too, but the problem has persisted. Potentially to do with using .config from a different version of coreboot.
But it works so no more investigation ☺.
Naveed
From: Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com]
Sent: Thursday, 30 March 2017 12:49 AM
To: Naveed Ghori
Cc: coreboot(a)coreboot.org
Subject: Re: [coreboot] Coreboot 4.5: No early serial output
Hello Naveed,
> In Coreboot 4.4 (Intel baytrail FSP) early serial output use to work (first line being coreboot version followed by RTC Init)
> In Coreboot 4.5 it seems that serial output only works once the FSP initializes the serial port (first line being romstage_main_continue).
What entity initializes serial port in Coreboot 4.4 (BYT FSP or Coreboot itself)? In which stage?
Once you get answer to this question, you should know what to do for/in Coreboot 4.5 . ;-)
Zoran
On Wed, Mar 29, 2017 at 10:55 AM, Naveed Ghori <naveed.ghori(a)dti.com.au<mailto:naveed.ghori@dti.com.au>> wrote:
Hi all,
In Coreboot 4.4 (Intel baytrail FSP) early serial output use to work (first line being coreboot version followed by RTC Init)
In Coreboot 4.5 it seems that serial output only works once the FSP initializes the serial port (first line being romstage_main_continue).
Notes: Setup for spew output, using the debug serial port lines.
I am looking at what might have caused this but though I’d ask if this was a known issue, possibly already fixed with a patch or if it was an error on my part.
Note sure exactly where to search as I have already reviewed the changes in src/drivers/uart/uart8250io.c
Regards,
Naveed
Naveed Ghori | Lead Firmware & Driver Engineer
DTI Group Ltd | Transit Security & Surveillance
31 Affleck Road, Perth Airport, Western Australia 6105, Australia
P +61 8 9373 2905<tel:+61%208%209373%202905>,151 | F +61 8 9479 1190<tel:+61%208%209479%201190> | naveed.ghori(a)dti.com.au<mailto:naveed.ghori@dti.com.au>
Visit our website www.dti.com.au<https://linkprotect.cudasvc.com/url?a=http://www.dti.com.au&c=E,1,YR-Os6299…>
The information contained in this email is confidential. If you receive this email in error, please inform DTI Group Ltd via the above contact details. If you are not the intended recipient, you may not use or disclose the information contained in this email or attachments.
--
coreboot mailing list: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org>
https://www.coreboot.org/mailman/listinfo/coreboot<https://linkprotect.cudasvc.com/url?a=https://www.coreboot.org/mailman/list…>
Hi,
On 03/29/2017 06:48 PM, Toan Le manh wrote:
> @Andrey: The flashing is OK, but the board doesn't boot anything. The
> POST CODE is always "0".
> Even I tried flashing with IFWI .bin file released by Intel, the board
> still doesn't boot.
> Where can I select "Use IFWI stitching"?
make nconfig, select board, there will be option to "use IFWI
stitching". Then you will need to provide path to the ifwi file.
Best
Andrey
@Zoran: I tried flashing with the IFWI .bin file released by Intel, and the
file I got after building coreboot and stitching. Both don't work.
2017-03-29 18:00 GMT+01:00 Zoran Stojsavljevic <
zoran.stojsavljevic(a)gmail.com>:
> > ...tried flashing SPI chip (Winbond W25Q128FW)...
>
> Flashing with what (context in question)?
>
> (we'll come later to INTEL stitching tool, I have good
> perception/anticipation, developed for by INTEL) ;-)
>
> Thank you,
> Zoran
>
> On Wed, Mar 29, 2017 at 1:29 PM, Toan Le manh <lemanhtoantb(a)gmail.com>
> wrote:
>
>> I got the LeafHill CRB from Intel, tried flashing SPI chip (Winbond
>> W25Q128FW) using BeeProg2C.
>> However nothing worked. The Status Code remained "0".
>> Does anyone face the same problem? Could you please give me some advice?
>> Thanks a lot.
>>
>>
>>
>> --
>> coreboot mailing list: coreboot(a)coreboot.org
>> https://www.coreboot.org/mailman/listinfo/coreboot
>>
>
>
--
-----------------------------------------------------
Manh Toan Le
mimoOn Vietnam Ltd.
mimoOn GmbH - http://www.mimoon.de/
(84) (97) 844-4764
(84) (363) 638-811
lemanhtoantb(a)gmail.com
Toan.Le(a)mimoOn.de
Hi,
On 03/29/2017 04:29 AM, Toan Le manh wrote:
> I got the LeafHill CRB from Intel, tried flashing SPI chip (Winbond
> W25Q128FW) using BeeProg2C.
> However nothing worked. The Status Code remained "0".
Are you saying the flashing didn't work OR board doesn't boot after?
If latter, did you select "Use IFWI stitching" ?
Andrey
On 29.03.2017 10:52, Denis 'GNUtoo' Carikli wrote:
>>> To get a working Ethernet with (3) you need to set a
>>> valid mac address:
>>> In the installation documentation, you are expected to use ich9gen,
>>> however if you use it this way:
>>>> $ ./ich9gen
>>> It will not produce a valid MAC address. You must instead do
>>> something like that, and replace <A-VALID-MAC-ADDRESS> by a valid
>>> MAC address:
>>>> $ ./ich9gen --macaddress <A-VALID-MAC-ADDRESS>
>>> To find such MAC address, you have several options:
>>> - Look if it can be found on a sticker on the bottom of your laptop.
>>> - Reflash the original flash content and get it with:
>>>> $ ifconfig -a
>>> or:
>>>> ip link
>>
>> Pew, thanks for reminding me, that we have this in our wiki.
> I was not reminding you, I was talking to Zoran Stojsavljevic.
> That said, it indeed would have been faster for me to point to the wiki
> resources.
Sorry, this was badly articulated. The "thanks" was meant sincere.
I had this on my TODO list for some time. I think we should (if not
already done) extend ifdtool to toggle whatever bit is needed to run
without ME firmware. And let people use that instead of building a new
blob which only extends the list of entities you have to trust.
Nico
PS. Actually I think coreboot shouldn't handle these platform blobs at
all. But that's even harder to convince people of ;)
Hi,
After performing just an FLR (PCI function level reset) of a Gen8 Intel HD
graphics device, there's no VGA output from the device, no matter what I
try to do. I've had coreboot reset the graphics control register, VGA
control, VGA display disable bit, etc.
Has anyone seen anything like this? The only way I can get VGA restored is
by performing a system-level reset. But I just want to do an FLR. Any
ideas?
Thanks,
JP
Hello Micha,
On 27.03.2017 13:58, Michael Schröder wrote:
> Dear folks,
>
> i am interested in using coreboot with a MacMini 2007 (core2duo). It
> uses the same chipset (GM945) as the macbook2.1 which supported yet.
>
> I managed to read infos about the BIOS with flashrom.
> The verbose output is in the appendix.
>
> Is there a chance, that coreboot could be ported to MacMini2007?
you're on the wrong mailing list here. I'll move this to coreboot :)
Anyway, looking at coreboot, it supports not only the Macbook2,1 but
also the Macbook1,1 and iMac5,2, all with nearly the same code. IMO,
it's very likely that the Macmini2,1 matches one of them or comes close
at least. So there wouldn't be much work on the software side.
Before installing coreboot the first time, however, you should have a
solution to flash your MacMini externally (i.e. with an extra flash
programmer that can flash your BIOS/coreboot in case the machine doesn't
boot any more). It's just too easy to brick a machine when trying a
coreboot build that hasn't been tested before.
It's not unlikely that you already have suitable hardware. Most single-
board computers (RaspberryPi and the like) have a native SPI interface.
Beside that you'd need some cables and either an SOIC clip matching your
flash chip or a soldering iron.
Nico
Hi,
while doing LPC examination for keyboard actions on Getac laptop few
weeks ago, I noticed that the controlling sequence for backlight step
has been put outside of an ACPI spec for no visible reason (therefore
it is not possible to control backlight using unmodified ectool, for
example).
Sample step control sequence when Fn+Backlightxx is pressed looks like
following:
CT DT
0x80 0x17 // Reading 0x17 for current level, twice (why???)
0x80 0x17
0x86 0xff 0xf9 0x7f // Ok, now that`s weird, Why OEM-ing control
sequences is necessary in there?
0x80 0x17 // Reading updated value
I wonder if some people in list have touched simular kind of
development, is there any real reason behind using non-standard
control commands for EC? There *are* counterexamples in coreboot tree,
but they are using very extensive control command set and stepping
outside of spec looks reasonable. In my case, controller seemingly
uses just as few handles as the spec suggests, but omits standard ones
in favor of 0x85/0x86, could be there any practical reason for doing
this?
