Re: [coreboot] mute button on X200
by Francis Rowe
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 22/08/15 13:48, Idwer Vollering wrote:
> 2015-08-22 11:04 GMT+02:00 Francis Rowe <info(a)gluglug.org.uk>: Any
> ideas?
>
>> Boot into vendor BIOS/EFI thing, install and start acpi_listen,
>> then press the mute button.
>> http://linux.die.net/man/8/acpi_listen
>
I tried that just now. I don't see any events in acpi_listen, when I
use the mute button. I do see events for the up/down volume buttons.
The mute button does work (only in factory BIOS), but I don't see any
events in the OS. The volume in gnome isn't shown muted, either. I
think the mute button might be hardware based, while the volume
buttons are software (ACPI).
On 22/08/15 14:09, Alexander Couzens wrote:> On Sat, 22 Aug 2015
> and take a look on "Interaction with the Embedded Controller" at
> https://wiki.ubuntu.com/Kernel/Reference/ACPITricksAndTips
>
> you want to know which _QXX function is called. maybe that one is
empty in the coreboot aml for h8s..
Thanks, I'll take a look. It doesn't seem like the mute button is
controlled by ACPI, though.
Perhaps I could use ectool (and other utils?) to see what happens when
muting.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJV2IoGAAoJEP9Ft0z50c+UkVkH/1tv8GLz3nrsUW8girDImciJ
eT1jsnnlehTBmEIQtJ4SADqZYrtCUdLIutuV+/r53LIqxHT/LRAGDd67HotBY8UY
sIWFx2YysDqwpCBnPIdptLVUHrd2xBwS4oGYfiPd8muhFTuhnJ72/+50EhmD96w3
RwDZrZJ/NWbF9OX4YaptOvoBoOkuyMO+thpNBnqcAfUkD/9IEjLOrm7ig7YxCIkm
jNhiR9FobQWQhjq8Vl1k6NyRLZdx6Q8YKb8uubbQYL6E95+G76xhpLK62rTFMBJ4
cmHiOX/kcUqey8qI1kHYRtuAK0NIc/jm9WhEitHXudLtivNwZr0OfQHyAisfX9E=
=TE96
-----END PGP SIGNATURE-----
3 years, 12 months
mute button on X200
by Francis Rowe
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
On the Lenovo X200 with coreboot installed, the volume up/down keys on
the keyboard work, but the mute key doesn't (it does in factory BIOS).
I'm investigating this myself, but in case I fail, I'm also reporting
this here.
First I tried monitoring it in xev, but that doesn't seem to show
anything in factory bios either. This button is controlled by the EC,
isn't it? And coreboot has to expose that somehow.
I tried looking in the coreboot src to see what I needed to modify,
but I haven't found it yet. I looked in src/ec/lenovo/h8/acpi/ec.asl
mostly.
Any ideas?
Regards,
Francis Rowe.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJV2DsEAAoJEP9Ft0z50c+U2ZoIAKloxikP2I1F3oRlWCIDLuCE
Dd6ylZVGImMnBB1cEL/uac8uedToFOFKKRr170cY2WN3jR5fybWyQ80sGHeWdOD3
MrbbIqYNJGnSbzNfHdSqgS3wDqvCXPzMX6dNLo8MU6uLIZheG5/laEaAMpPuRyYI
hkwD3pJhk7Wer1W9nFAAhZBzCOdl8Eh5KAMEp6xJqvAAlp623J8tuIzUQRl+Din6
enpJjDnc/ksiZqXoTs2iM65FmEVRj3rwImem54eIjcLWbrQrtnFyUYOZUHaIVj7G
gCv+ES2wDOqDn51TqHlHyr5KLBFsxqaEfQsy1WuLNmdGOb3tNXa2LWd+AYQMnMI=
=TLev
-----END PGP SIGNATURE-----
3 years, 12 months
Adding Coreboot support to the F2A85-M PRO mainboard
by Paul Kocialkowski
The Asus F2A85-M and F2A85-M LE boards are currently supported in
Coreboot. However, as the wiki[0] page emphasis, the F2A85-M PRO version
of the board is the more widely available one.
A few weeks ago, GNUtoo (CC-ed) and I decided to get one each and add
Coreboot support to those. It looks like the main difference between the
F2A85-M and the F2A85-M PRO is the Super I/O, according to the wiki[0].
A year ago, Alec Ari (CC-ed) submitted support for that Super I/O, his
code[1] was not merged and eventually, Matt DeVillier (CC-ed) added
support for that chip (but apparently missing early serial support).
I wonder if either Alec or Matt have the F2A85-M PRO in hands and
whether they did write code to support the board, as the wiki[0]
suggests. If so, it would be useful to send it as-is so that I could
have a base to add support for the board.
Otherwise, I will start "from scratch", using the F2A85-M code as a
base.
Note that I'm new to working on low-level on x86 hardware (but I'm used
to ARM hardware), so I may need some pointers here and there to get this
done properly.
Generally speaking, any help regarding that board is welcome!
Thanks!
[0]: http://www.coreboot.org/Board:asus/f2a85-m#F2A85_series_status
[1]: http://review.coreboot.org/#/c/4589/
[2]: http://review.coreboot.org/#/c/10232/
--
Paul Kocialkowski, Replicant developer
Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.
Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/
3 years, 12 months
From wildcat linking to exploring new languages
by Nico Huber
Hi coreboot folks!
I dared to link a coreboot ramstage with, well, not only C but also some
fancy Ada code. Things worked out well enough and I'd like to release
the code and upstream it.
So, first question: Would it be accepted? being written in a foreign
language?
This code is essentially another native graphics init for Intel hardware,
currently supporting eDP on Ivybridge (tested as native graphics init),
and everything but VGA on Haswell/Broadwell (only tested after VBIOS
ran). It's actually written in SPARK (Ada subset, with some provability
extras). Some internal discussion concluded that we may release it if
there is either real interest in the community to take part in further
development or at least the will to review it and give feedback. As this
is one of the areas where I work on nearly the same code in C and Ada, I
hope for the former :)
Thoughts?
And here comes the disclaimer: Supporting the upstreaming of this code
may result in further development in Ada (currently I only have simple
device drivers in mind). I hereby wash my hands of any damage that may
arise from that :P
Nico
--
M. Sc. Nico Huber
Senior Berater SINA-Softwareentwicklung
Netzwerk- & Client-Sicherheit / Network & Client Security
Division Öffentliche Auftraggeber / Public Authorities
secunet Security Networks AG
Tel.: +49-201-5454-3635, Fax: +49-201-5454-1325
E-Mail: nico.huber(a)secunet.com
Mergenthalerallee 77, 65760 Eschborn, Deutschland
www.secunet.com
______________________________________________________________________
Sitz: Kronprinzenstraße 30, 45128 Essen, Deutschland
Amtsgericht Essen HRB 13615
Vorstand: Dr. Rainer Baumgart (Vors.), Thomas Pleines
Aufsichtsratsvorsitzender: Dr. Peter Zattler
______________________________________________________________________
3 years, 12 months
Re: [coreboot] memtest86+ test fails at 3070.7MB
by Jonathan A. Kollasch
On Thu, Aug 20, 2015 at 06:36:00PM +0800, Iru Cai wrote:
> Hi,
>
> I installed coreboot(4.1-315-gf58746b) on a ThinkPad X220, with factory VGA
> option ROM and SeaBIOS 1.7.5 as payload. When I run memtest86+ on this
> machine, it reports a fail at 3070.7MB. If I just install a 2GB memory
> module, it passes the test. So what makes memtest86+ give a test failure?
Any other differences, particularly with respect to attached USB devices
between each test?
If you run memtest86+ on SeaBIOS w/ USB (or other DMA-using hardware)
on coreboot, you can expect to see memory test failures due to DMA
clobbering the memory you're trying to test. You need a memtest86+
patched to not check for a coreboot/linuxbios memory map. SeaBIOS
reserves its own memory in the BIOS memory map, but not the coreboot
memory map, so when running SeaBIOS the coreboot memory map is wrong.
Jonathan Kollasch
3 years, 12 months
serial console : no keystroke
by Maxime de Roucy
Hello,
I am trying vanilla coreboot/SeaBios on an pc-engines apu1d4 :
http://www.pcengines.ch/apu1d4.htm
The board natively use a modified version of coreboot, the sources are
available at http://www.pcengines.ch/howto.php#CoreBoot (coreboot_14090
8.tar.gz)
I use a usb-SR232 adapter to connect on the board.
I use minicom and picocom. Both are working fine.
BUT
When I use coreboot vanilla (master) with SeaBios vanilla (master, I
also tried 1.7.5), when I get to "Press ESC for boot menu" I can't send
keystroke to SeaBios through the serial console.
I have to plug an USB keyboard and press ESC on it.
I tried scancode (F10, F12, Q (0x10)) same problem.
I disabled hardware and software flow control on minicom.
In fact, SeaBios doesn't get ANY keystroke from the serial port.
I can press any keyboard key in minicom/picocom the message "Press ESC
for boot menu." stay until timeout (DEFAULT_BOOTMENU_WAIT) (I set
etc/boot-menu-wait to 90000 to verify that… so I am pretty sure of it).
Furthermore, after I enter the boot menu via usb keyboard I can't
choose anything from the menu through minicom/picocom.
I have to use an USB keyboard.
When I get in the OS (tinycore Linux), minicom/picocom input works.
I don't have the problem with the modified coreboot/SeaBios from PC
-Engines.
At first I thought it's a SeaBios problem but the keystroke code part
(src/boot.c) are the same in vanilla SeaBios and PC-Engines SeaBios.
PC-Engines sources don't have .config files (nor for coreboot neither
for SeaBios) but have build/config.h and out/autoconf.h.
I tried to look for some interesting difference between vanilla and PC
-Engines sources for those file but my coreboot/SeaBios knowledge
weren't enough to spot anything.
Can anyone help me ?
Since I don't know if the problem relies on coreboot or SeaBios I post
this on both mailing-list.
I attached to this mail :
* my .config coreboot file
* my build/config.h coreboot file
* my payloads/external/SeaBIOS/seabios/out/autoconf.h SeaBios file
* PC-Engines build/config.h
* PC-Engines SeaBios autoconf.h
--
Regards
Maxime
4 years
memtest86+ test fails at 3070.7MB
by Iru Cai
Hi,
I installed coreboot(4.1-315-gf58746b) on a ThinkPad X220, with factory VGA
option ROM and SeaBIOS 1.7.5 as payload. When I run memtest86+ on this
machine, it reports a fail at 3070.7MB. If I just install a 2GB memory
module, it passes the test. So what makes memtest86+ give a test failure?
Iru
4 years
