coreboot March 2015

coreboot@coreboot.org

62 participants
166 discussions

Re: [coreboot] VGA doesn't work on Mohon Peak
by ron minnich 22 Mar '15

22 Mar '15

A good first pass is to enable YABEL instead of native execution and watch what it does. That's how I've had to debug graphics before. Also, if you can do a serial console only setup, you can run the VBIOS once linux is booted and try to debug it that way. It's very hard to debug a VBIOS issue as you are doing it now, however. It will take years off of your life :-) ron On Sun, Mar 22, 2015 at 9:07 AM Martin Roth <gaumless(a)gmail.com> wrote: > My experience is that the aspeed chip based graphics card that comes with > Mohon Peak has a bug in the vbios causing it to hang when run. If you need > to use this specific card, you'll need to debug it, probably with a jtag > debugger, going through the assembly, and see what's causing the issue. My > initial guess is that they're looking for some value in the bda or ebda > that isn't present, but I'm not sure what this might be. > > Martin > > On Sun, Mar 22, 2015 at 8:45 AM, Kevin O'Connor <kevin(a)koconnor.net> > wrote: > >> On Fri, Mar 20, 2015 at 12:30:38PM +0300, Kuzmichev Viktor wrote: >> > I tried not to include any VBIOS file in coreboot ROM much earlier, in >> my >> > first tests. With 'Run VGA Option ROMs' option checked the board just >> hung. >> > >> > And as I mentioned in my previous email VGA works fine with vendor's >> BIOS. >> > So the card itself should be fine. >> > >> > Sadly, I don't have another card to try. Even if I had, I still would >> need >> > to make this one work somehow as Mohon Peak is just a reference board >> and >> > the target board will have a similar VGA controller. >> > >> > So please, let me know if there are some other things I could try or if >> I am >> > mistaken somewhere. >> >> Hi Viktor, >> >> It seems you've tried a bunch of different configurations. However, >> this is making your trouble report hard to understand as it becomes >> unclear which config had which results. >> >> If you have an external VGA card, then please build coreboot with >> CONFIG_VGA_ROM_RUN, CONFIG_ON_DEVICE_ROM_RUN, CONFIG_VGA_BIOS, and >> CONFIG_PXE_ROM all disabled. Please use either the SeaBIOS provided >> by coreboot, or build SeaBIOS with a default config (only >> CONFIG_COREBOOT and if needed CONFIG_DEBUG_SERIAL changed from the >> seabios defaults). This is described at: >> http://www.coreboot.org/SeaBIOS >> >> In particular, there should be no "pciXXXX,YYYY.rom" or "vgaroms/XXX" >> files in your cbfs rom. >> >> If the above does not work, please use the above config and recompile >> SeaBIOS at debug level 8, and post the full debug log along with the >> output of "cbfstool print". >> >> Cheers, >> -Kevin >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot >> > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Query regarding gsoc project
by Marc Jones 21 Mar '15

21 Mar '15

Hi Kumar, Thanks for your interest in coreboot GSoC. I recommend that you focus on a small part of coreboot and become more familiar with how it works. You should get it booting in qemu. Having hardware to work on is important, so you should identify which hardware is most relevant to you and see what is supported and what support you would need to add. Regards, Marc On Sat, Mar 21, 2015 at 9:40 AM Kushagra Kumar <kushagra.nasa(a)gmail.com> wrote: > Respected sir, I am a computer engineering student.Sir I have been reading > all the available resources on the net about the firmwares and seriously I > am very upset at the present trend.Sir I am preparing one project using > coreboot but I have a doubt.Sir if I can understand all the working of > current uefi I will need my own hardware to implement it that is a bit > impractical... For now and for the hardware vendors to accept my proposal I > will need to propose a design better than uefi and make them believe > acctually it is better...which will take a long time so y don't we just get > a way in between these two and somehow try to reverse engineer the RAM > cryptography of uefi is it possible???will it help??? > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Query 2
by Kushagra Kumar 21 Mar '15

21 Mar '15

Do we need to do it without making the uefi mainframe aware...and we don't need to break the chain of trust or else I will lend up in a hash?

1 0

Query regarding gsoc project
by Kushagra Kumar 21 Mar '15

21 Mar '15

Respected sir, I am a computer engineering student.Sir I have been reading all the available resources on the net about the firmwares and seriously I am very upset at the present trend.Sir I am preparing one project using coreboot but I have a doubt.Sir if I can understand all the working of current uefi I will need my own hardware to implement it that is a bit impractical... For now and for the hardware vendors to accept my proposal I will need to propose a design better than uefi and make them believe acctually it is better...which will take a long time so y don't we just get a way in between these two and somehow try to reverse engineer the RAM cryptography of uefi is it possible???will it help???

1 0

Query regarding gsoc project
by Kushagra Kumar 21 Mar '15

21 Mar '15

1 0

Re: [coreboot] [coreboot-gerrit] Patch merged into coreboot/master: debc174 libpayload: arch/mips: add virt/bus/phy_to_bus/phy/virt operations
by Dylan Jeffers 21 Mar '15

21 Mar '15

Hi all, Is anyone attending the LibrePlanet 2105 conference this weekend? I'm a college student interested in getting involved in the coreboot project and I'd enjoy meeting some members if convenient. Thank you, Dylan On Mar 21, 2015 6:09 AM, <gerrit(a)coreboot.org> wrote: the following patch was just integrated into master: commit debc1744e185cc9edd09197dfd220bfbff2cdf1b Author: Ionela Voinescu <ionela.voinescu(a)imgtec.com> Date: Mon Feb 2 14:48:12 2015 +0000 libpayload: arch/mips: add virt/bus/phy_to_bus/phy/virt operations BUG=chrome-os-partner:31438 TEST=tested on Pistachio FPGA and bring up board; works as expected BRANCH=none Change-Id: I368494f388b82969dda0ce73a38824791efce616 Signed-off-by: Patrick Georgi <pgeorgi(a)chromium.org> Original-Commit-Id: e4c2bbcbdbcf706062724cffe2d5f15953468ace Original-Change-Id: Id5c9b1d65c6ec87f2aba06995dc940c50afb041f Original-Signed-off-by: Ionela Voinescu <ionela.voinescu(a)imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/245386 Original-Reviewed-by: David Hendricks <dhendrix(a)chromium.org> Reviewed-on: http://review.coreboot.org/8746 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Reviewed-by: Paul Menzel <paulepanter(a)users.sourceforge.net> See http://review.coreboot.org/8746 for details. -gerrit -- coreboot-gerrit mailing list: coreboot-gerrit(a)coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot-gerrit

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 21 Mar '15

21 Mar '15

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 39 new defect(s) introduced to coreboot found with Coverity Scan. 2 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 20 of 39 defect(s) ** CID 1229667: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/northbridge/amd/amdk8/northbridge.c: 1083 in amdk8_domain_set_resources() ________________________________________________________________________________________________________ *** CID 1229667: Integer handling issues (OVERFLOW_BEFORE_WIDEN) /src/northbridge/amd/amdk8/northbridge.c: 1083 in amdk8_domain_set_resources() 1077 pre_sizek = mmio_basek - basek; 1078 if(pre_sizek>0) { 1079 ram_resource(dev, (idx | i), basek, pre_sizek); 1080 idx += 0x10; 1081 sizek -= pre_sizek; 1082 if (!ramtop) >>> CID 1229667: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> Potentially overflowing expression "mmio_basek * 1024UL" with type "unsigned long" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "u64" (64 bits, unsigned). 1083 ramtop = mmio_basek * 1024; 1084 } 1085 #if CONFIG_HW_MEM_HOLE_SIZEK != 0 1086 if(reset_memhole) 1087 #if !CONFIG_K8_REV_F_SUPPORT 1088 if(!is_cpu_pre_e0() ) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/1016?tab=overview To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://scan.coverity.com/subscriptions/edit?email=coreboot%40coreboot.org&… .

1 0

Re: [coreboot] questions about google/samus
by Duncan Laurie 20 Mar '15

20 Mar '15

On Fri, Mar 20, 2015 at 2:04 PM, Andrzej Szeszo <aszeszo(a)gmail.com> wrote: > On 13 March 2015 at 00:59, Stefan Reinauer <stefan.reinauer(a)coreboot.org> > wrote: > > >> - Is the SSD soldered to the board? > > > > Yes. > > It would be nice to look at motherboard pictures. Does anyone know if > there are any online? > > I am particularly interested if the mPCIe slot is present like in the > older model. I think it would allow adding some extra internal USB > storage which would make it a really nice general purpose coreboot > laptop :) > > http://i.imgur.com/dqOIc0k.jpg There is an unstuffed M.2 header at the bottom of the board (with USB2 only) in that picture, under the Type-C flex cable and next to the SD card. I do not know if there are any related components that would also be needed to make that header functional. -duncan

1 0

questions about google/samus
by Anthony Martin 20 Mar '15

20 Mar '15

Hi, I have a few questions about the samus device and I figure this is the best place to ask. - Does it use the usual depthcharge payload with an internal write-protect switch for flashing the firmware? There's no boot guard shenanigans going on, correct? - It looks like the gigabit ethernet device is disabled in the device tree but are there pins or pads on the board to get to it? - Can someone describe the keyboard in comparison to, say, an older Macbook Pro, a Thinkpad X230 or X240, and the Toshiba Chromebook 2? What is the key travel distance like? - Is the display panel IPS or TN? - Is the SSD soldered to the board? - Could this be the coreboot laptop we've all been waiting for? :) Thanks, Anthony

5 4

Re: [coreboot] 0xE0000/0xF0000 segment issue
by Naresh G. Solanki 20 Mar '15

20 Mar '15

As per reply from seabios mailing list, the address range 0xE0000 to 0x10_0000 should have read write access and that can be done with help of some magic bit. Does anyone knows about these magic bits. The processor I'm working with is atom e6xx. -N Solanki On 20 Mar 2015 19:24, "WANG FEI" <wangfei.jimei(a)gmail.com> wrote: > I'm curious why your seabios payload is loading to shadow RAM (C/D/E/F000 > segment), this area suppose to be used by seabios, I guess since seabios is > a legacy BIOS. My suggestion is to load your seabios to a over 1MB address. > > On Thu, Mar 19, 2015 at 2:38 PM, Naresh G. Solanki < > naresh.solanki.2011(a)gmail.com> wrote: > >> Hi All, >> >> >> I'm trying to port coreboot with seabios payload. >> Everything goes fine till the control is transferred to payload. >> >> Since payload is loaded between memory range 0xC_0000 - 0x10_0000. >> >> The problem I was facing was that the board was going to auto reboot mode >> while executing payload.. >> >> Once it reboot then I'm not able to control the processor through XDP >> until I manually do CPU reset. >> >> It keeps on rebooting once control is transferred to payload. >> >> >> To find out the cause I did detailed memory test & found out that the >> memory range 0xA0000 - 0xBFFFF & 0xE0000 - 0xFFFFF always reads 0xFF. >> >> since payload is loaded in the same region so before jmp_payload, I tried >> to read this region through XDP & found payload code exist. >> >> so I introduced wbinvd instruction just before jmp_payload & I found that >> the XDP started reading 0xFF in the memory range 0xE0000 - 0xFFFFF. >> >> Thus from this I conclude that before the payload was able to execute >> because of cached copy of it in CPU cache & it didn't really existed in RAM. >> >> Also to enable memory range 0xE_0000 to 0xF_FFFF I have followed the >> guidlines as per table 15 of the document >> >> http://www.intel.com/content/www/us/en/intelligent-systems/queens-bay/atom-… >> >> Is that OK. >> What I can do to successfully enable the memory range 0xE_0000 to >> 0xF_FFFF for read write operation so that my payload execution goes >> undisturbed. >> >> My ultimate aim is to load Windows by Seabios as payload. >> >> Thanks >> N Solanki >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot >> > >

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
17
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 March 2015