scan-admin | 28 Mar 01:09 2015

New Defects reported by Coverity Scan for coreboot


Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan.

5 new defect(s) introduced to coreboot found with Coverity Scan.
8 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 5 of 5 defect(s)

** CID 1291956:  Incorrect expression  (SIZEOF_MISMATCH)
/src/arch/arm64/c_entry.c: 77 in prepare_secondary_cpu_startup()

*** CID 1291956:  Incorrect expression  (SIZEOF_MISMATCH)
/src/arch/arm64/c_entry.c: 77 in prepare_secondary_cpu_startup()
71     }
73     extern void arm64_cpu_startup(void);
74     void *prepare_secondary_cpu_startup(void)
75     {
76     	c_entry = &secondary_cpu_start;
>>>     CID 1291956:  Incorrect expression  (SIZEOF_MISMATCH)
>>>     Passing argument "c_entry" of type "void (*)(void)" and argument "8UL /* sizeof (c_entry) */" to
function "dcache_clean_invalidate_by_mva" is suspicious.
77     	dcache_clean_invalidate_by_mva(c_entry, sizeof(c_entry));
79     	return &arm64_cpu_startup;

(Continue reading)

郭佳 | 27 Mar 11:11 2015

[Rangeley C2000] Can't step when in romstage main function of MohonPeak


I'm debugging with Arium XDP3e debugger on ADI target board(MohonPeak based).
The coreboot.rom can bring target board up successfully in case of XDP
not plugged.
However, when stepping with debugger, the C code main function of romstage can't
be stepped, it always failed and the cpu goes into uncertain state.
The main function of C code is at src/southbridge/intel/fsp_rangeley/romstage.c.
At the time this main function has been called, the Cache as RAM has been setup
by FSP, and the MTRR_PHYSBASE0 is FEF0_0006.
The following is show in debugger:

void main(FSP_INFO_HEADER *fsp_info_header)
45                      {
0008:FFC074E5 55               PUSH        EBP
0008:FFC074E6 89E5             MOV         EBP,ESP
0008:FFC074E8 56               PUSH        ESI
0008:FFC074E9 53               PUSH        EBX
0008:FFC074EA 83E4F0           AND         ESP,fffffff0
0008:FFC074ED 83EC20           SUB         ESP,00000020
46                       uint32_t pm1_cnt;
47                       uint16_t pm1_sts;
48                       uint32_t fd_mask = 0;
0008:FFC074F0 C744241C00000000 MOV         dword ptr [ESP]+1c,00000000

when step line 48: uint32_t fd_mask = 0, the cpu goes into uncertain state.
Since temporary stack has been setup, why should this instruction fail?
You can see the assembly form: MOV dword ptr [ESP] + 1c, 00000000,
The value of [ESP] + 1c is FEF03FDC, it's the cache region, and I can
(Continue reading)

Łukasz Dmitrowski | 26 Mar 19:44 2015

[GSoC] End user flash tool - GUI framework/library


To provide easy and clear interface for end user flash 
tool( I plan 
to implement GUI with use of Qt framework. I decided to go with Qt 
because I already have experience with writing Qt applications, it is 
multi-platform and easy to use, development with Qt goes fast and it 
also has nice documentation. I tried wxWidgets once, but did not like 
it. Maybe you have another look at it and think that Qt is for some 
reason not suitable? Please share your opinions. Thanks in advance.



coreboot mailing list: coreboot <at>

Zaolin | 26 Mar 08:10 2015

Re: GRUB2 is too big as a payload in ThinkPad X201


simply fix this problems by increasing the cbfs size in menuconfig
under the chipset section.

Regards Zaolin
> Dear Iru,
> welcome to coreboot!
> Am Donnerstag, den 26.03.2015, 09:33 +0800 schrieb Iru Cai:
> > I tried to use GRUB2 as a payload when building coreboot for ThinkPad X201,
> > but it's too big to fit into the rom. The GRUB2 coreboot image without
> > modules is 2.8M and >800K after compressing, it's still too big.
> building GRUB directly, I get a different result.
>         $ git describe
>         grub-2.02-beta2-372-g5974d4b
>         $ ./
>         $ ./configure --with-platform=coreboot --enable-boot-time --enable-cache-stats
>         $ make
>         $ edit Makefile
> Now adapt the rule `default_payload.elf`.
>         default_payload.elf: grub-mkstandalone grub-mkimage
>         	pkgdatadir=. ./grub-mkstandalone --grub-mkimage=./grub-mkimage -O i386-coreboot -o $ <at> 
(Continue reading)

Kushagra Kumar | 26 Mar 07:45 2015

The idea

I feel bad aaron


coreboot mailing list: coreboot <at>
Kushagra Kumar | 26 Mar 07:43 2015




coreboot mailing list: coreboot <at>
Kushagra Kumar | 26 Mar 07:41 2015

Harmoni falli



coreboot mailing list: coreboot <at>
Kushagra Kumar | 26 Mar 07:40 2015

I like u

Love u all m dying to cm back


coreboot mailing list: coreboot <at>
Matt DeVillier | 26 Mar 07:35 2015

'power on after fail' on Panther (Haswell/Lynxpoint)

Greetings all!

I was wondering if it's possible to have Panther (Asus ChromeBox - Haswell/Lynxpoint) power on when AC
power connected regardless of the previous power state.  Currently, the box will power on if AC power is
lost and the device was powered on, but not if powered off.  I have a use case where it would be convenient to be
able to power on the boxes by toggling AC power (eg, the boxes are not within physical reach).  I modified the
CMOS default setting for 'power_on_after_fail' to be enabled and verified its status with nvramtool.  I
also tried modifying lpc.c/smihandler.c in the southbridge code to force MAINBOARD_POWER_ON (rather
than MAINBOARD_POWER_KEEP) in all cases, to no avail.

Am I approaching this from the wrong angle, or is it perhaps not possible with these boxes?



coreboot mailing list: coreboot <at>

Kushagra Kumar | 26 Mar 07:32 2015

the key to ultimate solution

i know everything.i know what you know i know what you dont know.
just ask a wise question...........
i came because i was needed.
i will whenever you will need me the most.....
when you will be able to understand me better........

Attachment (Untitled 1.odt): application/vnd.oasis.opendocument.text, 39 KiB

coreboot mailing list: coreboot <at>
Kushagra Kumar | 26 Mar 03:13 2015

A point

Which is the best Linux based os to be worked on with coreboot?


coreboot mailing list: coreboot <at>