Re: [coreboot] Where is the first instrucion?

[Rafael Machado]

Hi Anthony, thanks for the advise and for the explanation.

You are totally right about posting firmware code on the forum.

Rafael

Em seg, 25 de jul de 2016 15:59, Tony Marchini  escreveu:

> I would like to start with, Do not disassemble copyrighted firmware and
> CERTAINLY don't post your results to a public forum.
>
> That said, the di in this case is being used as a return instruction in a
> piece of BIOS that clearly doesn't have the memory enabled yet. No memory,
> no stack. No stack then no call /ret instructions. Here they set the return
> point and put it in the di register and then "call" the function. The
> instruction after the jp di is another function.
>
> Anthony A. Marchini
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Where is the first instrucion?

[Rafael Machado]

Thanks a lot Zoran.
I will!

Rafael

Em seg, 25 de jul de 2016 14:13, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> escreveu:

> Hello Rafael,
>
> Let me try hard... ;-)
>
> Let us look into what actually we have here, in Coreboot: in bootblock
> phase, at the very beginning.
> Let me tell you what I am looking into (what cb tree): [zoran@localhost
> coreboot-09.06.2016]$ git describe
> 4.4-455-g538b324
>
> Let us backtrace, to understand what is actual thread of execution:
> src/arch/x86/prologue.inc
> src/cpu/x86/16bit/entry16.inc
> src/cpu/x86/16bit/reset16.inc
> src/cpu/x86/32bit/entry32.inc
> src/cpu/x86/sse_enable.inc
> src/arch/x86/bootblock_simple.c
>
> Please, carefully examine what I pointed/presented here... And let us know
> your thoughts.
>
> Best Regards,
> Zoran
>
> On Mon, Jul 25, 2016 at 6:03 PM, Rafael Machado <
> rafaelrodrigues.mach...@gmail.com> wrote:
>
>> Hi guys. Long time since my last e-mail.
>>
>> It's hard to synchronize my day work with my firmware studies. Since my
>> projects are more UEFI related I usually do not have to much time to study
>> the legacy way, but It's really cool and Ill not give up :)
>>
>> Since the last talk I was doing what everyone kindly proposed. (by the
>> way thank you all for the guidance.)
>>
>> Now I'm disassembly an old systems bios I have, but I cannot understand
>> what is happening in a specific section of the code. (I'm using radare2 for
>> my studies)
>>
>> The code is:
>>
>> f000:0fcb 66b9ff02mov ecx, 0x2ff
>> f000:0fd1 0f32 rdmsr ; read register
>> 0x2ff (IA32_MTRR_DEF_TYPE)
>> f000:0fd3 0fbae80b  bts ax, 0xb ; Enable bit 11 (MTRR
>> Enable).
>> f000:0fd7 0fbae80a  bts ax, 0xa ; Enable bit 10 (Fixed
>> MTRR Enable).
>> f000:0fdb 0f30 wrmsr; Write changes to
>> MTRR
>> f000:0fdd 0f20c0 mov eax, cr0
>> f000:0fe0 660fbaf01e   btr eax, 0x1e   ; Bit 30 means CD - Cache
>> disabled.
>> f000:0fe5 660fbaf01d   btr eax, 0x1d   ; Disable bit 29. NW - No
>> Write-through
>> f000:0fea 0f22c0 mov cr0, eax   ; Write changes to CR0
>> f000:0fed ffe7  jmp di
>> f000:0fef 0f20c0  mov eax, cr0
>> f000:0ff2 660fbae81e   bts eax, 0x1e
>> f000:0ff7 660fbae81d   bts eax, 0x1d
>> f000:0ffc 0f22c0  mov cr0, eax
>>
>>
>> Here is the code with my notes. I understand that some MTRR were set, and
>> now the processor will be "configured".
>> We see at address f000:0fe0 and f000:0fe5 that the CR0 register is being
>> changed and after that the changes are saved.
>>
>> Now I have two questions.
>>
>> 1 - After CR0 changes get completed there is a "jmp di" instruction. This
>> does not make any sense to me. Does anyone know why this is needed ? As
>> far as I could check di value is 0x0 at this point. I think
>>
>> 2 - After the "jmp di" a "CR0 Déjà vu" code is executed. Any idea why
>> this is needed ?
>>
>> Thanks everyone
>> Rafael R. Machado
>>
>>
>> Em seg, 11 de jan de 2016 às 03:57, Alex G. 
>> escreveu:
>>
>>> On 01/10/2016 10:23 AM, ron minnich wrote:
>>> > One thing I think you'd enjoy doing is building the qemu target,
>>> setting
>>> > up qemu with gdb, and just watching what happens, instruction by
>>> > instruction, as the system boots.
>>>
>>> One exercise I liked doing was to rewrite the entire boot flow, from
>>> reset vector to protected mode entry. Tested on qemu, put it on
>>> hardware, nothing burned.
>>>
>>> Alex
>>>
>>> > ron
>>> >
>>> > On Sun, Jan 10, 2016 at 3:28 AM Rafael Machado
>>> > >> > > wrote:
>>> >
>>> > Hi Peter and Rudolf.
>>> > Thanks for the answers and tips. They are realy helpfull !
>>> > I'll take a look.
>>> >
>>> > Rafael R. Machado
>>> >
>>> >
>>> > Em Sáb, 9 de jan de 2016 17:19, Rudolf Marek >> > > escreveu:
>>> >
>>> > Hi,
>>> >
>>> > I guess your question is more general than the coreboot related
>>> > right?
>>> >
>>> > If you have a firmware image dump of the flash (not the file
>>> you
>>> > download from
>>> > board vendor) then yes, first location to be executed is the
>>> > instruction located
>>> > 16 bytes before end of the image.
>>> >
>>> > In coreboot see in build/ bootblock_inc.S which also has
>>> > reset16.inc and
>>> > entry16.inc which is a real start. Consult the Intel or AMD
>>> > manual to see the
>>> > CPU state after reset. The CPU starts in real mode, but CS base
>>> > is shifted to
>>> > last 64KB before end of 4GB address space. In general your CPU
>>> > starts in
>>> > compatible mode with 8086 manufactured in 1978.
>>> >
>>> > Thanks
>>> > Rudolf

Re: [coreboot] kexec of Xen hypervisor from a Linux payload

[Trammell Hudson]

On Mon, Jul 25, 2016 at 01:27:22PM -0600, Trammell Hudson wrote:
> I did find this note from 2008 that mentioned a similar
> issue regarding xen, kexec and coreboot:
> 
> http://ward.vandewege.net/blog/2008/08/kexecing-into-a-xen-kernel/

Following the links to the xen-devel mailing list had some hints:

# There seems to be a regression with regard to kexec'ing into
# a Xen kernel between Xen 3.1.0 (confirmed working) and 3.1.3
# (confirmed not working). I would try 3.1.1 and 3.1.2 but
# source for 3.1 versions older than 3.1.3 no longer seems to
# be available for download. I still had source for 3.1.0
# lying around, luckily.

I decided to try Xen 3.1.0 and found that the hypervisor
does start up just fine when kexec'ed from my Linux payload
launched from Coreboot (although my 4.6 payload isn't
compatible with the ELF loader used by the older Xen):

https://www.flickr.com/photos/osr/27931937284/in/photostream/lightbox/

Ward's further testing was the Xen 3.2 tree would fail to kexec
even with the "no-real-mode" flag and came to the conclusion that:

# This is likely a coreboot bug, so I'll have to track that
# down. Any information about differences between what 3.2.1
# and 3.1.4 require to be kexec'ed into would be most helpful
# though.

Unfortunately there weren't any followups.

-- 
Trammell

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Thinkpad x230 video glitches during boot

[Trammell Hudson]

On Mon, Jul 25, 2016 at 05:30:07PM +, ron minnich wrote:
> [...] I'm starting to worry about my toolchain.

My build machine is a stock Ubuntu 15.10:

diamond:~/build/coreboot: gcc -v -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.2.1-22ubuntu2' 
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-5 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib 
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-multiarch --disable-werror --with-arch
 -32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib 
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2) 

-- 
Trammell

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Microcode problem with Braswell CPU

[Zoran Stojsavljevic]

Hello Alex,

It is awhile... Opportunity just did struck (suddenly/plotzlich), so I am
back!

While lurking around in Coreboot, trying to solve some "Mystery of digital
Orga.ni.sms", I ran into very interesting file:
./src/include/console/post_codes.h

Coreboot tree I am using: [zoran@localhost coreboot-09.06.2016]$ git
describe
4.4-455-g538b324

Maybe, it is worth looking into it. You tell us?

Zoran

On Tue, May 3, 2016 at 10:28 AM, Alexander Böcken <
alexander.boec...@junger-audio.com> wrote:

> Hello Zoran,
>
> again, thanks for your clues to this problem. I don't think post code 0x52
> is about memory configuration. The post code appears when I call
> TempRamInit which is supposed to enable Cache-as-RAM. Real memory is
> initialized at a later call to FspMemoryInit. coreboot supplies the
> location of the microcode and a cachable region to TempRamInit.
> Additionally, there are some settings that can be applied to the FSP image
> with Intel's Binary Configuration Tool. I don't know if these are used
> during TempRamInit, but I'll try and fiddle around with them.
>
> I agree, it would be helpful to have a list of post codes that can be
> output by FSP. Otherwise it's all speculation as what is wrong.
>
> Regards,
> Alex
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ASUS KFSN4-DRE (K8) Automated Test Failure [master]

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/25/2016 12:55 PM, Raptor Engineering Automated Coreboot Test Stand
wrote:
> The ASUS KFSN4-DRE (K8) fails verification for branch master as of commit 
> b8257df83b1543c5139bec91dbd77150456f96a3
> 
> The following tests failed:
> BOOT_FAILURE

This looks like K8 hardware failure (again).  Please ignore.

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJXlmnoAAoJEK+E3vEXDOFb9asIAJSagVzz0rVC3feh93JK1Bzx
ikkpgda/Lui5qoI15qTQ2JLg/ZqCgDHbl72KtATU9U0R3wJsgQ2d8CH/ooh8er+Z
ZgsC9EJiZE8l2csfPy1y8gPeLyfrauAqEBRMSZHyPGgWHrquG1Al+u2kGW7eJbT6
0/XegrbCxXVrCf+ETuTOOemOCVGa5HyK+Tf14pSfb3ICCMozdnoBQZjP7dOdbKQd
Cl7L87ltSziv/rc5FBoYzHh0LdK8d1SBRSnzZm9KbRZtMBXELpWtGrIEcDUOK1UY
Lrd6k/2XPmb13QDi7AdiA+oyGMgQKQJJiSyygfJCG3L3vuykFUBN45hSdcK4RO4=
=e/Jj
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] kexec of Xen hypervisor from a Linux payload

[Trammell Hudson]

On Mon, Jul 25, 2016 at 02:42:11PM +0200, Zoran Stojsavljevic wrote:
> [...]
> *Probably some module required for your baremetal fedora is missing
> in initramfs. First of all, remove "quiet" option to receive more
> details. If that's about missing module, you can regenerate initramfs:

The system boots fine under coreboot+seabios, so I'm fairly
certain it isn't an initrd problem.  There are no modules at
all in the kernel that I've embedded as the coreboot payload.
Even without quiet there is no output after the "kexec_core:
Starting new kernel" message.

I did find this note from 2008 that mentioned a similar
issue regarding xen, kexec and coreboot:

http://ward.vandewege.net/blog/2008/08/kexecing-into-a-xen-kernel/

# The no-real-mode option stops Xen from doing some bios
# calls, and it also tells it to ignore the e820 bios table.
# Note that you need to pass no-real-mode as the first xen
# command line argument, otherwise it won’t work.
# 
# And somehow that solves the problem for Xen 3.1.3 and 3.1.4,
# both under qemu + coreboot and qemu + bochs. Kexec’ing into
# Xen 3.1.2 triple-faults qemu under qemu + coreboot, but
# works fine under qemu + bochs. That smells like a coreboot
# bug. I’ll try on real hardware tomorrow to see if this bug
# is specific to our qemu port, or a more general coreboot
# problem. To be continued..

"no-real-mode" does not affect my results on real hardware.
I'm still seeing what looks like a triple fault, leading to
coreboot being restarted.  At least it gets back to the
prompt in less than a second...

-- 
Trammell

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Where is the first instrucion?

[Zoran Stojsavljevic]

Hello Rafael,

Let me try hard... ;-)

Let us look into what actually we have here, in Coreboot: in bootblock
phase, at the very beginning.
Let me tell you what I am looking into (what cb tree): [zoran@localhost
coreboot-09.06.2016]$ git describe
4.4-455-g538b324

Let us backtrace, to understand what is actual thread of execution:
src/arch/x86/prologue.inc
src/cpu/x86/16bit/entry16.inc
src/cpu/x86/16bit/reset16.inc
src/cpu/x86/32bit/entry32.inc
src/cpu/x86/sse_enable.inc
src/arch/x86/bootblock_simple.c

Please, carefully examine what I pointed/presented here... And let us know
your thoughts.

Best Regards,
Zoran

On Mon, Jul 25, 2016 at 6:03 PM, Rafael Machado <
rafaelrodrigues.mach...@gmail.com> wrote:

> Hi guys. Long time since my last e-mail.
>
> It's hard to synchronize my day work with my firmware studies. Since my
> projects are more UEFI related I usually do not have to much time to study
> the legacy way, but It's really cool and Ill not give up :)
>
> Since the last talk I was doing what everyone kindly proposed. (by the way
> thank you all for the guidance.)
>
> Now I'm disassembly an old systems bios I have, but I cannot understand
> what is happening in a specific section of the code. (I'm using radare2 for
> my studies)
>
> The code is:
>
> f000:0fcb 66b9ff02mov ecx, 0x2ff
> f000:0fd1 0f32 rdmsr ; read register 0x2ff
> (IA32_MTRR_DEF_TYPE)
> f000:0fd3 0fbae80b  bts ax, 0xb ; Enable bit 11 (MTRR
> Enable).
> f000:0fd7 0fbae80a  bts ax, 0xa ; Enable bit 10 (Fixed
> MTRR Enable).
> f000:0fdb 0f30 wrmsr; Write changes to MTRR
> f000:0fdd 0f20c0 mov eax, cr0
> f000:0fe0 660fbaf01e   btr eax, 0x1e   ; Bit 30 means CD - Cache
> disabled.
> f000:0fe5 660fbaf01d   btr eax, 0x1d   ; Disable bit 29. NW - No
> Write-through
> f000:0fea 0f22c0 mov cr0, eax   ; Write changes to CR0
> f000:0fed ffe7  jmp di
> f000:0fef 0f20c0  mov eax, cr0
> f000:0ff2 660fbae81e   bts eax, 0x1e
> f000:0ff7 660fbae81d   bts eax, 0x1d
> f000:0ffc 0f22c0  mov cr0, eax
>
>
> Here is the code with my notes. I understand that some MTRR were set, and
> now the processor will be "configured".
> We see at address f000:0fe0 and f000:0fe5 that the CR0 register is being
> changed and after that the changes are saved.
>
> Now I have two questions.
>
> 1 - After CR0 changes get completed there is a "jmp di" instruction. This
> does not make any sense to me. Does anyone know why this is needed ? As
> far as I could check di value is 0x0 at this point. I think
>
> 2 - After the "jmp di" a "CR0 Déjà vu" code is executed. Any idea why this
> is needed ?
>
> Thanks everyone
> Rafael R. Machado
>
>
> Em seg, 11 de jan de 2016 às 03:57, Alex G. 
> escreveu:
>
>> On 01/10/2016 10:23 AM, ron minnich wrote:
>> > One thing I think you'd enjoy doing is building the qemu target, setting
>> > up qemu with gdb, and just watching what happens, instruction by
>> > instruction, as the system boots.
>>
>> One exercise I liked doing was to rewrite the entire boot flow, from
>> reset vector to protected mode entry. Tested on qemu, put it on
>> hardware, nothing burned.
>>
>> Alex
>>
>> > ron
>> >
>> > On Sun, Jan 10, 2016 at 3:28 AM Rafael Machado
>> > > > > wrote:
>> >
>> > Hi Peter and Rudolf.
>> > Thanks for the answers and tips. They are realy helpfull !
>> > I'll take a look.
>> >
>> > Rafael R. Machado
>> >
>> >
>> > Em Sáb, 9 de jan de 2016 17:19, Rudolf Marek > > > escreveu:
>> >
>> > Hi,
>> >
>> > I guess your question is more general than the coreboot related
>> > right?
>> >
>> > If you have a firmware image dump of the flash (not the file you
>> > download from
>> > board vendor) then yes, first location to be executed is the
>> > instruction located
>> > 16 bytes before end of the image.
>> >
>> > In coreboot see in build/ bootblock_inc.S which also has
>> > reset16.inc and
>> > entry16.inc which is a real start. Consult the Intel or AMD
>> > manual to see the
>> > CPU state after reset. The CPU starts in real mode, but CS base
>> > is shifted to
>> > last 64KB before end of 4GB address space. In general your CPU
>> > starts in
>> > compatible mode with 8086 manufactured in 1978.
>> >
>> > Thanks
>> > Rudolf
>> >
>> > --
>> > coreboot mailing list: coreboot@coreboot.org
>> > 
>> > http://www.coreboot.org/mailman/listinfo/coreboot
>> >
>> >
>> >
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
>>
>

Re: [coreboot] Where is the first instrucion?

[Rafael Machado]

Hi guys. Long time since my last e-mail.

It's hard to synchronize my day work with my firmware studies. Since my
projects are more UEFI related I usually do not have to much time to study
the legacy way, but It's really cool and Ill not give up :)

Since the last talk I was doing what everyone kindly proposed. (by the way
thank you all for the guidance.)

Now I'm disassembly an old systems bios I have, but I cannot understand
what is happening in a specific section of the code. (I'm using radare2 for
my studies)

The code is:

f000:0fcb 66b9ff02mov ecx, 0x2ff
f000:0fd1 0f32 rdmsr ; read register 0x2ff
(IA32_MTRR_DEF_TYPE)
f000:0fd3 0fbae80b  bts ax, 0xb ; Enable bit 11 (MTRR
Enable).
f000:0fd7 0fbae80a  bts ax, 0xa ; Enable bit 10 (Fixed MTRR
Enable).
f000:0fdb 0f30 wrmsr; Write changes to MTRR
f000:0fdd 0f20c0 mov eax, cr0
f000:0fe0 660fbaf01e   btr eax, 0x1e   ; Bit 30 means CD - Cache
disabled.
f000:0fe5 660fbaf01d   btr eax, 0x1d   ; Disable bit 29. NW - No
Write-through
f000:0fea 0f22c0 mov cr0, eax   ; Write changes to CR0
f000:0fed ffe7  jmp di
f000:0fef 0f20c0  mov eax, cr0
f000:0ff2 660fbae81e   bts eax, 0x1e
f000:0ff7 660fbae81d   bts eax, 0x1d
f000:0ffc 0f22c0  mov cr0, eax


Here is the code with my notes. I understand that some MTRR were set, and
now the processor will be "configured".
We see at address f000:0fe0 and f000:0fe5 that the CR0 register is being
changed and after that the changes are saved.

Now I have two questions.

1 - After CR0 changes get completed there is a "jmp di" instruction. This
does not make any sense to me. Does anyone know why this is needed ? As far
as I could check di value is 0x0 at this point. I think

2 - After the "jmp di" a "CR0 Déjà vu" code is executed. Any idea why this
is needed ?

Thanks everyone
Rafael R. Machado


Em seg, 11 de jan de 2016 às 03:57, Alex G.  escreveu:

> On 01/10/2016 10:23 AM, ron minnich wrote:
> > One thing I think you'd enjoy doing is building the qemu target, setting
> > up qemu with gdb, and just watching what happens, instruction by
> > instruction, as the system boots.
>
> One exercise I liked doing was to rewrite the entire boot flow, from
> reset vector to protected mode entry. Tested on qemu, put it on
> hardware, nothing burned.
>
> Alex
>
> > ron
> >
> > On Sun, Jan 10, 2016 at 3:28 AM Rafael Machado
> >  > > wrote:
> >
> > Hi Peter and Rudolf.
> > Thanks for the answers and tips. They are realy helpfull !
> > I'll take a look.
> >
> > Rafael R. Machado
> >
> >
> > Em Sáb, 9 de jan de 2016 17:19, Rudolf Marek  > > escreveu:
> >
> > Hi,
> >
> > I guess your question is more general than the coreboot related
> > right?
> >
> > If you have a firmware image dump of the flash (not the file you
> > download from
> > board vendor) then yes, first location to be executed is the
> > instruction located
> > 16 bytes before end of the image.
> >
> > In coreboot see in build/ bootblock_inc.S which also has
> > reset16.inc and
> > entry16.inc which is a real start. Consult the Intel or AMD
> > manual to see the
> > CPU state after reset. The CPU starts in real mode, but CS base
> > is shifted to
> > last 64KB before end of 4GB address space. In general your CPU
> > starts in
> > compatible mode with 8086 manufactured in 1978.
> >
> > Thanks
> > Rudolf
> >
> > --
> > coreboot mailing list: coreboot@coreboot.org
> > 
> > http://www.coreboot.org/mailman/listinfo/coreboot
> >
> >
> >
>
> --
> coreboot mailing list: coreboot@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] New on blogs.coreboot.org: [GSoC] Multiple status registers, block protection and OTP support, week #6, 7, 8 and 9

[WordPress]

A new post titled "[GSoC] Multiple status registers, block protection and OTP support, week #6, 7, 8 and 9" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/07/24/gsoc-multiple-status-registers-block-protection-and-otp-support-week-6-7-8-and-9/

Hello! I have been away for some time now, so this is going to be a longer post. I hope you have missed hearing from me  In this post I will talk about my work in the weeks post-midterm evaluations. After a discussion with my mentors in the midterm evaluations week, we decided to shift focus towards the first three phases of my GSoC proposal for the remainder of the duration. Work on the final phase will be done after GSoC along with the more long-term goals that have come up as I have been making progress.
I submitted patches (finally ;)) to the mailing list. The set of patches adds multiple status register, and block protection infrastructure. I have also added a command-line interface to expose the new functionality. Although I am not sure that the exact wording of the CLI is most optimum, but I did not spend a lot of time on that because IMO it is a rather subjective issue and altering it is not a difficult task. The set of patches also adds support for new infrastructure to around 90 existing chips. I am still waiting to receive feedback and review on them. (My mentors had been slightly busier then.) I am also investigating adding support for access protection to non-SPI chips. This isn’t on the highest priority (more like a long-term goal), but once the SPI infrastructure gets merged, I will begin writing code for that.
Based on the initial prototypes I built (here, here and here), we had decided to use pointers to new structs instead of fully embedding them in struct flashchip. This decision really started to show when I was adding support for existing chips – with only 25 unique struct definitions we were able to support those 90 chips!  One of the problems I faced was that I needed to test the new infrastructure, but doing so on a physical chip would be cumbersome. So that problem was solved by adding a dummy chip to use with flashrom’s dummy programmer. (At that time the code was the dummy chip was messy and something I would be ashamed to put up publicly, but now I have improved upon it! :P)
Currently I am working on finalising the OTP/security register(s) patches – more specifically, adding support to existing chips, code cleanup and documentation. I will be able to send them to the mailing list in a few days. In my research on Eon, GigaDevice and Winbond chips, 2 distinct models for OTP were observed – the GigaDevice and Winbond model with security register(s), and the Eon model with a security sector.
The Security Register(s) model has 3 separate opcodes for read, program and erase – 0x48, 0x42 and 0x44 respectively. A chips can have multiple security registers (most commonly 3, but as high as 4) with each register being anywhere between 128 bytes to 1024 bytes in size (most commonly 512 bytes and then 256 bytes). Usually chips have a lock bit (LB1, LB2, …) in the status register that correspond to respective security registers. These one-time programmable bits are changed using the standard WRSR instruction. Some chips have a single lock bit that controls OTP status for all security registers.
The Security Sector model has a separate sector which can be operated in the OTP mode. OTP mode is entered with opcode 0x3A and exited by sending WRDI (0x04) instruction. While in the OTP mode, the sector behaves just like any other sector – normal read, program and erase instructions apply. The SRP/SRWD bit is served as OTP bit while in OTP mode. Issuing the WRSR command (irrespective of the data sent along with it) will cause the one-time programmable OTP bit to be set.
One of the recurrent issues (for the lack of a better word, I don’t think of it to be an issue really ;)) is that many chips I have based my research on, are not originally supported by flashrom (perhaps unfortunate siblings of the same family that didn’t find support in flashrom earlier xD). I don’t call it an issue per se because after I have submitted my patches flashrom will end up supporting even more chips, but since I have to write more code it might take slightly longer to submit the patches.
There is a third model which is dominantly followed by Spansion chips and a couple of AMIC chips (some AMIC chips follow one of the earlier models – it’s like AMIC couldn’t decide which one to stick to or they probably had different teams working on it! :P). Similar to the security sector design, these chips also have a separate OTP sector but instead of storing configuration in the register, a byte within the sector is allocated for storing the configuration data. I have planned to support this model in the next revision of patches, after the upcoming ones get reviewed and merged.
Thanks for your time, it was nice to get back in touch with you! 

Re: [coreboot] Bayou design question

[Marc Jones]

That approach sounds correct to me and should be a fun little project.

And for historical reference: http://bayoubobs.com/contact/

Marc



On Mon, Jul 25, 2016 at 3:39 AM Antonello Dettori  wrote:

> Hello, I'm currently taking a look at modifying the bayou payload in order
> to make it work on a modern coreboot system.
> The conversion seems pretty straightforward except for a few points that
> I'm unsure about since I don't know what the situation was during the
> coreboot-v3/LAR era or what was the payload's design process like.
>
>
> 1) Bayou is currently designed this way:
>
>- Take user-written xml configuration
>- Use pbuilder utility to parse the config
>- pbuilder then generates a single blob containing every payload
>specified (it also performs elf->self conversions, adds the payloads to the
>blob, etc.)
>- Bayou (when executed) takes a compressed blob
>- Reads the configuration from it
>- Parses through the blob looking for each payload specified
>- Follows the rest of the configuration
>
> This design choice seems a bit inappropriate given that we are nowadays
> used to store multiple secondary payloads directly inside the cbfs (with
> the re-introduction of bayou "secondary payloads" could also be expanded to
> contain all the payloads).
>
> I'm instead thinking of doing the following changes:
>
>- Doing away with the blob
>- Storing the configuration inside the cbfs as a cbfs_file
>- Parse the configuration directly from the cbfs
>- Use cbfstool to handle all addition/removal of payloads to the cbfs
>- Eliminate pbuilder
>
> This seems to be a much cleaner solution than the current one.
> I currently don't see any downsides to it but I would like to hear other
> opinions on the matter.
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot

-- 
http://marcjonesconsulting.com
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] kexec of Xen hypervisor from a Linux payload

[Zoran Stojsavljevic]

Hello Trammell,

Reading what you are trying. Have no idea what Qubes OS is... I apologize
for my ignorance, but I am (fortunately) willing to learn. New OSes, new
tricks, and this old dog (me) is still willing to learn new tricks (in
other words, also learning experience for me)?! ;-)

So, since you are coming to dracut after all, I am suspecting that
something with your initramfs is not quite right... It often happens to me
with Linux distros I am using for HW/SoC testing (95% Fedora distro).

In order to determine what is really wrong with your setup, I asked my best
friend for dozens of years: www.google.com, searching for pattern ->
*initramfs*-4.1.13-9.pvops.qubes.x86_64.img


The following appeared:
https://groups.google.com/forum/#!msg/qubes-users/DYw6f2LpDA8/z4fDsy9CBwAJ

*And this cot my eye (from Marek Marczykowski-Górecki):*






*Probably some module required for your baremetal fedora is missing
in initramfs. First of all, remove "quiet" option to receive more
details. If that's about missing module, you can regenerate initramfs: 0.
Make sure you've copied modules from
Qubes (/lib/modules/4.1.13-9.pvops.qubes.x86_64) 1. Call "dracut -f
/initramfs-4.1.13-9.pvops.qubes.x86_64.img 4.1.13-9.pvops.qubes.x86_64 *

Could help (you might search other options with the provided search
pattern) ... :-)

Please, let us know.

Zoran

On Mon, Jul 25, 2016 at 6:05 AM, Trammell Hudson  wrote:

> I've successfully built a 4.6.4 Linux kernel payload for CoreBoot and
> flashed it onto the top 4 MB of the boot ROM on my Thinkpad x230.
> The runtime is a dynamic linked busybox with glibc, as well as a copy
> of the kexec binary from my Ubuntu laptop.
>
> kexec of a xen kernel (multiboot-x86) results in an immediate reboot
> into the coreboot payload:
>
> https://www.flickr.com/photos/osr/27913702804/lightbox
>
> kexec of a Linux kernel produces the expected result (panic in this
> case since I didn't pass any additional parameters to find a root fs):
>
> https://www.flickr.com/photos/osr/27914585663/lightbox
>
> This might be a xen problem (triple fault leading to reset vector?)
> rather than a coreboot issue, however the same Xen hypervisor config
> works with grub2 on the drive loaded by seabios payload.
>
> There is this old document that describes a "--vmm" option to kexec,
> but that doesn't seem to exist in the current kexec tree:
>
> https://xenbits.xen.org/docs/4.3-testing/misc/kexec_and_kdump.txt
>
> --
> Trammell
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] w83627 uart port is not workable with coreboot in linux

[Nico Huber]

Hi Cheng,

On 25.07.2016 04:33, cheng yichen wrote:
> Hi all
> 
> After i follow kontron/ktqm77 setting. I can't solve the issue.
> I try to change iqr(for com1) to 5 or 6. but system can't print linux
> message and minicom is not workable.

Can you confirm that you see the full coreboot log on your UART? With
log level >= debug, it should end with lines about loading the payload,
containing a line starting with "Jumping to boot code at".

If you see this line, it's unlikely to be a coreboot issue. If not,
please provide a full log with highest log level. Also the output of
`lspci -xxx`, `cbmem -c` and your devicetree.cb might be helpful.

Another way to test the UART is to use Linux' earlycon driver, e.g. with
earlycon=uart8250,io,0x3f8,115200n8 in your kernel command line. This
driver is simpler than the serial8250 (it doesn't use interrupts and is
closer to what coreboot's driver does).

Nico

> 
> 
> 
> dump from superiotool
> Found Winbond W83627DHG-P/-PT (id=0xb0, rev=0x73) at 0x2e
> Register dump:
> idx 02 20 21 22 23 24 25 26  27 28 29 2a 2b 2c 2d 2e  2f
> val ff b0 73 ff 00 42 00 00  ff 50 80 00 00 eb 21 00  ff
> def 00 b0 NA ff 00 MM 00 MM  RR 50 00 00 RR e2 21 00  00
> LDN 0x00 (Floppy)
> idx 30 60 61 70 74 f0 f1 f2  f4 f5
> val 01 03 f0 06 02 8e 00 ff  00 00
> def 01 03 f0 06 02 8e 00 ff  00 00
> LDN 0x01 (Parallel port)
> idx 30 60 61 70 74 f0
> val 01 03 78 07 04 3f
> def 01 03 78 07 04 3f
> LDN 0x02 (COM1)
> idx 30 60 61 70 f0
> val 01 03 f8 04 40
> def 01 03 f8 04 00
> LDN 0x03 (COM2)
> idx 30 60 61 70 f0 f1
> val 01 02 f8 03 40 00
> def 01 02 f8 03 00 00
> LDN 0x05 (Keyboard)
> 
> 
> dump from dmesg
> 
> home# dmesg | grep -i tty
> [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.2.0-16-generic
> root=UUID=b2b7f7fa-b1db-4e97-941f-8aaee291f3dc ro console=tty1
> console=ttyS0,115200n8 quiet splash vt.handoff=7
> [0.00] Kernel command line:
> BOOT_IMAGE=/boot/vmlinuz-4.2.0-16-generic
> root=UUID=b2b7f7fa-b1db-4e97-941f-8aaee291f3dc ro console=tty1
> console=ttyS0,115200n8 quiet splash vt.handoff=7
> [0.00] console [tty1] enabled
> [0.00] console [ttyS0] enabled
> [1.637664] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a
> 16550A
> [1.658835] serial8250: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200)
> is a 16550A
> [3.412478] fbcon: Remapping primary device, fb1, to tty 1-63
> [   44.378835] systemd[1]: Created slice system-serial\x2dgetty.slice.
> [   44.380198] systemd[1]: Created slice system-getty.slice.
> 
> 
> 
> 
> 
> 2016-07-22 20:24 GMT+08:00 Kyösti Mälkki :
> 
>> On Fri, Jul 22, 2016 at 1:14 PM, cheng yichen 
>> wrote:
>>> Hi all
>>>
>>> My platform is braswell SOC with W83627dhg superIO. In post stage I can
>> get
>>> debug message over w83627 uart1(3f8/irq4). but after boot to linux, uart
>>> port is not woarkable. I test the function by minicom but I can't receive
>>> and send data. I can get uart information by dmesg command.
>>> How to initial it in corebooot?
>>
>> Does not sound like a coreboot issue to me.
>>
>> Do you have CTS/RTS hardware handshake disabled in minicom
>> configuration? If you directed kernel console to serial port, you
>> should not (cannot) use the port for user apps.
>>
>> HTH,
>> Kyösti
>>
> 
> 
> 

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Bayou design question

[Antonello Dettori]

Hello, I'm currently taking a look at modifying the bayou payload in 
order to make it work on a modern coreboot system.
The conversion seems pretty straightforward except for a few points that 
I'm unsure about since I don't know what the situation was during the 
coreboot-v3/LAR era or what was the payload's design process like.



1) Bayou is currently designed this way:

 * Take user-written xml configuration
 * Use pbuilder utility to parse the config
 * pbuilder then generates a single blob containing every payload
   specified (it also performs elf->self conversions, adds the payloads
   to the blob, etc.)
 * Bayou (when executed) takes a compressed blob
 * Reads the configuration from it
 * Parses through the blob looking for each payload specified
 * Follows the rest of the configuration

This design choice seems a bit inappropriate given that we are nowadays 
used to store multiple secondary payloads directly inside the cbfs (with 
the re-introduction of bayou "secondary payloads" could also be expanded 
to contain all the payloads).


I'm instead thinking of doing the following changes:

 * Doing away with the blob
 * Storing the configuration inside the cbfs as a cbfs_file
 * Parse the configuration directly from the cbfs
 * Use cbfstool to handle all addition/removal of payloads to the cbfs
 * Eliminate pbuilder

This seems to be a much cleaner solution than the current one.
I currently don't see any downsides to it but I would like to hear other 
opinions on the matter.


-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] w83627 uart port is not workable with coreboot in linux

[cheng yichen]

Hi Zoran

TTYS1 is also not workable. I also change io resource from 3f8 to 3e8  irq
from 4 to 5. but result is the same.

Thank you

2016-07-25 13:57 GMT+08:00 Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com>:

> Hello Chen,
>
> I see. Also learning, reading and trying to get to the root of the problem.
>
> > [1.637664] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200)
> is a 16550A
> > [1.658835] serial8250: ttyS1 at I/O 0x2f8 (irq = 3, base_baud =
> 115200) is a 16550A
>
> Please, try to experiment with ttyS1. But I guess, you already know what I
> just wrote. Maybe this also can help:
> http://forums.debian.net/viewtopic.php?f=7=111355
>
> Zoran
>
> On Mon, Jul 25, 2016 at 7:08 AM, cheng yichen 
> wrote:
>
>> Hi Zoran
>>
>> The ttyS0 is superIo uart. Because I add uart asl code in coreboot system
>> will show "00:05: ttyS0"
>> If I remove asl code system will show "serial8250:ttty"Thank you
>>
>> 2016-07-25 12:10 GMT+08:00 Zoran Stojsavljevic <
>> zoran.stojsavlje...@gmail.com>:
>>
>>> > home# dmesg | grep -i tty
>>> > [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.2.0-16-generic
>>> root=UUID=b2b7f7fa-b1db-4e97-
>>> > 941f-8aaee291f3dc ro console=tty1 console=ttyS0,115200n8 quiet splash
>>> vt.handoff=7
>>> > [0.00] Kernel command line: 
>>> > BOOT_IMAGE=/boot/vmlinuz-4.2.0-16-generic
>>> root=UUID=b2b7f7fa-b1db-
>>> > 4e97-941f-8aaee291f3dc ro console=tty1 console=ttyS0,115200n8 quiet
>>> splash vt.handoff=7
>>> > [0.00] console [tty1] enabled
>>> > [0.00] console [ttyS0] enabled
>>> > [1.637664] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud =
>>> 115200) is a 16550A
>>> > [1.658835] serial8250: ttyS1 at I/O 0x2f8 (irq = 3, base_baud =
>>> 115200) is a 16550A
>>> > [3.412478] fbcon: Remapping primary device, fb1, to tty 1-63
>>> > [   44.378835] systemd[1]: Created slice system-serial\x2dgetty.slice.
>>> > [   44.380198] systemd[1]: Created slice system-getty.slice.
>>> ___
>>>
>>> Hello Cheng,
>>>
>>> Please, try to do the following: lspci -vv (to find your serial on
>>> PCIe), then try to remap your IRQs, to see if this will somehow work.
>>>
>>> Example:
>>> setserial /dev/ttyS0 port 0xd800 UART 16550A irq 5
>>> setserial /dev/ttyS0 -av
>>> /dev/ttyS0, Line 0, UART: 16550A, Port: 0xd800, IRQ: 5
>>> Baud_base: 115200, close_delay: 5000, divisor: 0
>>> closing_wait: 37856
>>> Flags: spd_normal skip_test
>>>
>>> Something like described on this web pointer:
>>> https://forums.gentoo.org/viewtopic-t-249041-start-0.html
>>>
>>> Please, report your attempts/results here.
>>>
>>> Thank you,
>>> Zoran
>>>
>>> On Mon, Jul 25, 2016 at 4:33 AM, cheng yichen 
>>> wrote:
>>>
 Hi all

 After i follow kontron/ktqm77 setting. I can't solve the issue.
 I try to change iqr(for com1) to 5 or 6. but system can't print linux
 message and minicom is not workable.



 dump from superiotool
 Found Winbond W83627DHG-P/-PT (id=0xb0, rev=0x73) at 0x2e
 Register dump:
 idx 02 20 21 22 23 24 25 26  27 28 29 2a 2b 2c 2d 2e  2f
 val ff b0 73 ff 00 42 00 00  ff 50 80 00 00 eb 21 00  ff
 def 00 b0 NA ff 00 MM 00 MM  RR 50 00 00 RR e2 21 00  00
 LDN 0x00 (Floppy)
 idx 30 60 61 70 74 f0 f1 f2  f4 f5
 val 01 03 f0 06 02 8e 00 ff  00 00
 def 01 03 f0 06 02 8e 00 ff  00 00
 LDN 0x01 (Parallel port)
 idx 30 60 61 70 74 f0
 val 01 03 78 07 04 3f
 def 01 03 78 07 04 3f
 LDN 0x02 (COM1)
 idx 30 60 61 70 f0
 val 01 03 f8 04 40
 def 01 03 f8 04 00
 LDN 0x03 (COM2)
 idx 30 60 61 70 f0 f1
 val 01 02 f8 03 40 00
 def 01 02 f8 03 00 00
 LDN 0x05 (Keyboard)


 dump from dmesg

 home# dmesg | grep -i tty
 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.2.0-16-generic
 root=UUID=b2b7f7fa-b1db-4e97-941f-8aaee291f3dc ro console=tty1
 console=ttyS0,115200n8 quiet splash vt.handoff=7
 [0.00] Kernel command line:
 BOOT_IMAGE=/boot/vmlinuz-4.2.0-16-generic
 root=UUID=b2b7f7fa-b1db-4e97-941f-8aaee291f3dc ro console=tty1
 console=ttyS0,115200n8 quiet splash vt.handoff=7
 [0.00] console [tty1] enabled
 [0.00] console [ttyS0] enabled
 [1.637664] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200)
 is a 16550A
 [1.658835] serial8250: ttyS1 at I/O 0x2f8 (irq = 3, base_baud =
 115200) is a 16550A
 [3.412478] fbcon: Remapping primary device, fb1, to tty 1-63
 [   44.378835] systemd[1]: Created slice system-serial\x2dgetty.slice.
 [   44.380198] systemd[1]: Created slice system-getty.slice.





 2016-07-22 20:24 GMT+08:00 Kyösti Mälkki :

> On Fri, Jul 22, 2016 at 1:14 PM, cheng yichen 
> wrote:
> > Hi all
> >
> > My platform is braswell SOC with W83627dhg superIO. In post