date:20160802

Re: [coreboot] Sequence of the Excution of the drivers in Coreboot

2016-08-02 Thread Zoran Stojsavljevic

Hello Alok,

>From another @ thread, you might also be interested in (few @ threads
below): [coreboot] Where is the first instruction?

*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 Tue, Aug 2, 2016 at 6:58 PM, Alok Kumar 
wrote:

> Hi All,
>Previosly I have worked in the UEFI- BIOS and just now I have started
> with Core boot. Like In the BIOS we have startup.asm the very first file
> which will get execute in the UEFI BIOS. IN the same way I want to know
> which is the first driver/file will get executed in the coreboot in the
> case if we are using Intel Platform.
>
>Please guide me how can I identify the sequence of the drivers getting
> executed in the coreboot.
>
> Regards
> Alok
>
> --
> 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

[coreboot] Sequence of the Excution of the drivers in Coreboot

2016-08-02 Thread Alok Kumar

Hi All,
   Previosly I have worked in the UEFI- BIOS and just now I have started
with Core boot. Like In the BIOS we have startup.asm the very first file
which will get execute in the UEFI BIOS. IN the same way I want to know
which is the first driver/file will get executed in the coreboot in the
case if we are using Intel Platform.

   Please guide me how can I identify the sequence of the drivers getting
executed in the coreboot.

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

[coreboot] New on blogs.coreboot.org: [GSoC] Better RISC-V Support, week #10

2016-08-02 Thread WordPress

A new post titled "[GSoC] Better RISC-V Support, week #10" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/08/02/gsoc-better-risc-v-support-week-10/

This past week, I worked on the virtual memory initialization code of coreboot on RISC-V. The first part of this was to update encoding.h a file that defines constants such as bit masks which are necessary for interacting with RISC-V’s Control and Status Registers. As a result, I also had to change a few files that relied on outdated constants. Then I wrote some code to walk the page table structures, and fixed one or two bugs in the page table setup code. Unfortunately my patches aren’t as finished as I would like them to be.
When I tested my changes with a Linux payload (which I had to edit the ELF headers of, because Linux uses virtual addresses, while cbfstool and the SELF loader use physical addresses), I stumbled upon another strange error: I get a store access fault in the instruction of the trap handler that saves the first register, even if I initialize the stack pointer to a value that’s within the RAM. When the trap handler runs again to handle this store access fault, it runs without any problems. This fault is especially confusing, because machine mode should always be able to access RAM through its physical addresses.
What’s next?
During the next week, I’ll be traveling and won’t be able to work on coreboot. When I return, I will rework my patches so they can be merged, and hopefully understand the aforementioned access fault problem. Properly set-up page tables should bring me a step closer to running Linux on coreboot/RISC-V (without bbl in the middle).
If time permits, I will start porting coreboot to the Nexys 4 DDR devboard.

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

Re: [coreboot] ARM Trusted Firmware build issue

2016-08-02 Thread Paul Kocialkowski

Le mercredi 20 juillet 2016 à 19:33 -0700, Stefan Reinauer a écrit :
> Martin produced a binutils fix for the issue. Whether the binutils 
> people will find it to be the "right" fix is still to be found out, but 
> it seems to allow compiling the latest, unmodified ARM TF.

Upstream just answered with a comprehensive description of what is happening and
a patch to solve the issue, at:
https://sourceware.org/bugzilla/show_bug.cgi?id=20364

Could someone try that and report back (either here directly on the tracker)
whether it solves the issue? There's a chance this fix will be accepted upstream
if it works.

Cheers,

-- 
Paul Kocialkowski, developer of low-level free software for embedded devices

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] New Defects reported by Coverity Scan for coreboot

2016-08-02 Thread scan-admin


Hi,

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

56 new defect(s) introduced to coreboot found with Coverity Scan.
52 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 20 of 56 defect(s)


** CID 1361056:  Memory - illegal accesses  (OVERRUN)
/dev/cb-build/coreboot-coverity.0/AMD_LAMAR/agesa/amdlib.c: 1411 in 
IdsErrorStop()



*** CID 1361056:  Memory - illegal accesses  (OVERRUN)
/dev/cb-build/coreboot-coverity.0/AMD_LAMAR/agesa/amdlib.c: 1411 in 
IdsErrorStop()
1405} post = {0xDEAD, FileCode, 0xDEAD, FileCode};
1406UINT16 offset = 0;
1407UINT16 j;
1408 
1409while(1) {
1410offset %= sizeof(struct POST) / 2;
>>> CID 1361056:  Memory - illegal accesses  (OVERRUN)
>>> Overrunning array of 3 4-byte elements at element index 15 (byte offset 
>>> 60) by dereferencing pointer "(UINT32 *)( + offset)".
1411WriteIo32(80, *((UINT32*)(+offset)));
1412++offset;
1413for (j=0; j<250; ++j) {
1414ReadIo8(80);
1415}
1416}

** CID 1361055:(OVERRUN)
/dev/cb-build/coreboot-coverity.0/AMD_OLIVEHILLPLUS/agesa/amdlib.c: 1411 in 
IdsErrorStop()
/dev/cb-build/coreboot-coverity.0/ODE_E21XX/agesa/amdlib.c: 1411 in 
IdsErrorStop()
/dev/cb-build/coreboot-coverity.0/AMD_DB_FT3B_LC/agesa/amdlib.c: 1411 in 
IdsErrorStop()



*** CID 1361055:(OVERRUN)
/dev/cb-build/coreboot-coverity.0/AMD_OLIVEHILLPLUS/agesa/amdlib.c: 1411 in 
IdsErrorStop()
1405} post = {0xDEAD, FileCode, 0xDEAD, FileCode};
1406UINT16 offset = 0;
1407UINT16 j;
1408 
1409while(1) {
1410offset %= sizeof(struct POST) / 2;
>>> CID 1361055:(OVERRUN)
>>> Overrunning array of 3 4-byte elements at element index 15 (byte offset 
>>> 60) by dereferencing pointer "(UINT32 *)( + offset)".
1411WriteIo32(80, *((UINT32*)(+offset)));
1412++offset;
1413for (j=0; j<250; ++j) {
1414ReadIo8(80);
1415}
1416}
/dev/cb-build/coreboot-coverity.0/ODE_E21XX/agesa/amdlib.c: 1411 in 
IdsErrorStop()
1405} post = {0xDEAD, FileCode, 0xDEAD, FileCode};
1406UINT16 offset = 0;
1407UINT16 j;
1408 
1409while(1) {
1410offset %= sizeof(struct POST) / 2;
>>> CID 1361055:(OVERRUN)
>>> Overrunning array of 3 4-byte elements at element index 15 (byte offset 
>>> 60) by dereferencing pointer "(UINT32 *)( + offset)".
1411WriteIo32(80, *((UINT32*)(+offset)));
1412++offset;
1413for (j=0; j<250; ++j) {
1414ReadIo8(80);
1415}
1416}
/dev/cb-build/coreboot-coverity.0/AMD_DB_FT3B_LC/agesa/amdlib.c: 1411 in 
IdsErrorStop()
1405} post = {0xDEAD, FileCode, 0xDEAD, FileCode};
1406UINT16 offset = 0;
1407UINT16 j;
1408 
1409while(1) {
1410offset %= sizeof(struct POST) / 2;
>>> CID 1361055:(OVERRUN)
>>> Overrunning array of 3 4-byte elements at element index 15 (byte offset 
>>> 60) by dereferencing pointer "(UINT32 *)( + offset)".
1411WriteIo32(80, *((UINT32*)(+offset)));
1412++offset;
1413for (j=0; j<250; ++j) {
1414ReadIo8(80);
1415}
1416}

** CID 1361054:  Memory - illegal accesses  (OVERRUN)
/dev/cb-build/coreboot-coverity.0/AMD_BETTONG/agesa/amdlib.c: 1411 in 
IdsErrorStop()



*** CID 1361054:  Memory - illegal accesses  (OVERRUN)
/dev/cb-build/coreboot-coverity.0/AMD_BETTONG/agesa/amdlib.c: 1411 in 
IdsErrorStop()
1405} post = {0xDEAD, FileCode, 0xDEAD, FileCode};
1406UINT16 offset = 0;
1407UINT16 j;
1408 
1409while(1) {
1410offset %= sizeof(struct POST) / 2;
>>> CID 1361054:  Memory - illegal accesses  (OVERRUN)
>>> Overrunning array of 3 4-byte elements at element index 15 (byte offset 
>>> 60) by dereferencing pointer "(UINT32 *)( + offset)".
1411WriteIo32(80, *((UINT32*)(+offset)));
1412++offset;
1413for (j=0; j<250; ++j) {
1414ReadIo8(80);
1415}
1416

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

2016-08-02 Thread Raptor Engineering Automated Coreboot Test Stand

The ASUS KFSN4-DRE (K8) fails verification for branch master as of commit 
8c8403ff5f7bab0f6e5c4ccc20e5be0afbca569b

The following tests failed:
BOOT_FAILURE

Commits since last successful test:
8c8403f console: Drop leftover struct console_driver
b168db7 intel/skylake: Fix UART build options
0f2025d intel/lynxpoint,broadwell: Fix eDP display in Windows, SeaBios & Tiano
6e8233a soc/intel/quark: Enable use of hard reset
aac31ca soc/intel/common: Fix build error in reset.c
0cd338e Remove non-ascii & unprintable characters
bb9722b Add newlines at the end of all coreboot files
049b462 arch/x86: Enable postcar console

See attached log for details

This message was automatically generated from Raptor Engineering's ASUS 
KFSN4-DRE (K8) test stand
Want to test on your own equipment?  Check out 
https://www.raptorengineeringinc.com/content/REACTS/intro.html

Raptor Engineering also offers coreboot consulting services!  Please visit 
https://www.raptorengineeringinc.com for more information

Please contact Timothy Pearson at Raptor Engineering 
 regarding any issues stemming from this 
notification


1470130913-2-automaster.log.bz2
Description: application/bzip2
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Sequence of the Excution of the drivers in Coreboot

[coreboot] Sequence of the Excution of the drivers in Coreboot

[coreboot] New on blogs.coreboot.org: [GSoC] Better RISC-V Support, week #10

Re: [coreboot] ARM Trusted Firmware build issue

[coreboot] New Defects reported by Coverity Scan for coreboot

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

6 matches

Site Navigation

Mail list logo

Footer information