[coreboot] Problem with USB keyboard
Hi, I'm begin with coreboot and seaBIOS. I have the problem with USB keyboard and mouse. When I boot the firmware my keyboard and mouse don't work. I use : coreboot, payload seaBios, MinnowMax board Problem: What I need to do for correct a firmware? Best regards, *Anteja * -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot community chat
Hi Stefan, thanks for organizing this! I think it's a really good idea. On 07.05.2015 06:05, Stefan Reinauer wrote: Hi coreboot community! In order to have more face time and a more personal connection with each other than it is possible on the coreboot IRC channel, I would like to invite you to participate in a monthly video conference to discuss the up and coming projects, ideas and issues that all of us are involved in. [...] So I would like to invite interested contributors of the community to join us. The first video conference will be on Thursday, May 21th at 9:15am Pacific Time (16:15 UTC). The meeting can be joined by clicking on this link: http://goo.gl/SD6t3G. I am very much looking forward to this and will try to participate. Regards, Carl-Daniel -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Soft-Reset when enabling resources on Sun Ultra 40 M2
Hi, Sorry just a quick note, I need to go now. Usually it happens when resources assigned are wrong (like overlapping local APIC or the area ffe which is used to deliver IRQs. CHeck resource allocation. I assume your problem happens when you enable the bridge decoding. Thanks Rudolf -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Problem with USB keyboard and mouse
Hi, I'm begin with coreboot and seaBIOS. I have the problem with USB keyboard and mouse. When I boot the firmware my keyboard and mouse don't work. I use : coreboot, payload seaBios, MinnowMax board Problem: What I need to do for correct a firmware? Best regards, *Anteja Vuk - Maček * -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [poll] device_t
one counter-question: is romcc ever going away, or at least is the usage gong to change such that no code would ever use the uint32 version of device_t? If it's *never* going away then I think the change makes no sense. If romcc is going away, then I would favor the change. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [poll] device_t
* ron minnich rminn...@gmail.com [150507 21:35]: one counter-question: is romcc ever going away, or at least is the usage gong to change such that no code would ever use the uint32 version of device_t? If it's *never* going away then I think the change makes no sense. If romcc is going away, then I would favor the change. With our current bootblock concept, it is never going away on x86 (for bootblock usage) Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [poll] device_t
Since Edward started hijacking patches on gerrit to push his agenda of getting rid of device_t without prior discussion, I would like to start a poll on how people think about this, and maybe find reasons for why it might be a good idea. Edward wrote: The issue of 'device_t' has many heads. The primary issue I have here is that these patches introduce many more 'device_t' instances that make the job of sorting out which 'device_t' are 'uint32_t' and which are 'struct device *' significantly harder as this sort of thing progresses. If the author would just use 'struct device *' and there is (for some wrapped reasoning) a consensus to only use 'device_t' then it is trivial to go do 's/struct device * /device_t /g'. There is actually no reason needed here to use a opaque type which was invented to solve a particular issue however has now spilled over to becoming rampant though the tree. The reality here is that device_t was a concept used ever since coreboot v2 (LinuxBIOS v2 from 2003 actually) existed. It is indeed the use of struct device that has accidently spilled over. The reason this was done was to use the same driver code in romstage and ramstage. While this can be achieved by other means, no doubt, I don't think that this churn on the code base is particularly useful. Before we continue on this path I would like to see a reason for not using device_t or why the difference between the type has to be sorted out. The whole idea is that it does not matter, and the code does not have to know. Check out the poll at https://doodle.com/vvqtyhdxr9yhvqci Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [poll] device_t
2015-05-07 22:00 GMT+02:00 Stefan Reinauer stefan.reina...@coreboot.org: With our current bootblock concept, it is never going away on x86 (for bootblock usage) Which isn't that much of a problem once we provide separate headers for x86 bootblock code. There's really very tiny overlap. That could then be reused to deal with raminit on romcc-boards, too: from coreboot's point of view, raminit is just an overly large piece of cache-as-ram code, followed by a raminit noop. This is simplified by the lack of the need for development tools (eg printk) to develop new non-car x86 raminits. One of these days... 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@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] ASUS KFSN4-DRE Automated Test Failure
The ASUS KFSN4-DRE fails verification as of commit b2aee6f2e7c61ae87ddfdab00c22775313603981 The following tests failed: CBMEM_OBJECT_TABLE_TRUNCATED Commits since last successful test: b2aee6f vboot2: Replace hard coded 'fallback' prefix with Kconfig variable b4a6ca9 imgtec/pistachio: Add comment on the unusual memory layout c6e1f8a Add MAINTAINERS file 0ff13d9 Drop lbtdump, like it's 2007 7d89849 Drop dumpmcrr 35 commits skipped 2436bda cpu: get rid of socket source code 99cc1aa Mediawiki editing warning e9b7e25 util/xcompile/xcompile: Allow to override `HOSTCC` variable 939dc84 crossgcc: Re-download the archive if it is incomplete 6548ae9 cbfstool/Makefile*: Use `LDFLAGS` instead of `LINKFLAGS` See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE test stand Raptor Engineering offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information Please contact Timothy Pearson at Raptor Engineering tpear...@raptorengineeringinc.com regarding any issues stemming from this notification 1431003322-0-automaster.log.bz2 Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AGESA PI for Olivehill+
Hello Wolfgang, It is correct that you can't use this right away but the memory configurations can be made. We have done this for several FT3B SoC based boards. We can do this for your board as well. Please contact me off-line if you are interested. Best Regards, Wim Vervoorn Eltan B.V. Ambachtstraat 23 5481 SM Schijndel The Netherlands T : +31-(0)73-594 46 64 E : wvervo...@eltan.com W : http://www.eltan.com THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES. From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Wolfgang Kamp - datakamp Sent: Thursday, May 07, 2015 3:19 PM To: coreboot@coreboot.org Subject: [coreboot] AGESA PI for Olivehill+ Hi Bruce, is it right that the AGESA Pi binary for AMD Olivehill+ board is not usable for custom board implementations of FT3B GSOC? For example, if we use memory down design in star topology, AGESA will fail to initialize DDR3. Regards, Wolfgang -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] AGESA PI for Olivehill+
Hi Bruce, is it right that the AGESA Pi binary for AMD Olivehill+ board is not usable for custom board implementations of FT3B GSOC? For example, if we use memory down design in star topology, AGESA will fail to initialize DDR3. Regards, Wolfgang -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problem with USB keyboard
On 2015-05-07 11:25, Anteja Vuk-Maček wrote: Hi, I'm begin with coreboot and seaBIOS. I have the problem with USB keyboard and mouse. When I boot the firmware my keyboard and mouse don't work. I use : coreboot, payload seaBios, MinnowMax board Problem: What I need to do for correct a firmware? Best regards, _Anteja _ What version of Coreboot are you using? Version number should look something like 4.0-9612-g7aafe53. What version of the Intel FSP are you using(Gold3?)? I'm running GIT commit d93bd263b66d83fff4e22826e465aae8fac326df + the patch from the following review: http://review.coreboot.org/#/c/10100/2/src/drivers/intel/fsp1_0/fsp_util.c With my Apple USB keyboard connected to the USB 3.0 port I can enter the SeaBIOS boot menu and make a selection from there without a problem. That is on a dual core Minnowboard Max. Best regards, David -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AGESA PI for Olivehill+
On to, 2015-05-07 at 13:19 +, Wolfgang Kamp - datakamp wrote: Hi Bruce, is it right that the AGESA Pi binary for AMD Olivehill+ board is not usable for custom board implementations of FT3B GSOC? For example, if we use memory down design in star topology, AGESA will fail to initialize DDR3. Regards, Wolfgang I assume you have left out SPD eeproms from BOM, so have you already created and double-checked the SPD files? We have some boards in the tree doing that already. I hope to upstream DB-FT3b-LC board sources to coreboot.org, possibly next week. That may or may not help You further. Do you have PI build with raminit logging enabled? Regards, Kyösti -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
