Keith Emery | 30 Aug 22:43 2015
Picon

Openbiosprog-spi

G,day all

I just made an order on PCB cart for the OpenBiosprog_spi.
As a result of mild brain damage on my part; I went ahead and ordered 200 boards.

So in light of the above I am happy to mail out as many boards as anyone might want for the low low price of $1.20 AUD plus postage.  Spread the word!

http://keithtronics.tictail.com/
--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
John Lewis | 30 Aug 20:43 2015
Picon

Acer Chromebook 15 debug

Hi Guys,

Coolstar Organisation wants to do his Windows thang with one of the 
Broadwell Chromebooks, so I'm trying to build a working ROM with 
chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmware-yuna-6301.59.B 
to give him a hand. Luckily USB debug works with this, so here is what 
I'm getting. What could I do next?

Incidentally, if I flash back my backup, it goes into recovery mode now 
every time I boot (flags are 0x489), I've tried pulling the battery to 
no avail. If anyone has a trick to get around that, I'd appreciate it, 
as the Acer is my main machine.

-⁠John.

coreboot-⁠5cbe3a8-⁠dirty romstage Sun Aug 23 12:18:55 BST 2015 
starting...

PM1_STS:   8910

PM1_EN:    0000

PM1_CNT:   00000000

TCO_STS:   0000 0000

GPE0_STS:  1ef82df0 187d4fdf 0005f240 00000000

GPE0_EN:   00000000 00000000 00000000 00000000

GEN_PMCON: 0200 2024 520b

Previous Sleep State: S5

CPU: Intel(R) Core(TM) i3-⁠5005U CPU  <at>  2.00GHz

CPU: ID 306d4, Broadwell E0 or F0, ucode: 0000001d

CPU: AES supported, TXT NOT supported, VT supported

MCH: device id 1604 (rev 09) is Broadwell F0

PCH: device id 9cc5 (rev 03) is Broadwell U Base

IGD: device id 1616 (rev 09) is Broadwell U GT2

CPU: frequency set to 2000 MHz

SPD: index 1 (GPIO47=0 GPIO9=0 GPIO13=1)

SPD: module type is DDR3

SPD: module part is HMT425S6AFR6A-⁠PB

SPD: banks 8, ranks 1, rows 15, columns 10, density 4096 Mb

SPD: device width 16 bits, bus width 64 bits

SPD: module size is 2048 MB (per channel)

Boot Count incremented to 8

ME: FW Partition Table      : OK

ME: Bringup Loader Failure  : NO

ME: Firmware Init Complete  : NO

ME: Manufacturing Mode      : NO

ME: Boot Options Present    : NO

ME: Update In Progress      : NO

ME: Current Working State   : Normal

ME: Current Operation State : Bring up

ME: Current Operation Mode  : Normal

ME: Error Code              : No Error

ME: Progress Phase          : BUP Phase

ME: Power Management Event  : Pseudo-⁠global reset

ME: Progress Phase State    : Waiting for DID BIOS message

ME: HSIO Version            : 8705 (CRC 0xfbc2)

No FMAP found at ffe10000.

FMAP: area RW_MRC_CACHE not found

No MRC cache found.

Starting Memory Reference Code

Initializing Policy

Installing common PPI

MRC: Starting...

Initializing Memory

MRC: Done.

MRC Version 2.6.0 Build 0

memcfg DDR3 clock 1600 MHz

memcfg channel assignment: A: 0, B  1, C  2

memcfg channel[0] config (00780008):

    enhanced interleave mode on

    rank interleave on

    DIMMA 2048 MB width x16 single rank, selected

    DIMMB 0 MB width x16 single rank

memcfg channel[1] config (00780008):

    enhanced interleave mode on

    rank interleave on

    DIMMA 2048 MB width x16 single rank, selected

    DIMMB 0 MB width x16 single rank

CBMEM: root  <at>  7cfff000 254 entries.

MRC data at ff7d0d9c 6246 bytes

Relocate MRC DATA from ff7d0d9c to 7cfeb000 (6246 bytes)

create cbmem for dimm information

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
蝈蝈 | 30 Aug 08:11 2015

sincerely consult about Gerrit plugin

Dear Mr/Ms,

    I am very excited to read the slide "Gerrit: how to cook a plugin in only 10 mins". Now I have a problem about how to build a gerrit plugin to display all the projects' name. Could you help me?

    Firstly, I built the gerrit platform and achieved the servertime gerrit plugin (the example in the slide). In the attachment, you can find the achievement of this step (servertime.png). 

    Secondly, I followed the flow of the servertime gerrit plugin, I build a new java file (ProjectList.java), and I want to get the list of all the projects' name in the Gerrit through this projectlist gerrit plugin. In the attachment,I just write the head of class ProjectList (projectlist.png), I don't know whether it is right. Could you tell me how to write the class ProjectList to get all the projects' name?
 
I am looking forward to hearing from you.
 

Best Wishes,
Zhaoguo Liu
National Key Laboratory of Cognitive Neuroscience and Learning
No. 19, XinJieKouWai St., HaiDian District, 
Beijing 100875, P. R. China


夏日畅销榜大牌美妆只要1元



夏日畅销榜大牌美妆只要1元



夏日畅销榜大牌美妆只要1元

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
蝈蝈 | 30 Aug 07:49 2015

sincerely consult about Gerrit plugin

Dear Mr/Ms,

    I am very excited to read the slide "Gerrit: how to cook a plugin in only 10 mins". Now I have a problem about how to build a gerrit plugin to display all the projects' name. Could you help me?

    Firstly, I built the gerrit platform and achieved the servertime gerrit plugin (the example in the slide). In the attachment, you can find the achievement of this step (servertime.png). 

    Secondly, I followed the flow of the servertime gerrit plugin, I build a new java file (ProjectList.java), and I want to get the list of all the projects' name in the Gerrit through this projectlist gerrit plugin. In the attachment,I just write the head of class ProjectList (projectlist.png), I don't know whether it is right. Could you tell me how to write the class ProjectList to get all the projects' name?
 
I am looking forward to hearing from you.
 

Best Wishes,
Zhaoguo Liu
National Key Laboratory of Cognitive Neuroscience and Learning
No. 19, XinJieKouWai St., HaiDian District, 
Beijing 100875, P. R. China


夏日畅销榜大牌美妆只要1元



夏日畅销榜大牌美妆只要1元



夏日畅销榜大牌美妆只要1元

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
John Lewis | 29 Aug 22:20 2015
Picon

Acer Chromebook 15 debug

Hi Guys,

Coolstar Organisation wants to do his Windows thang with one of the 
Broadwell Chromebooks, so I'm trying to build a working ROM with

https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmware-yuna-6301.59.B 
to give him a hand. Luckily USB debug works with this, so here is what 
I'm getting. What could I do next?

-John.

coreboot-5cbe3a8-dirty romstage Sun Aug 23 12:18:55 BST 2015 starting...

PM1_STS:   8910

PM1_EN:    0000

PM1_CNT:   00000000

TCO_STS:   0000 0000

GPE0_STS:  1ef82df0 187d4fdf 0005f240 00000000

GPE0_EN:   00000000 00000000 00000000 00000000

GEN_PMCON: 0200 2024 520b

Previous Sleep State: S5

CPU: Intel(R) Core(TM) i3-5005U CPU  <at>  2.00GHz

CPU: ID 306d4, Broadwell E0 or F0, ucode: 0000001d

CPU: AES supported, TXT NOT supported, VT supported

MCH: device id 1604 (rev 09) is Broadwell F0

PCH: device id 9cc5 (rev 03) is Broadwell U Base

IGD: device id 1616 (rev 09) is Broadwell U GT2

CPU: frequency set to 2000 MHz

SPD: index 1 (GPIO47=0 GPIO9=0 GPIO13=1)

SPD: module type is DDR3

SPD: module part is HMT425S6AFR6A-PB

SPD: banks 8, ranks 1, rows 15, columns 10, density 4096 Mb

SPD: device width 16 bits, bus width 64 bits

SPD: module size is 2048 MB (per channel)

Boot Count incremented to 8

ME: FW Partition Table      : OK

ME: Bringup Loader Failure  : NO

ME: Firmware Init Complete  : NO

ME: Manufacturing Mode      : NO

ME: Boot Options Present    : NO

ME: Update In Progress      : NO

ME: Current Working State   : Normal

ME: Current Operation State : Bring up

ME: Current Operation Mode  : Normal

ME: Error Code              : No Error

ME: Progress Phase          : BUP Phase

ME: Power Management Event  : Pseudo-global reset

ME: Progress Phase State    : Waiting for DID BIOS message

ME: HSIO Version            : 8705 (CRC 0xfbc2)

No FMAP found at ffe10000.

FMAP: area RW_MRC_CACHE not found

No MRC cache found.

Starting Memory Reference Code

Initializing Policy

Installing common PPI

MRC: Starting...

Initializing Memory

MRC: Done.

MRC Version 2.6.0 Build 0

memcfg DDR3 clock 1600 MHz

memcfg channel assignment: A: 0, B  1, C  2

memcfg channel[0] config (00780008):

    enhanced interleave mode on

    rank interleave on

    DIMMA 2048 MB width x16 single rank, selected

    DIMMB 0 MB width x16 single rank

memcfg channel[1] config (00780008):

    enhanced interleave mode on

    rank interleave on

    DIMMA 2048 MB width x16 single rank, selected

    DIMMB 0 MB width x16 single rank

CBMEM: root  <at>  7cfff000 254 entries.

MRC data at ff7d0d9c 6246 bytes

Relocate MRC DATA from ff7d0d9c to 7cfeb000 (6246 bytes)

create cbmem for dimm information

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

WordPress | 29 Aug 12:25 2015

New on blogs.coreboot.org: coreboot changelog – Weeks of 2015-08-10 and 2015-08-17

A new post titled "coreboot changelog – Weeks of 2015-08-10 and 2015-08-17" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/08/29/coreboot-changelog-weeks-of-2015-08-10-and-2015-08-17/

this report covers commits 1cbef1c to 410f9ad

The vast majority of changes in these two weeks were upstreamed from Chrome OS and cover work on the Intel Skylake chipset and two mainboards based on it.

QEmu and Getac P470 saw a couple of improvements.
On AMD, there were some bugfixes to Fam10h concerning VGA memory and SMM initialization. The latter was in response to the Memory Sinkhole vulnerability, although it is as yet unclear if it even affects AMD.
Finally, an important memory structure used on pre-AGESA AMD code is now also usable outside Cache-as-RAM.
There was more progress on fixing 64bit issues across the codebase.

Our reference compiler was updated to gcc 5.2. This became necessary to support an update to the RISC-V specification.

Our other tools also saw a couple of improvements: ifdtool now works for descriptors on Skylake and newer platforms. cbfstool saw some refactorings that allow us to extend the format. cbmem now emits the accumulated boot time.

In our configuration system, the Kconfig definitions were cleaned up, so that boards don’t define symbols that their code never uses, that Chrome OS capable boards define “MAINBOARD_HAS_CHROMEOS” (which defines the capability) instead of “CHROMEOS” (which defines that this mode should be
used) and that dependencies between Kconfig options become more consistent.
There is a pending commit on gerrit to enforce clean dependencies by making errors out of kconfig’s warnings, that the latter changes prepare for.

On the build system side, it is now possible to build SeaBIOS as part of our build system even with an enabled ccache. The payload config and revision can also be stored in CBFS for better reproducibility. Finally, it’s possible to override the location from where the vboot source code for Chrome OS-style verified boot is taken from.

In libpayload, the non-accelerated memmove implementation now also works with size == 0 (instead of trying to move 4GB), and there were a couple of bug fixes to the DWC2 (some ARM) and XHCI (USB3) controller drivers, including support for the newer XHCI 1.1 specification.

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Gregg Levine | 29 Aug 03:51 2015
Picon

coreboot as a system startup device

Hello!
Is Google using coreboot as a method to start and manage its systems?
Especially since the open source gang at Facebook of all places is
realizing that the bottleneck towards getting their systems to run
capably happens to be its low level firmware.

Of course the chap at the NYLUG meeting for Wednesday 8/26 all but
admitted that they were using Intel based servers back there, so I did
not mention what goes on here.

The presentation should be up on the NYLUG Youtube channel in a matter of weeks.
-----
Gregg C Levine gregg.drwho8 <at> gmail.com
"This signature fought the Time Wars, time and again."

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

WordPress | 26 Aug 00:45 2015

New on blogs.coreboot.org: [GSoC] coreboot for ARM64 Qemu – Week #9 #10

A new post titled "[GSoC] coreboot for ARM64 Qemu – Week #9 #10" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/08/25/gsoc-coreboot-for-arm64-qemu-week-9-10/

In the last post I talked about using aarch64-linux-gnu-gdb and debugging in qemu. In these two weeks I was intensely involved in stepping through gdb, disassembly and in-turn debugging the qemu port. I summarise the major highlights below.

Firstly, the correct instruction to invoke qemu is as follows

./aarch64-softmmu/qemu-system-aarch64 -machine virt -cpu cortex-a57 -machine type=virt -nographic -smp 1 -m 2048 -bios ~/coreboot/build coreboot.rom -s -S

After invoking gdb, I moved onto tracing the execution of the instructions step by step to determine where and how the code fails. A compendium of the code execution is as follows

gdb) target remote :1234
Remote debugging using :1234
(gdb) set disassemble-next-line on
(gdb) stepi
0x0000000000000980 in ?? ()
=> 0x0000000000000980: 02 00 00 14 b 0x988
(gdb)
0x0000000000000988 in ?? ()
=> 0x0000000000000988: 1a 00 80 d2 mov x26, #0x0                    // #0
(gdb)
0x000000000000098c in ?? ()
=> 0x000000000000098c: 02 00 00 14 b 0x994
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x0000000000000750 in ?? ()
=> 0x0000000000000750: 3f 08 00 71 cmp w1, #0x2

The detailed version can be seen here.

The first sign of error can be seen here, where the instruction is 0 and the address is way off.

0x64672d3337303031 in ?? () => 0x64672d3337303031: 00 00 00 00 .inst 0x00000000 ; undefined

To find insights as to why this is happening, I resorted to tracing in gdb. This can be done by adding the following in the qemu invoke command. This creates a log file in /tmp which can be read to determine suitable information.

-d out_asm,in_asm,exec,cpu,int,guest_errors -D /tmp/qemu.log

Looking at the disassembly, it can be seen that execution of instructions till 0x784 is correct and it goes bonkers immediately after it. Looking at the trace, this is where the code hangs

IN:
0x0000000000000784:  d65f03c0      ret
The ret goes to somewhere bad. So the stack has been blown or it has executed into an area it should have prior to this. Next, I did a objdump on the bootblock.debug file. Relating to the code at this address, it could be determined that the code fails at “ret in 0000000000010758 <raw_write_sctlr>:”
Next up was determining where the stack gets blown or corrupt. For this, while stepping through each instruction, I looked at the stack pointer. The output here shows the details. Everything seems to function correctly till 0x00000000000007a0 (0x00000000000007a0: f3 7b 40 a9 ldp x19, x30, [sp] ), then next is 0x00000000000007a4: ff 43 00 91 add sp, sp, #0x10 . This is where saved pc goes corrupt. This code gets called in the “raw_write_sctlr_current” (using objdump)
From the trace, we have the following information : The ret goes bad at 0000000000010758 <raw_write_sctlr>:
0x0000000000000908:  97fffe06      bl #-0x7e8 (addr 0x120)
0x0000000000000120:  3800a017      sturb w23, [x0, #10]
0x0000000000000124:  001c00d5      unallocated (Unallocated)
Taking exception 1 [Undefined Instruction]
…from EL1
…with ESR 0x2000000
Which is here:
0000000000010908 <arm64_c_environment>:
   10908: 97fffe06  bl 10120 <loop3_csw+0x1b>
   1090c: aa0003f8  mov x24, x0
This finally gave some leads in the qemu debug. There seems be some misalignment in smp_processor_id.
While tracing in gdb, we have
0x0000000000000908 in ?? ()
=> 0x0000000000000908: 06 fe ff 97   bl  0x120
(which is actually bl smp_processor_id (from src/arch/arm64/stage_entry.S))
Under arm64_c_environment (in objdump) we have;
10908:       97fffe06        bl      10120 <loop3_csw+0x1b>
Also in the trace we have
IN:
0x0000000000000908:  97fffe06      bl #-0x7e8 (addr 0x120)

Now loop3_csw is defined at (from objdump)
0000000000010105 <loop3_csw>:

So this + 0x1b = 10120

Thus it wants to branch and link to 0x120 but smp_processor_id is at 121.

smp_processor_id is at (from objdump)
0000000000010121 <smp_processor_id>:

This gives us where the code is failing. Next up is finding out the reason for this misalignment and rectifying it.

 

 

 

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Iru Cai | 25 Aug 05:13 2015
Picon

ectool misusage in autoport

Hi,

I'm trying to use autoport to port coreboot to a machine. However, when I look at the logs generated by:
./autoport --input_log=logs --make_logs --coreboot_dir=../..

I saw in logs/ectool.log:
../ectool/ectool: invalid option -- 'a'
usage: ../ectool/ectool [-vh?Vidq] [-w 0x<addr> -z 0x<data>]

So the autoport program doesn't make use of ectool, and it needs some fixing.

Iru

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
WordPress | 24 Aug 18:08 2015

New on blogs.coreboot.org: 2015-08-21 Librem 13: Weekly Progress Update

A new post titled "2015-08-21 Librem 13: Weekly Progress Update" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/08/24/2015-08-21-librem-13-weekly-progress-update/

This post covers the Librem 13 engineering considerations around writing to the SPI flash chip, and how that affects coreboot development. This builds on last week’s notes on the low level I/O for debugging coreboot builds. As always, email questions or comments to: larry.moberg <at> puri.sm.

The BIOS flash on the Librem 13 is an 8 MiB chip in a SOP-8 package. The EC firmware is located on a separate 64 KiB chip. This link can be used to locate the chips on your mainboard: the BIOS flash is halfway down, near the CPU heatpipe. The EC flash is at the bottom just below the DDR3L module.

Even without any patches specifically for the Librem 13, flashrom can flawlessly read its BIOS flash because it supports the PCH. Unless you write outside the BIOS region, you will not encounter any problems using flashrom to update your BIOS.

Please don’t update the Intel Firmware Descriptor or ME region just yet–all the IFD bits are marked read/write and flashrom is happy to execute a write to that region. The issue arises because the ME writes asynchronously to the ME region. A collision of flashrom and ME writes will corrupt the ME region and may brick the laptop. Purism intends to provide an unlocked ME that respects your freedom, so look for an update on the purism blog.

In-System Programming The BIOS Flash

The BIOS can be written and verified using a SOP-8 clip after closing the two sides of jumper J1 to assert the PCH RSMRST# pin. Warning: reflashing the BIOS risks bricking the laptop until in-system programming and/or soldering a new BIOS chip restores the BIOS to a good state.

EC Flash

The KB3930 datasheet, section 3.1 “Hardware Trap,” gives the method for programming the EC flash:

  1. Disconnect the battery and the A/C power so that the EC is fully powered down.
  2. Pull GPIO23/TP_ISP (pin 42) to GND. Note the internal 40K-ohm pull-up resistor.
  3. Connect the A/C power supply to the board. The EC is now powered up.
  4. TP_ISP sets CS#, SPI_CLK, MISO, and MOSI lines “High-Z”.
  5. Connect a SOP-8 clip and flash programmer and flash the EC firmware.

It should be noted fine-pitch soldering is required to connect to pin 42 on the EC. The KB3930 also supports firmware updates via software. In the interest of all users’ privacy and security, here is a listing of the 8051 opcodes for the current Librem 13 EC firmware.

EC Firmware Listing Notes

This listing is still incomplete. Here are some notes:

  1. KB3930-specific Special Function Registers (SFR), SFR bits, and interrupt vectors are labelled like in the datasheet.
  2. Besides the jump tables and switch tables, there is some 8051 code not listed as code. It appears to be unreachable, though in time the execution path to reach these sections may be found.
  3. No A5 opcode. Some 8051 implementations add this opcode, but the KB3930 uses a vanilla 8051 architecture.
  4. This is not Free Software. Users should have the ability to verify their shipped firmware against this listing but Purism’s goal is to provide a Free Software implementation of the EC firmware.

Conclusions

This post covers the steps for coreboot development and recovery. Fortunately, the EC firmware is not shared with the BIOS or ME blob, which makes flashrom’s job easier.

BIOS development is hard. One of the major challenges facing BIOS developers is a lack of accurate, comprehensive documentation for all the hardware coreboot interacts with. The “elephant in the room,” for an Intel-based laptop, is the Management Engine.

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
nancyor | 24 Aug 17:43 2015
Picon

build coreboot off-line

HI.
I want build coreboot off-line. Can I make that __????

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

--
Este mensaje le ha llegado mediante el servicio de correo electronico que ofrece Infomed para respaldar el
cumplimiento de las misiones del Sistema Nacional de Salud. La persona que envia este correo asume el
compromiso de usar el servicio a tales fines y cumplir con las regulaciones establecidas

Infomed: http://www.sld.cu/

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot


Gmane