Paul Kocialkowski | 3 Aug 11:21 2015
Picon

Porting Libreboot to the C201 Chromebook (veyron_speedy)

Over the past week or so, I've been working to get Libreboot running on
the latest ARM Chromebook: the C201, manufactured by Asus (codename
veyron_speedy). The laptop is running with a RK3288 SoC and ships with
Google's version of Coreboot preinstalled. It should require no
proprietary code nor any proprietary firmware load or microcode update
to boot, thus it would be a good fit for Libreboot, as a fully free
distribution of Coreboot.

In addition to that, the device's embedded controller (that handles
aspects of power management as well as the keyboard and a few other
things) is a microcontroller that is also running free software: the
free embedded controller firmware from Google.

Aside from that, it has a soldered Wi-Fi/bluetooth BCM4354 chip (cannot
be removed) that has a free driver but requires to load a proprietary
firmware on the chip. However, it is easy to work around that issue and
not use that chip at all, e.g. using an ath9k_htc dongle on one of the
two USB ports.

The GPU is a Mali T764, on which Luc has been doing some early work to
have free software support for it. It is uncertain[0] how long it will
take to have an usable free replacement for it, but now that there is
that hardware available, free graphics for Mali T GPUs would mean having
a recent laptop running fully free software, down to the firmware level,
without losing any major hardware feature, something that has hardly
ever been achieved yet. Thus, I believe it is of the utmost importance
to back Luc up on this, even if big players like ARM are trying hard to
make Lima not happen and to make it difficult for Luc to keep going.

Another aspect that I still have to look at in-depth is the ability to
(Continue reading)

Andrey Korolyov | 2 Aug 22:22 2015
Picon

i855GM on laptop - possible or not?

Hello,

I am trying to estimate amount of effort to make an old military Getac
to work with coreboot (currently it runs Insyde with computrace-style
code). All currently supported boards, lanner/em8510 and
digitallogic/adl855pc are desktops, which means that I should play
with EC support almost from scratch. Given the fact that i855G(M) was
quite popular in P-M era, are there any real issues standing behind
lack of support of a simular mobile platform in a tree?

Thanks in advance!

--

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

Patrick Georgi | 31 Jul 20:07 2015
Picon

ANN: Test builder change

Hi all,

I just changed the "coreboot" builder on http://qa.coreboot.org/ to use the just fixed "what-jenkins-does" build target (defined in $(top)/Makefile.inc), so all future builds will use that instead of the hard coded sequence of commands that used to be defined in our build environment.

I plan to move the "coreboot-gerrit" builder over in about a week. This means that from that point on, contributions on gerrit that predate the inclusion of http://review.coreboot.org/#/c/11097/ will break.

Therefore if you have long-running development branches, please remember to rebase them to a current upstream or you'll get a build error after pushing them.


Thanks,
Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Carl-Daniel Hailfinger | 30 Jul 14:01 2015
Picon
Picon

coreboot conference in Europe, October 2015

Dear coreboot developers, users and interested parties,

we are currently trying to organize a coreboot conference and developer
meeting in October 2015 in Germany.

This is not intended to be a pure developer meeting, we also hope to
reach out to manufacturers of processors, chipsets, mainboards and
servers/laptops/tablets/desktops with an interest in coreboot and the
possibilities it offers.

My plan (which is not final yet) is to have the Federal Office for
Information Security (BSI) in Germany host the conference in Bonn,
Germany. As a national cyber security authority, the goal of the BSI is
to promote IT security in Germany. For this reason, the BSI has funded
coreboot development in the past for security reasons.

The preliminary plans are to coordinate the exact date of the conference
to be before or after Embedded Linux Conference Europe, scheduled for
October 5-7 in Dublin, Ireland. Planned duration is 3-4 days. This means
we can either use the time window from Thursday Oct 1 to Sunday Oct 4,
or from Thursday Oct 8 to Monday Oct 12. The former has the advantage of
having cheaper hotel rooms available in Bonn, while the latter has the
advantage of avoiding Oct 3, a national holiday in Germany (all shops
closed).

ATTENTION vendors/manufacturers: If your main interest is forging
business relationships and/or strategic coordination and you want to
skip the technical workshops and soldering, we'll try make sure there is
one outreach day of talks, presentations and discussions on a regular
business day. Please indicate that with "(strategic)" next to your name
in the doodle linked below.

If you wonder about how to reach Bonn, there are three options available
by plane:
The closest is Cologne Airport (CGN), 30 minutes by bus to Bonn main
station.
Next is Düsseldorf Airport (DUS), 1 hour by train to Bonn main station.
The airport with most international destinations is Frankfurt Airport
(FRA), 2.5 hours by train to Bonn main station.
There's the option to travel by train as well. Bonn is reachable by
high-speed train (ICE), and other high-speed train stations are
reasonably close (30 minutes).

What I'm looking for right now is a rough show of hands who'd like to
attend so I can book a conference venue. I'd also like feedback on which
weekend would be preferable for you. If you have any questions, please
feel free to ask me directly <c-d.hailfinger.devel.2006 <at> gmx.net> or our
mailing list <coreboot <at> coreboot.org>.

Please enter your participation abilities in the doodle below:
http://doodle.com/bw52xs4fc7pxte6d

Regards,
Carl-Daniel Hailfinger

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Yu-Cheng Liu | 29 Jul 16:04 2015
Picon

Suggestion about motherboard that implement coreboot ?

hello,
I want to trigger the SMI/SMM in the coreboot,and burn it on the motherboard 
what kind of motherboard is suggest to use? 

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
WordPress | 29 Jul 20:45 2015

New on blogs.coreboot.org: coreboot changelog - Week of 2015-07-20

A new post titled "coreboot changelog - Week of 2015-07-20" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/07/29/coreboot-changelog-week-of-2015-07-20/

This covers commits 406effd5 up to commit ef0158ec

Apart from adding the google/glados board, this week’s activity concentrated on bug fixes in chipsets and mainboards, spanning AMD K8 and Hudson, Intel Sandy Bridge, Braswell and Skylake, Nvidia Tegra, Rockchip RK3288 and RISC-V. Most of the changes are too small individually and too spread out across the code base for a shout-out (or this report becomes just a fancy kind of “git log”), but two changes stand out:

Native RAM init on Sandybridge gained support for multiple DIMMs on the same channel, further improving the reverse engineered code base for that chipset.

To improve Skylake support, our 8250mem serial port driver now also supports Skylake’s 32bit UART access mode. This may also be useful when reducing code duplication in our serial console drivers (such as on ARM SoCs).

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
WordPress | 28 Jul 18:22 2015

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

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

This was a tough week. After having passed the coreboot building stage, I thought my work whould be easier now. But I had another thing coming.

As I had mentioned in my last post, I didn’t have any output while booting on qemu. So, the first aim was to get qemu monitor working. After some debug, I was able to get qemu monitor working to print onto my terminal (stdio)
This gave me then following :

qemu: fatal: Trying to execute code outside RAM or ROM at 0x0000000008000000

R00=00000950 R01=ffffffff R02=44000000 R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=00000000
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=00000000 R14=40010010 R15=08000000
PSR=400001db -Z– A und32
s00=00000000 s01=00000000 d00=0000000000000000
s02=00000000 s03=00000000 d01=0000000000000000
s04=00000000 s05=00000000 d02=0000000000000000
s06=00000000 s07=00000000 d03=0000000000000000
s08=00000000 s09=00000000 d04=0000000000000000
s10=00000000 s11=00000000 d05=0000000000000000
s12=00000000 s13=00000000 d06=0000000000000000
s14=00000000 s15=00000000 d07=0000000000000000
s16=00000000 s17=00000000 d08=0000000000000000
s18=00000000 s19=00000000 d09=0000000000000000
s20=00000000 s21=00000000 d10=0000000000000000
s22=00000000 s23=00000000 d11=0000000000000000
s24=00000000 s25=00000000 d12=0000000000000000
s26=00000000 s27=00000000 d13=0000000000000000
s28=00000000 s29=00000000 d14=0000000000000000
s30=00000000 s31=00000000 d15=0000000000000000
s32=00000000 s33=00000000 d16=0000000000000000
s34=00000000 s35=00000000 d17=0000000000000000
s36=00000000 s37=00000000 d18=0000000000000000
s38=00000000 s39=00000000 d19=0000000000000000
s40=000000 Abort trap: 6

I did some searching, this meant that the bootloader could not be loaded. And realised maybe the ROM qemu is being allotted is not sufficient. The ‘execute outside ram or rom’ is usually a jump to somewhere that qemu does not recognize as ROM/RAM.
Since we expect
CONFIG_BOOTBLOCK_BASE is 0x10000
CONFIG_ROMSTAGE_BASE  is 0x20000
CONFIG_SYS_SDRAM_BASE is 0x1000000
i.e ROM to start at 64k. So I ran qemu by giving a -m 2048M (for testing) and got over this fatal qemu error, but still wasn’t able to get coreboot to boot (no output on serial). This meant, some more debugging was needed.

I started to debug this using gdb. I created a gdb stub in the qemu boot (by using -s -S), but running gdb to connect to it gave me :
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
warning: Architecture rejected target-supplied description
0x40080000 in ?? ()

Which probably meant I will have to have to build a cross gdb (aarch64-linux-gnu-gdb) and use that.
For this, on linux we could have something called gdb-multiarch, but this is not available for macOSX.

I then turned to using Valgrind. There are Valgrind tools available that can help detect many memory management bugs.

This is what I got on valgrind,

==2070== Memcheck, a memory error detector
==2070== Copyright (C) 2002-2013, and GNU GPL’d, by Julian Seward et al.
==2070== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==2070== Command: aarch64-softmmu/qemu-system-aarch64 -machine virt -cpu cortex-a57 -machine type=virt -nographic -m 2048 -kernel /Users/naman/gsoc/coreboot2.0/coreboot/build/coreboot.rom
==2070==
–2070– aarch64-softmmu/qemu-system-aarch64:
–2070– dSYM directory is missing; consider using –dsymutil=yes
UNKNOWN __pthread_sigmask is unsupported. This warning will not be repeated.
–2070– WARNING: unhandled syscall: unix:330
–2070– You may be able to write your own handler.
–2070– Read the file README_MISSING_SYSCALL_OR_IOCTL.
–2070– Nevertheless we consider this a bug.  Please report
–2070– it at http://valgrind.org/support/bug_reports.html.
==2070== Warning: set address range perms: large range [0x1053c5040, 0x1253c5040) (undefined)
==2070== Warning: set address range perms: large range [0x239e56040, 0x255e55cc0) (undefined)
==2070== Warning: set address range perms: large range [0x255e56000, 0x2d5e56000) (defined)

2070 set address range perms means that the permissions changed on a particularly large block of memory.
That can happen because when a very large memory allocation or deallocation occurs – a mmap or umap call. Which meant we are leaking some memory, but we need to find where. I read some documentations and believe something called a massif tool (in valgrind) could be used. I am now looking at how to find where this memory gets eaten.

On the target now is getting some answers on valgrind if possible. But if I dont get sufficient leads, I would have to switch to gdb (aarch64 on macOSX) and continue my debugging.

 

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
WordPress | 29 Jul 03:25 2015

New on blogs.coreboot.org: [GSoC] EC/H8S firmware week #7|#8

A new post titled "[GSoC] EC/H8S firmware week #7|#8" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/07/29/gsoc-ech8s-firmware-week-78/

Week #7 was is little bit frustrating, because of no real progress, only more unfinished things which aren’t working. Week #8 was a lot better.

1. Sniffing the communication between the 2 embedded controllers H8S and PMH4.

I’ve tried to build an protocol analyser with the msp430, but the data output was somehow strange. For testing purpose I used my H8S firmware to produce testing data. But the msp430 decoded only wrong data. I’m using IRQs on the clock to do the magic and writing it to a buffer before transmitting it via UART. Maybe the msp430 is too slow for that? Possible. Set a GPIO to high when the IRQ routing start and to low when it ends. Visualize the clock signal and connect the  IRQ measure pin to an oscilloscope. The msp430 is far too slow. I’m using memory dereference in the IRQ routine, which takes a lot of time. Maybe the msp430 is fast enough, when using asm routine and registers to buffer the 3 byte transmission. But a logic analyser would definitely work. So I borr owed two logic analyser. An OLS (Openbench Logic Sniffer) and a Saleae Logic16.

There isn’t so much data on the lines. Every 50 ms there is a short transmission of 3 byte. But I don’t want to decode the data by hand. So it needs a decoder for the logic analyser. sigrok looks like the best start point and both analyser are supported.

I’ve started with the Openbench Logic Sniffer, but unfortunately it doesn’t have enough RAM to buffer the input long enough. Maybe the external trigger input can be used. But before doing additional things I would like to test with the Logic16.

The Logic16 doesn’t support any triggers but it can stream all data over USB even with multiple MHz. Good enough to capture all data. I found out that the best samplerate is 2 MHz. Otherwise the LE signal isn’t captured, because it’s a lot shorter than a clock change. In the end I created a decoder with libsigrokdecode.

sigrok-cli -i boots_and_shutdown_later_because_too_hot.sr –channels 0-3 -P ec_xp:clk=2:data=3:le=1:oe=0 | uniq -c 

67 0x01 0x07 0xc8
3 0x01 0x04 0xc8 
4 0x01 0x10 0x48
1120 0x01 0x17 0x48
67 0x01 0x07 0xc8

0x01 0x07 0xc8 is called when only power is plugged in, like a watchdog(every 500ms)
0x01 0x17 0x48 is called when the device is powered on, like a watchdog (every 50ms)
0x01 0x04 0xc8 around the time power button pressed
0x01 0x10 0x48 around the time power button pressed

2. Flash back the OEM H8S firmare

The OEM H8S firmware is included in the bios updates. cabextract and strings is enough for extracting it out of the update. Look for SREC lines. Put the SREC lines into a separate file and flash them back via UART bootloader and the renesas flash tool. The display powers up and it’s booting again with OEM BIOS.
I could imagine they are using a similar update method like the UART bootloader. First transfer a flasher application into RAM and afterwards communicate with the flasher to transfer the new firmware, but the communication works over LPC instead of UART.

3. Progress on the bootloader

I’ve implemented the ADC converter to enable the speaker amp and the display backlight brightness.

Written down LPC registers and just enable the Interface in order to get GateA20 working. Still unclear how far this works.

4. How to break into the bootloader?

The idea of the bootloader is providing a brick free environment for further development. The bootloader loads the application which adds full support for everything. It should be possible to stop the loading application and flash a new application into the EC flash. When starting development on the x60 or x201 I want to use I2C line as debug interface. I2C chips have a big footstep and are easy to access. But there must be a way to abort the loading. I will use the function key in combination with the leds.

  1. Remove the battery and power plug.
  2. Press the function key
  3. Put the power plug in
  4. Wait until leds blinking
  5. release the function key within 5 seconds after the leds starting to blink to enter the bootloader.

The H8S will become I2C slave on a specific address.

What next?

  • Add new PMH4 commands to the H8S
  • solder additional pins to MAINOFF PWRSW_H8 A20 KBRC
  • use the logic analyser to put the communication in relation with these signals
  • UART shell
  • I2C master & client
  • solder LPC pins to analyse firmware update process
  • test T40 board with new PMH4 commands and look if all power rails are on
--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Patrick Georgi | 29 Jul 20:45 2015
Picon

coreboot changelog - Week of 2015-07-20

(This covers commits 406effd5 up to commit ef0158ec)

Apart from adding the google/glados board, this week’s activity concentrated on bug fixes in chipsets and mainboards, spanning AMD K8 and Hudson, Intel Sandy Bridge, Braswell and Skylake, Nvidia Tegra, Rockchip RK3288 and RISC-V. Most of the changes are too small individually and too spread out across the code base for a shout-out (or this report becomes just a fancy kind of “git log”), but two changes stand out:

Native RAM init on Sandybridge gained support for multiple DIMMs on the same channel, further improving the reverse engineered code base for that chipset.

To improve Skylake support, our 8250mem serial port driver now also supports Skylake's 32bit UART access mode. This may also be useful when reducing code duplication in our serial console drivers (such as on ARM SoCs).


Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Iru Cai | 28 Jul 16:26 2015
Picon

coreboot for vexpress-v9 qemu failed

Hi,

I am using QEMU from Arch Linux x86_64 official repo. I need to test my built u-boot payload, so I tried to build a QEMU ARM coreboot image. However, it failed to run and had the following output.

qemu: fatal: Trying to execute code outside RAM or ROM at 0xfffffffe

R00=00000000 R01=00011b70 R02=00000000 R03=ffffffff
R04=00c51878 R05=00000147 R06=00000000 R07=00000000
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000002 R13=000fffd8 R14=ffffffff R15=fffffffe
PSR=600000ff -ZC- T sys32
s00=00000000 s01=00000000 d00=0000000000000000
s02=00000000 s03=00000000 d01=0000000000000000
s04=00000000 s05=00000000 d02=0000000000000000
s06=00000000 s07=00000000 d03=0000000000000000
s08=00000000 s09=00000000 d04=0000000000000000
s10=00000000 s11=00000000 d05=0000000000000000
s12=00000000 s13=00000000 d06=0000000000000000
s14=00000000 s15=00000000 d07=0000000000000000
s16=00000000 s17=00000000 d08=0000000000000000
s18=00000000 s19=00000000 d09=0000000000000000
s20=00000000 s21=00000000 d10=0000000000000000
s22=00000000 s23=00000000 d11=0000000000000000
s24=00000000 s25=00000000 d12=0000000000000000
s26=00000000 s27=00000000 d13=0000000000000000
s28=00000000 s29=00000000 d14=0000000000000000
s30=00000000 s31=00000000 d15=0000000000000000
s32=00000000 s33=00000000 d16=0000000000000000
s34=00000000 s35=00000000 d17=0000000000000000
s36=00000000 s37=00000000 d18=0000000000000000
s38=00000000 s39=00000000 d19=0000000000000000
s40=00000000 s41=00000000 d20=0000000000000000
s42=00000000 s43=00000000 d21=0000000000000000
s44=00000000 s45=00000000 d22=0000000000000000
s46=00000000 s47=00000000 d23=0000000000000000
s48=00000000 s49=00000000 d24=0000000000000000
s50=00000000 s51=00000000 d25=0000000000000000
s52=00000000 s53=00000000 d26=0000000000000000
s54=00000000 s55=00000000 d27=0000000000000000
s56=00000000 s57=00000000 d28=0000000000000000
s58=00000000 s59=00000000 d29=0000000000000000
s60=00000000 s61=00000000 d30=0000000000000000
s62=00000000 s63=00000000 d31=0000000000000000
FPSCR: 00000000

After I add '-S -s' option to QEMU, I found the problem is in bootblock_simple.c, and the `main()' function in gdb is:

0x00000192 in ?? ()
=> 0x00000192:    08 b5    push    {r3, lr}
(gdb) disas $pc,+50
Dump of assembler code from 0x192 to 0x1c4:
=> 0x00000192:    push    {r3, lr}
   0x00000194:    bl    0x1704
   0x00000198:    bl    0x18c
   0x0000019c:    bl    0xd10
   0x000001a0:    bl    0x634
   0x000001a4:    bl    0x18e
   0x000001a8:    bl    0x190
   0x000001ac:    ldmia.w    sp!, {r3, lr}
   0x000001b0:    b.w    0x159c
   0x000001b4:    push    {r3, lr}
   0x000001b6:    mrc    15, 0, r3, cr1, cr0, {0}
   0x000001ba:    lsls    r2, r3, #29
   0x000001bc:    bpl.n    0x1c4
   0x000001be:    bl    0x2ac
   0x000001c2:    b.n    0x1cc
End of assembler dump.
(gdb) si
0x00000194 in ?? ()
=> 0x00000194:    01 f0 b6 fa    bl    0x1704
(gdb) b *0x198
Breakpoint 3 at 0x198
(gdb) c
Continuing.

Breakpoint 3, 0x00000198 in ?? ()
=> 0x00000198:    ff f7 f8 ff    bl    0x18c
(gdb) b *0x19c
Breakpoint 4 at 0x19c
(gdb) c
Continuing.

Breakpoint 4, 0x0000019c in ?? ()
=> 0x0000019c:    00 f0 b8 fd    bl    0xd10
(gdb) b *0x1a0
Breakpoint 5 at 0x1a0
(gdb) c
Continuing.
Remote connection closed

So there may be something wrong when setting up the console, however I'm not so familiar with debugging the ROM so I don't know which function call raise the problem.

Thanks,
Iru

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Karl Schmidt | 27 Jul 19:19 2015

Dead links - missing information?

This page has several dead links and I was unable to find a single coreboot server motherboard for 
sale after following the links.

http://www.coreboot.org/Products

I think I understand why this is happening.

-- 
--------------------------------------------------------------------------------
Link to our website and get free US-48 shipping on your next order.

Karl Schmidt                                  EMail Karl <at> xtronics.com
Transtronics, Inc.                              WEB https://secure.transtronics.com
3209 West 9th Street                             Ph (785) 841-3089
Lawrence, KS 66049                              FAX (785) 841-3089

The men the American people admire most extravagantly are the greatest liars: the men they detest 
most violently are those who try to tell them the truth.” H.L. Mencken

--------------------------------------------------------------------------------

--

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


Gmane