Lenovo T410 Coreboot
by A. Veek
-----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-----
3 months, 1 week
Re: [coreboot] Mohon Peak, Memtest86+ does not start
by Kuzmichev Viktor
Thank you very much, this helped a lot! Now memtest is loading and it
successfully performs RAM tests.
But there is another issue. Somehow, input via serial console does not
work. And it seems like the problem is not in memtest, rather it's in
SeaBIOS or coreboot. There is no any prompt for input in coreboot. But
there is in SeaBIOS, and I was not able to enter boot menu since it did
not respond to F12. Although, SeaBIOS responds to the keyboard that is
directly connected to the board while memtest does not seem to respond
at all (at least, I tried to hit Esc which should reboot the board).
I've tried to search for this but so far found nothing.
Will appreciate any help.
Viktor
On 23.01.2015 18:47, Aaron Durbin wrote:
> On Fri, Jan 23, 2015 at 1:45 AM, Kuzmichev Viktor
> <kuzmichevviktorv(a)gmail.com> wrote:
>> Hello Stefan,
>>
>> Thank you for the tip, I'm currently looking into that. But I'm still not
>> sure how to specify the load address. My guess is that I should edit the
>> linking script properly to do it. By default it looks as follows
>> (memtest.lds):
>>
>> OUTPUT_FORMAT("elf32-i386");
>> OUTPUT_ARCH(i386);
>>
>> ENTRY(_start);
>> SECTIONS {
>> . = 0x10000;
>> _start = . ;
>> .data : {
>> *(.data)
>> }
>> }
>>
>> And here is the output of 'readelf -a memtest' command:
>>
>> ELF Header:
>> Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
>> Class: ELF32
>> Data: 2's complement, little endian
>> Version: 1 (current)
>> OS/ABI: UNIX - System V
>> ABI Version: 0
>> Type: EXEC (Executable file)
>> Machine: Intel 80386
>> Version: 0x1
>> Entry point address: 0x10000
>> Start of program headers: 52 (bytes into file)
>> Start of section headers: 239496 (bytes into file)
>> Flags: 0x0
>> Size of this header: 52 (bytes)
>> Size of program headers: 32 (bytes)
>> Number of program headers: 1
>> Size of section headers: 40 (bytes)
>> Number of section headers: 3
>> Section header string table index: 2
>>
>> Section Headers:
>> [Nr] Name Type Addr Off Size ES Flg Lk
>> Inf Al
>> [ 0] NULL 00000000 000000 000000 00 0
>> 0 0
>> [ 1] .data PROGBITS 00010000 010000 02a774 00 WA 0 0
>> 1
>> [ 2] .shstrtab STRTAB 00000000 03a774 000011 00 0
>> 0 1
>> Key to Flags:
>> W (write), A (alloc), X (execute), M (merge), S (strings)
>> I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
>> O (extra OS processing required) o (OS specific), p (processor specific)
>>
>> There are no section groups in this file.
>>
>> Program Headers:
>> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
>> LOAD 0x000000 0x00000000 0x00000000 0x3a774 0x3a774 RW 0x200000
>>
>> Section to Segment mapping:
>> Segment Sections...
>> 00 .data
>>
>> There is no dynamic section in this file.
>>
>> There are no relocations in this file.
>>
>> The decoding of unwind sections for machine type Intel 80386 is not
>> currently supported.
>>
>> No version information found in this file.
>>
>> So, the entry point is at the offset of 0x10000. But I think I should
>> somehow change the 'VirtAddr'. I've tried to edit the script in different
>> ways, for example, I've tried to add MEMORY command and then allocate
>> certain sections to the regions as explained here:
>> https://sourceware.org/binutils/docs/ld/REGION_005fALIAS.html#REGION_005f...
>> but haven't come to any success yet.
>>
>> Are there any advices you could give me? Am I even looking in the right
>> direction?
> Ya. You are on the right path. I just confirmed your findings locally.
> What you'd like to see is VirtAddr/PhysAddr = 0x10000 as well as
> offset to be 0x10000 because that would match with .data section. Also
> notice that MemSiz is 0x10000 greater than the Size of the .data
> section. So when this payload is loading all memory from 0x00000 to
> 0x10000 is filled with zeros before the start of the program at
> 0x10000.
>
> I poked around in trying to relink in different ways but it kept
> loading at 0. You could hexedit the memtest elf file. Apparently there
> is an 'ht editor' program. However, I couldn't for the life of me
> figure it out, but I was able to make it coredump trying to figure out
> how to navigate it. :/
>
> But I just found this page:
> http://dwarfdump.blogspot.com/2009/08/executable-file-editor-elf-editor.html
>
> $ hte memtest
>
> <hit space>
>
> Goto 'elf/program headers'. Hit <enter>
>
> Expand 'entry 0' with <enter>
> Goto 'offset'
> Hit <F4>.
> Make 'offset', 'virtual address', 'physical address' all to 00010000
> Make 'in file size' and 'in memory size' 00027008.
>
> Hit <F2> to save.
> Hit <F10> to quit.
>
> Those values were based on the memtest I compiled:
> $ readelf -e memtest
> ELF Header:
> Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
> Class: ELF32
> Data: 2's complement, little endian
> Version: 1 (current)
> OS/ABI: UNIX - System V
> ABI Version: 0
> Type: EXEC (Executable file)
> Machine: Intel 80386
> Version: 0x1
> Entry point address: 0x10000
> Start of program headers: 52 (bytes into file)
> Start of section headers: 225308 (bytes into file)
> Flags: 0x0
> Size of this header: 52 (bytes)
> Size of program headers: 32 (bytes)
> Number of program headers: 1
> Size of section headers: 40 (bytes)
> Number of section headers: 3
> Section header string table index: 2
>
> Section Headers:
> [Nr] Name Type Addr Off Size ES Flg Lk Inf Al
> [ 0] NULL 00000000 000000 000000 00 0 0 0
> [ 1] .data PROGBITS 00010000 010000 027008 00 WA 0 0 1
> [ 2] .shstrtab STRTAB 00000000 037008 000011 00 0 0 1
> Key to Flags:
> W (write), A (alloc), X (execute), M (merge), S (strings)
> I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
> O (extra OS processing required) o (OS specific), p (processor specific)
>
> Program Headers:
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> LOAD 0x000000 0x00000000 0x00000000 0x37008 0x37008 RW 0x200000
>
> Section to Segment mapping:
> Segment Sections...
> 00 .data
>
>
> After the instructions above I get the following:
>
> $ readelf -e memtest
> ELF Header:
> Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
> Class: ELF32
> Data: 2's complement, little endian
> Version: 1 (current)
> OS/ABI: UNIX - System V
> ABI Version: 0
> Type: EXEC (Executable file)
> Machine: Intel 80386
> Version: 0x1
> Entry point address: 0x10000
> Start of program headers: 52 (bytes into file)
> Start of section headers: 225308 (bytes into file)
> Flags: 0x0
> Size of this header: 52 (bytes)
> Size of program headers: 32 (bytes)
> Number of program headers: 1
> Size of section headers: 40 (bytes)
> Number of section headers: 3
> Section header string table index: 2
>
> Section Headers:
> [Nr] Name Type Addr Off Size ES Flg Lk Inf Al
> [ 0] NULL 00000000 000000 000000 00 0 0 0
> [ 1] .data PROGBITS 00010000 010000 027008 00 WA 0 0 1
> [ 2] .shstrtab STRTAB 00000000 037008 000011 00 0 0 1
> Key to Flags:
> W (write), A (alloc), X (execute), M (merge), S (strings)
> I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
> O (extra OS processing required) o (OS specific), p (processor specific)
>
> Program Headers:
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> LOAD 0x010000 0x00010000 0x00010000 0x27008 0x27008 RW 0x200000
>
> Section to Segment mapping:
> Segment Sections...
> 00 .data
>
>
> Notice now that we're only loading the .data section at 0x10000. I
> hope that helps.
>
>> Thanks in advance,
>> Viktor
>>
>>
>> On 20.01.2015 22:33, Stefan Reinauer wrote:
>>> * Kuzmichev Viktor <kuzmichevviktorv(a)gmail.com> [150120 14:31]:
>>>> Hello,
>>>>
>>>> I'm trying to load Memtest86+ on the Mohon Peak reference board from
>>>> CBFS and it fails.
>>>> My primary payload is SeaBIOS. Memtest is added using cbfstool, so
>>>> the layout of my ROM file is as follows:
>>>>
>>>> $ ./build/cbfstool build/coreboot.rom print
>>>> coreboot.rom: 8192 kB, bootblocksize 1024, romsize 8388608, offset
>>>> 0x600000
>>>> alignment: 64 bytes, architecture: x86
>>>>
>>>> Name Offset Type Size
>>>> cmos_layout.bin 0x600000 cmos_layout 1352
>>>> fallback/romstage 0x600580 stage 26616
>>>> fallback/ramstage 0x606dc0 stage 60446
>>>> fallback/payload 0x615a40 payload 55799
>>>> config 0x623480 raw 4323
>>>> revision 0x6245c0 raw 714
>>>> img/Memtest86+ 0x6248c0 payload 225028
>>>> (empty) 0x65b800 null 1001368
>>>> mrc.cache 0x74ffc0 (unknown) 65536
>>>> cpu_microcode_blob.bin 0x760000 microcode 83968
>>>> (empty) 0x774840 null 46936
>>>> fsp.bin 0x77ffc0 (unknown) 372736
>>>> (empty) 0x7db000 null 150424
>>>>
>>>> I've tried versions 4.20 and 5.01. Memtest86+ v4.20 just hangs, here
>>>> is output of SeaBIOS trying to load it:
>>>> Trying CBFS
>>>> Booting from CBFS...
>>>> Run img/Memtest86+
>>>> Segment 41544144 194420@0xffe24920 -> 194420@0x00000000
>>>> No compression
>>>>
>>>> And then nothing. Memtest86+ v5.01 goes a bit further, SeaBIOS finds
>>>> its entry point:
>>>> Trying CBFS
>>>> Booting from CBFS...
>>>> Run img/Memtest86+
>>>> Segment 41544144 224972@0xffe24920 -> 224972@0x00000000
>>>> No compression
>>>> Calling addr 0x00010000
>>> It looks like in both cases memtest86+ is loaded at address 0x00000000
>>> which will overwrite a bunch of memory, including the coreboot tables.
>>> Looks like the memtest86+ elf binary needs to specify a load address.
>>>
>>> Stefan
>>>
>>
>> --
>> coreboot mailing list: coreboot(a)coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
4 years, 1 month
Re: [coreboot] coreboot code of conduct
by Carl-Daniel Hailfinger
Hi Marc,
On 19.01.2015 01:49, Marc Jones wrote:
> On Sat Jan 17 2015 at 8:12:20 PM Carl-Daniel Hailfinger wrote:
>> Hi Marc,
>>
>> thanks for writing this up.
>>
>> On 16.01.2015 19:15, Marc Jones wrote:
>>> A coreboot code of conduct has been posted on the wiki.
>>> - http://www.coreboot.org/Code_of_Conduct
>>>
>>> I have written a blog post about why we have a code of conduct.
>>> - http://blogs.coreboot.org/blog/2015/01/16/coreboot-code-of-conduct/
>>>
>>> Feel free to give feedback on the policy and how else we can contribute
>>> to a welcoming and collaborative environment.
>> Given that the Code of Conduct has been announced publicly in a blog
>> post, the feedback is probably expected to be public as well. Apologies
>> if that is not the case.
>>
>> The current wording suggests that anyone can be expelled from the
>> community permanently without warning for either perceived harrassment
>> or for strongly enforcing the code of conduct. This is probably not the
>> intention.
> Open discussion is acceptable.
Adding that sentence to the CoC would be helpful.
>> Furthermore, the second paragraph of "Unacceptable Behaviour" is either
>> redundant or woefully incomplete. If you really think the word
>> "harassing" from the first paragraph needs to be defined, you should
>> define the other words from the first paragraph "intimidating",
>> "abusive", "discriminatory", "derogatory" and "demeaning" as well. I
>> suggest deleting that second paragraph.
> I'll disagree. Harassment is the most common problem in online communities
Real citation needed, not just some sentiment. For example, quite a few
feminist blogs point to intimidating and derogatory speech/actions as
the primary hurdles against female participation in online communities.
> and warrants the paragraph about those unacceptable behaviors.
If harassment is the most common problem, that definitely warrants
listing harassment first (which is not the case in the current CoC).
> Defining
> every other term would not make this policy any more robust.
Is the term "harassment" so unclear it warrants explanation? I thought
there was universal agreement that harassment is bad, but having to
define harassment implies that there is no such universal agreement (you
can't agree on something undefined).
I argue that creating our own homegrown definition of harassment (or
copying someone else's homegrown definition) makes this policy less
robust because this current homegrown definition is woefully incomplete.
>> Please define "community organizers". Did you mean "arbitration team"?
>> Or is it the community members present at an event?
> It isn't not meant to be specific to an arbitration team. These members may
> not be present in all cases and organizers of events and online communities
> should uphold the good standards of the community.
Thanks for clarifying. The CoC would benefit from adding this clarification.
>> How can we deploy this against people not part of our community? If
>> they're not part of the community in the first place, it is by
>> definition impossible to exclude them from our community and the Code of
>> Conduct in its current form does not apply. If, on the other hand, we
>> define everyone on the mailing list, everyone on IRC and everyone
>> visiting our booths at various conferences and trade shows as being part
>> of our community, we're going to overshoot the mark. I don't want to be
>> guilty by association just because some troll on IRC joins all channels,
>> spews some random offensive crap and disappears.
> It applies to everyone that participates in coreboot communication, online,
> at an event or in a conference booth. People that are not up to this
> standard of behavior are not welcome in our community and they should be
> asked to leave. If a troll joins and spams the channel, clearly ask them to
> leave. If they don't leave report them to a channel or IRCOP. If there is a
> question of the policy or of a behavior, please contact an organizer or
> someone from the arbitration team.
Great, thanks for the explanation and guideline!
Regards,
Carl-Daniel
4 years, 1 month
AP cores not starting
by Timothy Pearson
All,
I have a bit of a strange problem here. When I install an 6-core
(Istanbul) Opteron processor the AP cores don't start:
POST: 0x93
Setting up local apic... apic_id: 0x00 done.
POST: 0x9b
CPU model: Six-Core AMD Opteron(tm) Processor 2419 EE
siblings = 05, CPU #0 initialized
CPU1: stack_base 00157000, stack_end 00157ff8
Asserting INIT.
Waiting for send to finish...
+Deasserting INIT.
Waiting for send to finish...
+#startup loops: 2.
Sending STARTUP #1 to 1.
After apic_write.
Startup point 1.
Waiting for send to finish...
+Sending STARTUP #2 to 1.
After apic_write.
Startup point 1.
Waiting for send to finish...
+After Startup send_status: 0 accept_status: 0.
CPU 0x01 would not start!
CPU2: stack_base 00156000, stack_end 00156ff8
Asserting INIT.
Waiting for send to finish...
+Deasserting INIT.
Waiting for send to finish...
+#startup loops: 2.
Sending STARTUP #1 to 2.
After apic_write.
Startup point 1.
Waiting for send to finish...
+Sending STARTUP #2 to 2.
After apic_write.
Startup point 1.
Waiting for send to finish...
+After Startup send_status: 0 accept_status: 0.
CPU 0x02 would not start!
CPU3: stack_base 00155000, stack_end 00155ff8
Asserting INIT.
Waiting for send to finish...
+Deasserting INIT.
Waiting for send to finish...
+#startup loops: 2.
Sending STARTUP #1 to 3.
After apic_write.
Startup point 1.
Waiting for send to finish...
Quad core (Barcelona) CPUs function normally. It almost looks like the
siblings are not executing any code whatsoever, but I'm not sure. All 5
siblings are enabled in the appropriate registers.
Any hints?
--
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645
http://www.raptorengineeringinc.com
4 years, 1 month
[SOLVED] Read the Coreboot version in the .rom binary
by Patrick Agrain
Hi Patrick,
Thanks for the tip and the related code snippet. It works like a charm.
Best regards,
Patrick Agrain
Am 2015-01-28 15:39, schrieb Patrick Agrain:
> Is there a way to read the coreboot version (as a string or as binary
> chain) from inside the build coreboot.rom file.
On x86, it's stored through src/arch/x86/lib/id.inc
It's a somewhat arcane format (historically grown), and is typically
ends
0x80 bytes before the end of the image. The last 4 qwords are the .long
values from which you can calculate the address of the version field
http://review.coreboot.org/gitweb?p=filo.git;a=blob;f=flashupdate/flashup...
test_id_section() and its caller provide an example for parsing that.
Regards,
Patrick
4 years, 1 month
Re: [coreboot] Help With port Coreboot to HP XW8400
by user7
W dniu 2015-01-30 01:47:37 użytkownik Matt Taggart <matt(a)lackof.org> napisał:
> user7 writes:
> > Hello All.
> > I have problem with port coreboot to HP XW8400. http://i.imgur.com/fFqTk95.png
> > http://h50146.www5.hp.com/lib/doc/manual/workstation/xw8400/364898-001.pdf
> > i want install on it Intel Xeon x54xx but i can install only x53xx.
> > This motherboard have:
> > Intel 5000X Chip.
> > Intel =C2=AE 631xESB/632xESB I/O Controller Hub (ESB2)
> > LSI SAS 1064 I/O Controller
> > BCM5752 - Broadcom
> > I check in coreboot siete and support chipset is 5000P, and I have 5000X it=
> > is possilble to easy port coreboot on my platform?
>
> I tried a similar experiment with putting an x54xx in an xw6400 (but not
> with cooreboot). It didn't work with the vendor BIOS (but maybe this is
> what you are trying to solve?) Here's a thread about it
>
> http://h30499.www3.hp.com/t5/Workstations-z-series-xw-series/Adding-processo
> r-to-the-xw6400-fastest-Quad-Core-supported/td-p/2381625
>
> --
> Matt Taggart
> matt(a)lackof.org
>
>
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
It is impossible to install unsupported processor in vendor BIOS therefore I must use coreboot.
before tired to use some external program but any one doesn't run because BIOS is from Compaq.
I don't know if coreboot will be work on HP XW8400 (?) if not I cannot help myself because I can't programing.
4 years, 1 month
FOSDEM 2015
by Carl-Daniel Hailfinger
Hi everyone!
31 Jan 2015 and 1 Feb 2015:
https://fosdem.org/2015/news/2014-09-19-call-for-participation-part-two/
I would love to be there again and some of you already said they'd try
to be there, but I forgot who. Who can be there with me at the booth and
when can you be there?
A preliminary stand application has already been sent by me to somewhat
hit the deadline, but I'd like to fill it in a bit more.
Side note: If someone has an interesting topic for a lightning talk,
please submit one!
Regards,
Carl-Daniel
4 years, 1 month
