January 2014 - coreboot - mail.coreboot.org

Re: [coreboot] Super I/O: Nuvoton NCT6779D support (Incomplete and stuck)
by Alec Ari Jan. 26, 2014

Jan. 26, 2014

Antti (and other devs) the datasheet is available here: http://www.mediafire.com/view/v49j1a5349m2h2e/NCT6779D_Datasheet_V1_1.pdf I am not under NDA with Nuvoton so I should be OK, if not I can always delete the datasheet upon request. Alec Ari

1 0

Unique information
by Vladimir 'φ-coder/phcoder' Serbinenko Jan. 26, 2014

Jan. 26, 2014

Hello, all. There is amount of information that should be unique to each machine and is supplied by coreboot. Most common examples are: - mobo serial number - UUID - Internal mac. While first 2 are not very important, the fact that currently on some boards all of them will share the same API is disturbing. For some machines like thinkpads this info is in some EEPROM and can be easily read (see my path on gerrit to do so) On other boards that info is stored in vendor flash and currently coreboot just uses some hardcoded string which is a problem. I think that this info should be stored in some text config file in CBFS. E.g: Mainboard serial: 99887766 Mainboard UUID: acdea9c8-be5e-4799-a972-ead8dab8e5c0 Internal MAC: 00:11:22:33:44:55 The file would be added at compile time from info supplied by user or randomly-generated strings if user didn't supply it. In case of missing file coreboot should disable internal NIC if possible. Duplicate macs should never go into networks. It being a separate file allows it to be easly replaced without recompilation. Is everyone ok with such plan of action?

2 1

Fwd: Re: coreboot port for macbook2,1
by Vladimir 'φ-coder/phcoder' Serbinenko Jan. 25, 2014

Jan. 25, 2014

-------- Original Message -------- Subject: Re: [coreboot] coreboot port for macbook2,1 Date: Sat, 25 Jan 2014 01:23:12 +0100 From: Vladimir 'φ-coder/phcoder' Serbinenko <phcoder(a)gmail.com> To: Mono <mono(a)posteo.de> On 24.01.2014 23:20, Mono wrote: > Hallo, > Would you help me on a coreboot port? I just installed coreboot on a Thinkpad X60 following the wiki. Now I want it on this mid-2007 macbook2,1 too. > I read some pages in the wiki and started to collect information about the macbook. it seems it has no superIO chip and I dont know what to think of the ectool output. As I understood by now, not knowing how the ec might interfere with the bios or coreboot is one of the big obstacles, no? I hope that once I would try a coreboot flash, recovery might be possible by an external programmer (which I do not have, yet). the flash chip is the same as on the X60 (I've read the factory bios already) as is the northbridge and southbridge. an usb debug port seems available. > I've put the log files here: http://macbook.donderklumpen.de/coreboot/ > Any comment about what you think about this and how I should proceed is very much welcome! > Good news is that other than EC and some minor points, your macbook is a copy of X60. With some luck a qualified dev can do it in a week (you may want to post bounty for it). You need to get console. EHCI debug would be the best option on your laptop. http://www.coreboot.org/EHCI_Debug_Port#Finding_the_USB_debug_port Take USB 2.0 stick and plug it into different port until it appears as device one on bus 3. You'll have to make a USB debug dongle or buy one (short supply). You'll also need to find your flash chip. Your laptop has this chip: http://orzparts.com/index.php?main_page=product_info&products_id=732 You'll have to teardown the whole laptop, looking at every chip which seems similar. Remember to discharge from static electricity before opening your laptop and not to wear anything that produces it. This has a risk of breaking your laptop, proceed at your own risk, you've been warned. > thanks > Mono >

1 1

Compilation Error building FILO
by Raymond van den Heuvel Jan. 24, 2014

Jan. 24, 2014

Hi, I am experiencing a problem with building filo. I am getting the following error: /........../coreboot/payloads/filo/build/libpayload/lib/libpayload.a(keyboard.libc.o): In function `keyboard_disconnect': keyboard.c:(.text+0x208): undefined reference to `keyboard_wait_write' make: *** [/........../coreboot/payloads/filo/build/filo] Error 1 I have tried various guides to try to build but I cannot get it to work. Does anybody else have the same problem? Or how can I fix it? Regards, Raymond

1 0

Re: [coreboot] Chromebox debugging.
by Kyösti Mälkki Jan. 24, 2014

Jan. 24, 2014

On 01/24/2014 01:39 AM, Timothy Potter wrote: > Hi Kyosti, Thanks the pointers. I tried adding the changes for dbgp from > the bug20-2.6.35-linaro to the 2.6.32 kernel I'm running on the phone. You > can see the results here: > > https://github.com/DengueTim/jordan-kernel/commits/AeroKernel > You still need the two patches from http://www.coreboot.org/EHCI_Gadget_Debug Looks like you reverted them for this attempt. > On startup, in /proc/kmsg I see: > > <7>[ 2.010284] dbgp gadget: setup: desc device > <7>[ 2.010314] dbgp gadget: setup complete: 0, 8/8 > <7>[ 2.010467] dbgp gadget: setup: desc device > <7>[ 2.010467] dbgp gadget: setup complete: 0, 18/18 > <7>[ 2.010589] dbgp gadget: setup: failure req 6 v 200 > <7>[ 2.010681] dbgp gadget: setup: failure req 6 v 200 > <7>[ 2.010772] dbgp gadget: setup: failure req 6 v 200 > <7>[ 2.016204] dbgp gadget: setup: failure req 6 v 3ee > Ignore those, g_dbgp driver implements only a few USB requests required for this special debug gadget purpose. > I've attached the full log in case there's more clues as to why it's > failing. Any more suggestions of what I should be looking at? I requested "lsusb" and "sudo lsusb -v" and dmesg from the other end of the communication too. If you see a "Debug descriptor" listed there, you can connect and reboot the chromebook with usbdebug enabled and collect new dmesg from that android side. Also run "cat /dev/ttyGS0" on that android before you restart your chromebook. Kyösti

2 1

Re: [coreboot] High demand for CLI payload: Use GRUB 2?
by David Hendricks Jan. 24, 2014

Jan. 24, 2014

On Thu, Jan 23, 2014 at 6:10 PM, David Hendricks <dhendrix(a)google.com>wrote: > I missed the discussion on IRC. But FWIW, I have been working on making a > small initramfs image consisting of busybox and a few handy tools > (flashrom, iotools, pciutils, usbutils, networking support, etc). I hope to > polish it up in the not-too-distant future and make it easy to build in the > ChromiumOS SDK (Portage-based). If you're interested to try out a snapshot > I have put one up here (built for i386): http://goo.gl/a2kwE0 . > Oops, I didn't tar that one up properly. I'll just keep a shared folder here for better tracking: http://goo.gl/yNLZGC -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

1 0

Re: [coreboot] High demand for CLI payload: Use GRUB 2?
by mrnuke Jan. 24, 2014

Jan. 24, 2014

On Thursday, January 23, 2014 06:10:39 PM David Hendricks wrote: > I missed the discussion on IRC. But FWIW, I have been working on making a > small initramfs image consisting of busybox and a few handy tools > (flashrom, iotools, pciutils, usbutils, networking support, etc). I hope to > polish it up in the not-too-distant future and make it easy to build in the > ChromiumOS SDK (Portage-based). If you're interested to try out a snapshot > I have put one up here (built for i386): http://goo.gl/a2kwE0 . > >[...] > > Perhaps we can call this LinuxBIOS :-) Who provides the BIOS services? :) Alex

1 0

High demand for CLI payload: Use GRUB 2?
by Paul Menzel Jan. 24, 2014

Jan. 24, 2014

Dear coreboot folks, in the coreboot IRC channel it was mentioned that a lot of vendors want to have a CLI (command line interface) payload. To get that they even used U-Boot as a payload. Though nobody understand the reason for this demand, the common opinion was to just give in and provide a solution for their problem. As getting a CLI payload with for example auto-completion, help texts and so on is tiresome and probably takes some work, I wonder why GRUB 2 is not a suitable solution? It’s very modular and thanks to Vladimir works very well as a payload for some time now. Though normally a menu is shown, you can drop into the command line and have a lot of commands depending on the modules you built. Could people in contact with the vendors please tell us, what the requirements from the vendors are? Do you also know if GRUB 2 does not fulfill one of these requirements? Thanks, Paul

4 3

Re: [coreboot] Chromebox debugging.
by Kyösti Mälkki Jan. 23, 2014

Jan. 23, 2014

On 01/20/2014 01:42 PM, Timothy Potter wrote: > On Sat, Jan 18, 2014 at 12:52 AM, John Lewis wrote: >> >> On 17/01/14 11:01, Timothy Potter wrote: >>> I've >>> also got an old Android phone with the ECHI debug gadget compiled into >>> the kernel. I've tried connecting that to every USB port on the >>> Chromebox but never get any output. >>> >> Hi Tim, >> Have you got "USB 2.0 EHCI debug dongle support" compiled on the >> coreboot side? If so, did you select "NET20DC and compatible" or >> "BeagleBone"? >> >> What kernel is the phone running? I assume because you have the EHCI >> debug gadget complied in the Android gadget is not? How does your phone >> react to the missing Android gadget? >> >> > Hi John, > I had a bit of time to review what how I'd set things up this weekend. > Yes. I compiled the debug dongle support into Coreboot, and left the > default 'NET20DC and compatible' selected. > On the phone side. Yes, the EHCI debug gadget replaces the Android > gadget, so the phone won't even charge while booted, but otherwise seems to > work as normal minus USB functionality. The kernel is version 2.6.32. I > suspect the problem is on the phone side as the phone doesn't show up in > the output of lsusb when connected to a Linux box. > I saw your video with the BeagleBone and HP laptop. Thanks for making > it. Good to see how things should work. > > Tim. Hi Tim That kernel is missing some bits from USB gadget framework. The oldest we have some result for is 2.6.35 and even that requires some backported patches. We have this linked at bottom of coreboot EHCI gadget wiki: https://github.com/buglabs/bug20-2.6.35-linaro/commits/master Kyösti

2 1

Latest SeaBIOS on Acer c720
by Kevin O'Connor Jan. 23, 2014

Jan. 23, 2014

This is a quick status update on my attempts to run the latest SeaBIOS on the Acer c720 chromebook (aka Google peppy). In brief, the latest SeaBIOS runs well on the c720, and it also enables booting from SD cards (which oddly doesn't seem to work in the version of seabios shipped with the c720). At this point, I've only upgrading SeaBIOS. I haven't updated the version of coreboot in the c720. For those interested in reproducing, it will require the very latest seabios from the git repo. Because only a small portion of the flash is used for seabios and that portion is in a non-standard location, the new seabios CONFIG_CBFS_LOCATION config option needs to be set to 0xffe00000 and some additional steps are needed to build the final rom. I've attached a script with the steps I run to build and install seabios for the c720 (based on instructions from Stefan Reinauer). In some initial tests, I can install and run Fedora on the c720, but there are some quirks. Suspend/resume is quirky (very slow to resume), the touchpad isn't working (needs a driver), and the keyboard mappings seem to be a little quirky. I don't think this is seabios related though. Also, systems using syslinux for a boot loader don't like the fact that the c720 reserves chunks of memory under 16Meg (which requires setting an explicit "mem=1600m" in the kernel boot parameters), however that doesn't seem to be a problem once the OS in installed (and no longer uses syslinux). The seabios xhci testing branch does detect the xhci controller. However, the current c720 boot code maps all the xhci devices to an ehci controller. I'm going to see if I can convince the boot code to map the devices back to the xhci controller so that I can test the seabios code on the Haswell xhci controller. -Kevin

1 0