coreboot February 2017

coreboot@coreboot.org

66 participants
212 discussions

Re: [coreboot] coreboot community meeting minutes for February 16, 2017
by Felix Held 17 Feb '17

17 Feb '17

Hi! > * coreboot is evaluating the idea switching from the mailing list to a > forum package. A poll on this will be posted shortly. > - Switch to reddit? > - Switch to google groups? > - Look for a forum software package that integrates well with the > mailing list. > - Skepticism was expressed about ditching the mailing list. I think dropping the mailing list for some forum would be a really bad idea. The mailing list is organized as a tree and most forums only support linear threads which get confusing very easily. Some forum with tree-structure (the code or reddit is open source, but i'm not sure how difficult it would be deploying an own installation of that) would be ok from that point, but i still see some possible problems in regard to archiving stuff there, since most of the data formats there will probably ways less portable than a mailing list archive. Regards Felix

2 1

Re: [coreboot] Support for BCM MX57QM
by Zoran Stojsavljevic 17 Feb '17

17 Feb '17

> The board is a Socket G1 board with a QM57 chipset, and it was running fine with an i7 620M before I bricked it > adding ucode for an i7 920XM. The BIOS looks to be a a Winbond 25Q64BVSIG 25/SPI (flashed with AMI). The Super > IO isIT8783F. Jesus Christ! How you were able to mix ucode of two complete different families of CORE CPUs? https://en.wikipedia.org/wiki/Arrandale [*i7 620M*] https://en.wikipedia.org/wiki/Clarksfield_(microprocessor) [*i7 920XM*] Man! :-( Zoran On Fri, Feb 17, 2017 at 5:28 PM, Ty Abonil <abonilts(a)hotmail.com> wrote: > Hello CB Community- > > > I recently aquired a BCM MX57QM board via ebay and bricked it trying to > update some microcodes. The board has an SPI header, so I was going to > pick up a programmer to try again, or restore to a supported ROM, and > thought that I might as well see if a coreboot build may work. > > > The board is a Socket G1 board with a QM57 chipset, and it was running > fine with an i7 620M before I bricked it adding ucode for an i7 920XM. > The BIOS looks to be a a Winbond 25Q64BVSIG 25/SPI (flashed with AMI). The > Super IO is IT8783F. > > > Tangentially, any tips on what programmer/cables to use would also be > appreciated. > > > Thanks in advance for any help. > > > > http://www.bcmcom.com/admin/Manual/MX57QM_Users_Manua_1.1.pdf > MX57QM - BCM Advanced Research > <http://www.bcmcom.com/admin/Manual/MX57QM_Users_Manua_1.1.pdf> > www.bcmcom.com > 1 MX57QM Intel® QM57 Mini ITX featuring latest two chips design, supports > Intel® Core™ i7, i5, i3 Arrandale Mobile processors, DDR3-800/1066 SODIMM > up to 8GB, > × > × > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] EHCI issue in APU3 (APU2) board
by Kamil Wcislo 17 Feb '17

17 Feb '17

Hi Thanks for the lead. Indeed, this was the cause. I've reversed the polarity and it works like a charm. It's really funny, that I haven't caught that on the schematics - probably turning blind ;). Thanks again! -- Best regards, Kamil Wcisło Embedded Systems Engineer http://3mdeb.com | @3mdeb_com On 02/17/2017 04:51 PM, Kyösti Mälkki wrote: > Hi > > I just had a quick look at the APU3a schema, looks like D+ D- lines on the J13 connector have switched places. > > Regards, > Kyösti > > > On Fri, Feb 17, 2017 at 5:31 PM, Kamil <kamil.wcislo(a)3mdeb.com <mailto:kamil.wcislo@3mdeb.com>> wrote: > > Hi everybody, > > We're trying to enable the USB on the J13 connector on APU3 board. It's using > the EHCI1 device (ports 0 to 3). As far as I understand it, USB controllers are > configured and set by the AGESA PI binary. I've tried with both versions of > AGESA - the one specific for pcengines boards (`3rdparty/blobs/mainboard/pcengines/apu2/AGESA.bin`) > and the latest one for this kind of chip (`3rdparty/blobs/pi/amd/00730F01/FT3b/AGESA.bin`). > Both versions deliver the same results. I've managed to use the latter version > by enabling all devices in `mainboard/pcengines/apu2/devicetree.cb`. > I'm using the master branch of coreboot, but also I've tried with some older > versions (same issue). > > We're working on mainlining all the changes needed for APU3 and one of them is > this USB header. It's unconnected and not used on APU2 boards, so disabled by > default. Besides that, shouldn't have more changes in this area. APU3 is similar > to APU2 board (the same SOC and design in general). The USB connections are on > page 6 on the schematics. > > My question is, what can we look for to investigate this issue further? Right > now we're out of options and we don't know what to do next. We would be grateful > for any insights on this matter. > > * Schematics for APU2 board: https://pcengines.ch/schema/apu2c.pdf <https://pcengines.ch/schema/apu2c.pdf> > * Schematics for APU3 board: https://pcengines.ch/schema/apu3a.pdf <https://pcengines.ch/schema/apu3a.pdf> > * Diff of my changes: http://pastebin.com/8YKkzB7Z > * Boot log: http://pastebin.com/uBAubrz9 > * PCI config space dumps: http://pastebin.com/3aBrt6wp > * lsusb dump: http://pastebin.com/V7NTWAnq > > -- > Best regards, > Kamil Wcisło > Embedded Systems Engineer > http://3mdeb.com | @3mdeb_com > >

1 0

Support for BCM MX57QM
by Ty Abonil 17 Feb '17

17 Feb '17

Hello CB Community- I recently aquired a BCM MX57QM board via ebay and bricked it trying to update some microcodes. The board has an SPI header, so I was going to pick up a programmer to try again, or restore to a supported ROM, and thought that I might as well see if a coreboot build may work. The board is a Socket G1 board with a QM57 chipset, and it was running fine with an i7 620M before I bricked it adding ucode for an i7 920XM. The BIOS looks to be a a Winbond 25Q64BVSIG 25/SPI (flashed with AMI). The Super IO is IT8783F. Tangentially, any tips on what programmer/cables to use would also be appreciated. Thanks in advance for any help. http://www.bcmcom.com/admin/Manual/MX57QM_Users_Manua_1.1.pdf MX57QM - BCM Advanced Research<http://www.bcmcom.com/admin/Manual/MX57QM_Users_Manua_1.1.pdf> www.bcmcom.com 1 MX57QM Intel® QM57 Mini ITX featuring latest two chips design, supports Intel® Core™ i7, i5, i3 Arrandale Mobile processors, DDR3-800/1066 SODIMM up to 8GB, × ×

1 0

EHCI issue in APU3 (APU2) board
by Kamil 17 Feb '17

17 Feb '17

Hi everybody, We're trying to enable the USB on the J13 connector on APU3 board. It's using the EHCI1 device (ports 0 to 3). As far as I understand it, USB controllers are configured and set by the AGESA PI binary. I've tried with both versions of AGESA - the one specific for pcengines boards (`3rdparty/blobs/mainboard/pcengines/apu2/AGESA.bin`) and the latest one for this kind of chip (`3rdparty/blobs/pi/amd/00730F01/FT3b/AGESA.bin`). Both versions deliver the same results. I've managed to use the latter version by enabling all devices in `mainboard/pcengines/apu2/devicetree.cb`. I'm using the master branch of coreboot, but also I've tried with some older versions (same issue). We're working on mainlining all the changes needed for APU3 and one of them is this USB header. It's unconnected and not used on APU2 boards, so disabled by default. Besides that, shouldn't have more changes in this area. APU3 is similar to APU2 board (the same SOC and design in general). The USB connections are on page 6 on the schematics. My question is, what can we look for to investigate this issue further? Right now we're out of options and we don't know what to do next. We would be grateful for any insights on this matter. * Schematics for APU2 board: https://pcengines.ch/schema/apu2c.pdf * Schematics for APU3 board: https://pcengines.ch/schema/apu3a.pdf * Diff of my changes: http://pastebin.com/8YKkzB7Z * Boot log: http://pastebin.com/uBAubrz9 * PCI config space dumps: http://pastebin.com/3aBrt6wp * lsusb dump: http://pastebin.com/V7NTWAnq -- Best regards, Kamil Wcisło Embedded Systems Engineer http://3mdeb.com | @3mdeb_com

2 1

Question about flashing only the bootblock
by Maxim Gusev 17 Feb '17

17 Feb '17

Hello! I am compiling some sourses. I have compiled bootblock and there is what I have: "OBJCOPY cbfs/fallback/bootblock.elf OBJCOPY bootblock.raw.bin" Now I want to see how the binary file works on the our hardware and debug it. But... The make file asks me to compile romstage... And I think ramstage will be: toolchain.inc:165: *** The toolchain architecture for romstage is unknown. toolchain.inc:165: *** Check your .config file for CONFIG_ARCH_romstage_* settings. Stop. (I have set the No parameters in Kconfig http://pastebin.com/vbAkdKtb for the romstage and ramstage of my arch). How to escape this step? How to programming the binary file only with bootblock? With Y parameters in the Kconfig file I have the same proplem: "make: *** No rule to make target `build/cbfs/fallback/romstage.elf', needed by `build/coreboot.pre'. Stop." Thank you a lot for helping! Regards, Maxim

1 0

Re: [coreboot] What payloads are easily usable with ARM targets?
by Zaolin 17 Feb '17

17 Feb '17

Moin. phcoder ported GRUB2 for ARM. ;) I don't know if there are any plans to publish it. Best Regards Zaolin On 02/17/2017 09:28 AM, Paul Menzel via coreboot wrote: > Dear coreboot folks, > > > What payload can be easily build and used for ARM targets? > > If you have any scripts, could you please share those? Maybe they can > be integrated into coreboot, so that there is also a default payload > available for ARM targets. > > Building GRUB resulted in a payload that is too big. I’ll try building > with a bigger ROM chip size for the target *QEMU armv7* later. > > > Thanks, > > Paul > >

1 0

Building working QEMU armv7 image with Debian toolchain
by Paul Menzel 17 Feb '17

17 Feb '17

Dear coreboot folks, Though not supported officially, I’d like to share, that I successfully built the board *QEMU armv7 (vexpress-a9)* with the Debian ARM toolchain from Debian Sid/unstable, and it worked with QEMU 2.8.0. ``` $ /usr/bin/arm-linux-gnueabi-gcc --version | head -1 arm-linux-gnueabi-gcc (Debian 6.3.0-5) 6.3.0 20170124 $ qemu-system-arm -version QEMU emulator version 2.8.0(Debian 1:2.8+dfsg-2) Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers ``` There are three crosscompilers for ARM in Debian. 1. gcc-arm-linux-gnueabi 2. gcc-arm-linux-gnueabihf 3. gcc-arm-none-eabi I wanted to install none-eabi, but just noticed, that by mistake installed the package *gcc-arm-linux-gnueabi*. (No idea if that matters for emulated boards like QEMU.) Which one should be correct? The crossgcc script, sets the line below. ``` util/crossgcc/Makefile: @$(MAKE) build_tools BUILD_PLATFORM=arm-eabi ``` Anyway, running the resulting coreboot image with no payload, works. ``` $ git log --oneline -1 231c198e2c mainboard/google/eve: Generate FPC device using SPI SSDT generator $ git describe --tag 4.5-991-g231c198e2c $ build/cbfstool build/coreboot.rom print Name Offset Type Size cbfs master header 0x0 cbfs header 32 fallback/romstage 0x80 stage 8964 fallback/ramstage 0x23c0 stage 17728 config 0x6940 raw 117 revision 0x6a00 raw 575 (empty) 0x6c80 null 4035096 header pointer 0x3dfec0 cbfs header 4 $ qemu-system-arm -machine vexpress-a9 -nographic -bios build/coreboot.rom pulseaudio: set_sink_input_volume() failed pulseaudio: Reason: Invalid argument pulseaudio: set_sink_input_mute() failed pulseaudio: Reason: Invalid argument coreboot-4.5-991-g231c198e2c Thu Feb 16 07:42:38 UTC 2017 bootblock starting... Exception handlers installed. CBFS @ 20100 size 3dff00 CBFS: 'Master Header Locator' located CBFS at [20100:400000) CBFS: Locating 'fallback/romstage' CBFS: Found @ offset 80 size 2304 coreboot-4.5-991-g231c198e2c Thu Feb 16 07:42:38 UTC 2017 romstage starting... CBFS @ 20100 size 3dff00 CBFS: 'Master Header Locator' located CBFS at [20100:400000) CBFS: Locating 'fallback/ramstage' CBFS: Found @ offset 23c0 size 4540 coreboot-4.5-991-g231c198e2c Thu Feb 16 07:42:38 UTC 2017 ramstage starting... Exception handlers installed. Enumerating buses... Show all devs... Before device enumeration. Root Device: enabled 1 I2C: 00:06: enabled 1 Compare with tree... Root Device: enabled 1 I2C: 00:06: enabled 1 Root Device scanning... root_dev_scan_bus for Root Device I2C: 00:06 enabled root_dev_scan_bus for Root Device done scan_bus: scanning of bus Root Device took 0 usecs done Allocating resources... Reading resources... Root Device read_resources bus 0 link: 0 I2C: 00:06 missing read_resources Root Device read_resources bus 0 link: 0 done Done reading resources. Show resources in subtree (Root Device)...After reading. Root Device child on link 0 I2C: 00:06 I2C: 00:06 Setting resources... Root Device assign_resources, bus 0 link: 0 Root Device assign_resources, bus 0 link: 0 Done setting resources. Show resources in subtree (Root Device)...After assigning values. Root Device child on link 0 I2C: 00:06 I2C: 00:06 Done allocating resources. Enabling resources... done. Initializing devices... Root Device init ... Devices initialized Show all devs... After init. Root Device: enabled 1 I2C: 00:06: enabled 1 Finalize devices... Devices finalized Could not add CBMEM for coreboot table. CBFS @ 20100 size 3dff00 CBFS: 'Master Header Locator' located CBFS at [20100:400000) CBFS: Locating 'fallback/payload' CBFS: 'fallback/payload' not found. Payload not loaded. ``` So, using the Debian toolchain seems to work quite fine for those wanting to save the time to build the coreboot toolchain. But keep in mind it’s currently not supported officially. The Debian toolchain also builds working images for the Lenovo X60 (Debian 8 (stable) with GCC 4.9.2) and the ASRock E350M1 (Debian 9 (unstable/sid) with GCC 6.3 (tested since GCC 4.9.2)). Thanks, Paul

1 0

How to enable ttyS0 on my board?
by 김유석 17 Feb '17

17 Feb '17

Dear Sir. My own board is based on ADI SG-2440. SG-2440 schematic is only connect(enable) the (UART1_RXD, UART1_TXD) to serial console port. So, only can use the "ttyS1" on kernel. But i want to use the "ttyS0". My board's schematic is a connect the uart0(UART0_RXD, UART0_TXD) and uart1(UART1_RXD, UART1_TXD) both. But message only out the the uart1. How can use/enable the uart0 on my board? What source code need a modify? Thank you.

1 0

Re: [coreboot] coreboot community meeting minutes for February 16, 2017
by Taiidan＠gmx.com 17 Feb '17

17 Feb '17

I am dumb so I wasn't aware that there was a community meeting. The mailinglist should stay, it is the most convenient and supported in a variety of viewing methods. Google groups and reddit both require javascript and they don't support easy text mode viewing - both should also not be used for philosophical reasons Reddit admins censor and stealth-edit user posts for kicks and political reasons and google loves to harvest peoples information - which is entirely their right to do (hardware/bandwidth isn't free - that's how they make money) but I don't like being shoehorned in to a service like that. I believe it is only a matter of time before google insist on something silly like requiring you to register an account with a phone number for using google groups, or demand that you do one of those browser fingerprinting mechanical turk captchas. I do not like freenode IRC as they discriminate against VPN users, even as they advertise VPN service on their home page. I can't understand why, considering you pretty much need a VPN with IRC unless you want someone to be able to easily escalate a petty disagreement in to being swatted and shot in the head. On 02/16/2017 06:41 PM, Martin Roth wrote: > Here are the meeting minutes of today's coreboot community meeting. > Info about the next meeting (March 2) is at the bottom. > > ################################################################## > > General coreboot news > * coreboot is working on joining the Software Freedom Conservancy in a > fiscal sponsorship agreement. Work on this is moving forward, and is > speeding up. Several announcements about this should be posted soon. > - Summary by Martin; there will be a blog post > - goal is April, or early May at the very latest > > Infrastructure Issues & News > * Updated coverity tools from 8.5.0.5 to 8.7.0 > - coreboot's coverity testing is run twice a week by Jenkins > - Tested projects: flashrom, ChromeEC, vboot, Memtest86+ > - All other projects are tested daily or when commits happen > * Having problems with merging users in gerrit - We plan to email people > with multiple existing accounts and merge them, but due to gerrit upgrades, > there are currently issues that we need to figure out before we can make > progress on this. > * Discussions on the current Mailing list vs switching to a forum > * coreboot is evaluating the idea switching from the mailing list to a > forum package. A poll on this will be posted shortly. > - Switch to reddit? > - Switch to google groups? > - Look for a forum software package that integrates well with the mailing > list. > - Skepticism was expressed about ditching the mailing list. > * Because jenkins builders build in tmpfs, memory was getting filled, and > builds were failing. We've taken steps to mitigate this. > * IRC/Mattermost > - Mattermost was set up to help make it easier for people who aren't > familiar with irc > - To reduce spam on irc, only allow registered nicks to talk? > - How big is the spam/abuse problem? > - Deprecate IRC channel? > - Not being planned right now, but in the future? > - Mattermost's default channel doesn't have irc bridged. It sounds like > the latest version of mattermost can add multiple default channels, so we > can add the irc channel as a default. > > Development > * Review of commits > - Martin has been busy and hasn't been able to review things as much > - The best way to get a quick review is to post in chat/irc asking for > reviews on specific patches. > - How do we get more people to review patches? > * Discussion *Add coreboot storage driver* > https://www.coreboot.org/pipermail/coreboot/2017-February/thread.html#83218 > - How will a decision on this be made? > - If we're going to come to any conclusion, the decision will probably > need to be made by Stefan. > > Interesting External news items > * Raptor engineering looking for support in porting openbmc for the ASUS > KGPE-D16 board - > http://www.phoronix.com/scan.php?page=news_item&px=KGPE-D16-OpenBMC-Effort > and https://firmwaresecurity.com/tag/coreboot/ > > coreboot community meeting related > * Attendance has been spotty. Is this worthwhile? > - Yes - The community meeting is useful to people > - Ten participants today \o/ > * Very few people actually add agenda items. > * Is the time the issue? Should we try switching time again? > * Announcing it on IRC (about one hour before it begins) helps > * We should announce it on the mailing list, the day before too > * Several people weren't aware that we had bi-weekly coreboot conference > meetings. > > > > ################################################################## > > Next meeting is March 2, 2017 > Check the coreboot calendar for the time in your timezone: > https://www.coreboot.org/calendar.html > > Join using the bluejeans web app or the phone bridge: > https://bluejeans.com/616384323 > > Phone bridge call in numbers: https://www.bluejeans.com/numbers > Meeting ID: 616384323 > > Current agenda & history: > https://coreboot-meeting.pads.ccc.de/CommunityMeetingTopics > > >

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
22
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot February 2017