-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi @ all,
is there a Coroboot for the Lenovo T410 Laptop?
Greetings
Alex Veek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iF4EAREIAAYFAlNxKzsACgkQ53cWmi2XuzOOXAD8CNLPoycJNftQzeHnMQbl8ZG9
4y2SPIHwLota1/Gsfm0BAJzhG2M+MKXDBJgazHjt/HM2DyAeHi6S24sGcwd1W2GN
=sFKM
-----END PGP SIGNATURE-----
#95: Run coreboot in VirtualBox
---------------------------------+------------------------------------------
Reporter: uwe | Owner: somebody
Type: defect | Status: new
Priority: minor | Milestone:
Component: misc | Version:
Keywords: | Dependencies:
Patchstatus: there is no patch |
---------------------------------+------------------------------------------
It would be nice if we could test coreboot images in VirtualBox, see
http://virtualbox.org/.
VirtualBox does not (yet) provide a simple mechanism to use a different
BIOS in their emulated machines (something like "-L" in qemu). Instead the
BIOS image (a custom bochs BIOS + LGPL'g VGABIOS) is converted to C code
(an array of bytes, or the like) and merged into the VirtualBox
executable.
The relevant files are
{{{
src/VBox/Devices/PC/DevPcBios.cpp
bldprogs/bin2c.c
}}}
if someone want to hack VirtualBox to easily support using coreboot images
instead of their usual BIOS.
--
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/95>
coreboot <http://www.coreboot.org/>
On 25.08.2014 04:39, Charles Devereaux wrote:
> Hello
>
> Previously
> (http://www.coreboot.org/pipermail/coreboot/2014-July/078320.html) I
> mentioned that 3 bugs seemed to be related to the DSDT:
> - missing ACPI events when the stylus is inserted/removed
How is the OS supposed to react to them?
> - errors when trying to make the leds blink with tpacpi
details? usecase?
> - errors during TPM initialization
Some people here would call it a feature.
> Ideally, the DSDT should be fixed within coreboot, but this goes beyond
> my present abilities.
Not true. Just do the same changes to the corresponding *.asl files in
coreboot repo and send the patch to gerrit. Other than a layer of
preprocessing, it's exactly the same code as you got from disassembly.
Hi,
I am managing to replace BIOS with coreboot on a Rangeley evaluation board, but the serial console cannot display message after coreboot calls console_init() in src/southbridge/intel/fsp_rangeley/romstage.c.
The console is connected to UART0 (0x3f8), which has been verified by BIOS.
My configuration of coreboot includes:
Mainboard: Intel->Mohon Peak CRB, which is the only choice for Rangeley
FSP and microcode: downloaded from Intel FSP (https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=23676).
Payload: U-boot-x86 (should be irrelevant to payload, since coreboot just enters romstage)
I have checked that the UART0 registers should have been initialized.
The TX FIFO should also work: after out something to 0x3f8, LSR will change.
I have also checked some other registers might related to UART.
The UART_CONT (0:1f.0-0x80) is in the default state (0x00000003).
The GPIO Use Select is also in default state: GPIOS_13 is 0.
Is there any other register can block the UART output?
Besides, actually the coreboot finally run deeply.
The post code changes from 47->66->67->69->...>72->73->77... and finally stop at 0xE2.
But there's no console display so I cannot know where it stops.
Regards,
Qingxin
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 21/08/14 23:41, ron minnich wrote:
> On Thu, Aug 21, 2014 at 2:10 PM, The Gluglug <info(a)gluglug.org.uk>
> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>>
>>
>> On 21/08/14 22:08, The Gluglug wrote:
>>> A little quirk I noticed. If I put the machine in suspend
>>> while an ethernet cable is plugged in to a switch (or if
>>> plugging it in after suspending), the green light from the
>>> ethernet/eth0 is still active.
>>>
>>> Any ideas?
>>>
>>
>> The same thing also happens while the machine is powered off, if
>> I leave the AC adapter/charger connected.
>
>
> and only on coreboot?
>
> I can't recall but I did have laptops that would light the LED even
> when off, I always assumed it was the ME
>
> ron
>
Haven't tried it on factory.bin. Will let you know.
i945 doesn't have ME/AMT, as far as I know.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJT9ps5AAoJEP9Ft0z50c+UWKsIAJn5w/+6RxZ6oyhqaHSuJoBq
2/YHDL5TYM7EW0XoBstcB2NS7W/lWtWfwpCvNvM9R3ynliqPoAjErMZIuTwPM4p9
wBFvNdSWJGHOgxi8KEDA1n2Af0Dhfoys6Wb+uI3hflGGunJHz05QWiMEos0dWkmU
JsZVr2HCrjIKTGooXJxZXfRlD6SY2S3PNY7myDcfeAaTnx6kCsySFCqBkfIUTIhf
Mtg1NosYrbmNAXqROwrHf5LO3oAJ41zODZraMspYy+QDE8XvO2wbzkDBtglV4rBn
V7qO7PaS1l1jfOlERTd3A6ZEXI4ltzr8BTwe3ZTZod+zrs9R9/May4JasN4lKe4=
=on0Y
-----END PGP SIGNATURE-----
On 22/09/14 19:59, Aaron Durbin wrote:
> On Mon, Sep 22, 2014 at 12:24 PM, John Lewis <jlewis(a)johnlewis.ie> wrote:
>>
>>
>> On 22/09/14 17:39, Aaron Durbin wrote:
>>>
>>> On Sun, Sep 21, 2014 at 8:14 AM, John Lewis <jlewis(a)johnlewis.ie> wrote:
>>>>
>>>> On 21/09/14 14:06, Aaron Durbin wrote:
>>>>>
>>>>>
>>>>> On Sun, Sep 21, 2014 at 7:44 AM, John Lewis <jlewis(a)johnlewis.ie> wrote:
>>>>>>
>>>>>>
>>>>>> snip
>>>>>>
>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I'm trying to flash the ROM externally now, but it's telling me it
>>>>>>>>>>> can't
>>>>>>>>>>> disable block protection. It gets as far as trying to erase
>>>>>>>>>>> 0x600000,
>>>>>>>>>>> then
>>>>>>>>>>> goes through all the erase functions, finally crapping out. Do you
>>>>>>>>>>> know
>>>>>>>>>>> how
>>>>>>>>>>> I can work-around that?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The write protect screw is removed, right? After that the flash's
>>>>>>>>>> write protect register needs to be updated. Do you know the status
>>>>>>>>>> register values? Flashrom should be able to do that.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes, it is definitely removed - I didn't put it back in after the
>>>>>>>>> initial
>>>>>>>>> brick. It says the register value is 0x94 - I did also hook up the
>>>>>>>>> Bus
>>>>>>>>> Pirate for use with statically linked ChromeOS Flashrom (as the
>>>>>>>>> particular
>>>>>>>>> version I have doesn't have Dediprog support) - I had an idea
>>>>>>>>> running
>>>>>>>>> --wp-disable might help, but it didn't recognise the chip and said
>>>>>>>>> the
>>>>>>>>> register was already 0x94 (paraphrasing). I am currently compiling a
>>>>>>>>> newer
>>>>>>>>> statically linked version of ChromeOS Flashrom using the SDK, in the
>>>>>>>>> hope
>>>>>>>>> that might be able to do the job. Am I barking up the wrong tree
>>>>>>>>> though, or
>>>>>>>>> is there something else I could do?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> You are in the right spot. The fact that it failed at 6MiB is very
>>>>>>>> indicative of the SPI part write protection. There are, however, more
>>>>>>>> than one status register. There should be 3 of them:
>>>>>>>>
>>>>>>>> Read Status Register-1 (05h), Status Register-2 (35h) & Status
>>>>>>>> Register-3 (15h)
>>>>>>>>
>>>>>>>> Btw, I'm referencing W25Q64FW datasheet.
>>>>>>>>
>>>>>>>> -Aaron
>>>>>>>>
>>>>>>> Yeah, using --wp-status with Clapper's Flashrom tells me that the
>>>>>>> write
>>>>>>> protect *is* enabled, after all. But I can't see where, apart from the
>>>>>>> screw I took out right next to the battery, the write-protect screw
>>>>>>> would be? And I'm confused as to why it let me write initially if the
>>>>>>> write-protect wasn't enabled.
>>>>>>>
>>>>>>> This is the output I get trying to run --wp-disable:
>>>>>>>
>>>>>>> w25_set_srp0: old status: 0x94
>>>>>>> w25_set_srp0: new status: 0x94
>>>>>>> w25q_disable_writeprotect(): error=1.
>>>>>>> No -i argument is specified, set ignore_fmap.
>>>>>>> FAILED
>>>>>>> Setting SPI voltage to 0.000 V
>>>>>>> restore_power_management: Re-enabling power management.
>>>>>>>
>>>>>>
>>>>>> I've sorted it out now - had to bridge pins 3,7 and 8 using a large
>>>>>> paper-clip, as alluded to in the OSCON presentation, referenced by
>>>>>> Barry
>>>>>> Schultz. Never had to do that before, oddly.
>>>>>
>>>>>
>>>>>
>>>>> Interesting. You had to hard pull WP# and HOLD#. I need to take a look
>>>>> at that circuit. I wouldn't have expected you to do that either.
>>>>>
>>>> I don't understand it obviously, but I thought the main point was to get
>>>> voltage to the WP pin to disable the hard write-protect.
>>>
>>>
>>> I looked at the schematics. There's a lot of complexity in that area
>>> because of voltage differences. I'm not surprised you had to short WP#
>>> to SPI VCC to make it work. I'm guessing this is most likely required
>>> for all baytrail based ChromeOS devices.
>>>
>>>>
>>>> Anyway, back to our original problem - the ROM with the refcode section
>>>> changed from type 50 to type 10, still doesn't give us anything. As an
>>>> experiment, I tried extracting one of my own kernel payloads, then adding
>>>> it
>>>> back in unchanged as a raw file, and changing the type to 50 on my Falco,
>>>> and that doesn't work either.
>>>>
>>>> Could we try turning the extracted refcode binary back into an elf? How
>>>> would I go about that?
>>>
>>>
>>> I'm told firmware-clapper-5216.199.B is the correct firmware branch
>>> to use. The other one is old and may not be working (this issue?).
>>>
>>> I'd be curious to see if you can get anything from your image.
>>> http://www.chromium.org/chromium-os/servo has the servo pin
>>> definitions for the cable. You could get uarts from EC and the
>>> baytrail part.
>>>
>>> As for changing that thing back to ELF, it's definitely possible. Can
>>> we try using the proper branch first? If not, the refcode is an
>>> rmodule so you'll just need to take the relocation information and the
>>> code to create a new ELF. We don't have a tool to do that right now,
>>> but it wouldn't be too too hard.
>>>
>>
>> I already switched to 5216.199.B today as that's the one the shellball is
>> using. Unfortunately, it didn't make too much difference.
>>
>> That's a bit over my head - I am a complete dunce when it comes to
>> electronics, can't even use a soldering iron. I don't know how to read
>> schematics even. Unless you or someone else can illustrate further what
>> would need to be done there, it's going to be a no go. I think Ron did
>> semi-promise me a servo board near the start of the year though. ;)
>>
>> I also tried recreating the elf using the commands on the Hacking VMX page
>> http://www.chromium.org/chromium-os/developer-information-for-chrome-os-dev…
>> but I'm fairly sure some of those values would be wrong. Happily though, the
>> elf ended up exactly the right size once it was in the ROM (4296 bytes).
>> Still didn't help though.
>>
>> Finally, I enabled the i915 driver in my Jeltka embedded Linux in the hope
>> that there was just something wrong with SeaBIOS/video so it might get as
>> far as the payload and give me a display regardless. But again, that didn't
>> help. Tried with refcode done both ways.
>>
>
> My concern is that we are focusing on this refcode thing, though
> valid, but we're tripping over other issues. The only way I can see of
> obtaining proof of life is to either get an LPC debug decoder (could
> attach to TPM) or getting uarts from the EC and x86. The servo
> connector has the EC and x86 uarts on it. We could tap into that.
>
> Could you load your SPI image to a place I could pull it down and
> inspect it? I may be able to magically find some issue. But don't hold
> your breath. :)
>
The only other thing that sticks out to me is vboot. Even though I have
"# CONFIG_VBOOT_VERIFY_FIRMWARE is not set" in the config, the build
still expects to find vboot_api.h from platform/vboot_reference. I've
managed with some help to reasonably reliably get other models working
using ChromeOS coreboot in the past, so I have to assume it's something
new like this or refcode, causing the issue. It seems to me that a few
problems are caused by code from one feature being tightly integrated
with code from another, and when you don't want to use one of the
features, things break.
I've uploaded my last go to https://johnlewis.ie/coreboot-clapper-220914.rom
Thank you!
John.
On Tue, Sep 30, 2014 at 07:00:12AM -0700, David Hubbard wrote:
>
> The console output is really unhelpful if the DDR3 init finds no usable
> ram. I suspect that is your problem, but you'll want to turn on additional
> debug output (sorry, you caught me at a bad time, I should look up the
> config option for you). If indeed it isn't able to init your DDR3, the
> output would look like this.
>
> Hope that helps.
It really does, thanks a lot!
I'll next try the "2 blue slots"
http://www.coreboot.org/Board:asus/f2a85-m#Memory
and switch on some debugging if necessary.
I can dig out the options, the hint that I'm on the
right track is very valuable.
Thanks!
Torsten