[coreboot] Re: Status of maintained boards and policies?

Hi, For some reason I forgot to add coreboot@coreboot.org in Cc, so I'm forwarding the reply as well: Begin forwarded message: Date: Wed, 25 Jan 2023 00:32:39 +0100 From: Nico Huber To: Denis 'GNUtoo' Carikli Subject: Re: [coreboot] Re: Status of maintained boards and policies? Hi Denis

[coreboot] Re: Status of maintained boards and policies?

On Wed, 4 Jan 2023 21:00:43 +0100 Nico Huber wrote: > Hi Denis, Hi, > I've always estimated that it would take about $200k to get there for > any of the older AMD platforms (assuming you can get experienced core- > boot developers to do it). But once reasonable code for one platform > would be

[coreboot] Re: Status of maintained boards and policies?

On Wed, 4 Jan 2023 09:58:59 -0700 Nicholas Chin wrote: > > And given that there is no way to guarantee that a Mainboard doesn't > > get removed, we'd also need to watch what is happening with the GM45 > > Thinkpads as well, as this problem also affect these computers. > > Could you elaborate on

[coreboot] Re: Status of maintained boards and policies?

On Wed, 4 Jan 2023 04:37:01 +0100 (CET) Martin Roth wrote: > Hey Denis, My reply got out of control here.  Apologies for the > length, feel free to ignore the top and just skip to my replies.  :) I think that getting the background as well is important here. > Unfortunately, that's simply not

[coreboot] Re: Status of maintained boards and policies?

On Tue, 3 Jan 2023 18:38:02 +0100 (CET) Martin Roth wrote: > Hi Denis, >  - Responses inline Hi, Thanks for the answers. > Jan 2, 2023, 17:16 by gnu...@cyberdimension.org: > > > Hi, > > > > The MAINTAINERS file has the following: > > > >> PC ENGINES ALL MAINBOARDS > >> M: Piotr Król >

[coreboot] Status of maintained boards and policies?

Hi, The MAINTAINERS file has the following: > PC ENGINES ALL MAINBOARDS > M: Piotr Król > M: Michał Żygowski > S: Supported > F: src/mainboard/pcengines/ But the commit f9decbb0c720662d8e71fe221aef55b7ecf76196 ("mb/*/*: Remove AMD family14 boards") actually removed the apu1

[coreboot] Re: Optiplex 790 now has preliminary support by coreboot

On Wed, 11 Oct 2017 18:34:15 -0400 "taii...@gmx.com" wrote: > https://review.coreboot.org/21774 > In case anyone else didn't notice - It is a sandy/ivy system with > IOMMU. I happen to have an Optiplex 790, but it probably lacks many parts (RAM, storage, etc). > This is great and should help

[coreboot] Re: Comment on story about bootloader security?

On Mon, 9 Dec 2019 09:08:35 -0800 Seth Rosenblatt wrote: > I wasn't able to find the security@ alias, otherwise would've emailed > y'all there. I didn't hear back before publication but happy to make > any corrections if needed. I'm also willing to include a statement > from Coreboot if you want

[coreboot] Re: AMD AGESA board removals

On Tue, 10 Dec 2019 10:31:38 +0100 Nico Huber wrote: > Hi Denis, Hi, [f2a85m-pro] > Please re-check your bisect result, I'm sorry for having messed up here. Doing too much things at the same time didn't help (too much deadlines around the same date). I double checked everything this time.

[coreboot] Re: AMD AGESA board removals

On Mon, 9 Dec 2019 18:54:18 +0200 Kyösti Mälkki wrote: [f2a85m-pro broken on master] > Weird. Seems like I let the devicetree in a bit of a bad shape back > in 2015. Try if this makes any difference: > https://review.coreboot.org/c/coreboot/+/37619 I tried that through the normal/fallback

[coreboot] Re: AMD AGESA board removals

On Mon, 9 Dec 2019 02:20:29 +0200 Kyösti Mälkki wrote: [E350M1] > You want to rebase your changes on pcengines/apu1 transition [1] > which is the first fam14 board to drop ROMCC_BOOTBLOCK. > > [1] https://review.coreboot.org/c/coreboot/+/37332/11 I've done that, and after build it, flashing it

[coreboot] Re: AMD AGESA board removals

On Mon, 9 Dec 2019 02:20:29 +0200 Kyösti Mälkki wrote: > On Mon, Dec 9, 2019 at 1:53 AM Denis 'GNUtoo' Carikli > wrote: > > I've tried to do the same for the E350M1 and I end up with: > > > [...]/i386-elf-ld.bfd: build/bootblock/arch/x86/bootblock_crt0.o: > >

[coreboot] Re: AMD AGESA board removals

On Sun, 8 Dec 2019 18:49:26 +0200 Kyösti Mälkki wrote: > > - What to do if the board doesn't boot anymore with master > > (f2a85m-pro)? Should I bisect the issue first? Or would the > > conversion be able to fix the issue? > > Bisect first and return master to a working state please. There

[coreboot] Re: AMD AGESA board removals

_ram.S is selected by SOC_AMD_COMMON_BLOCK_CAR, which is only used in src/soc/amd/stoneyridge/Kconfig. I don't understand why the other boards converted to switch away from ROMCC_BOOTBLOCK don't have that issue. Denis. From 687f67f2645dbfae6af691a84ba5af6d672800d9 Mon Sep 17 00:00:00 2001 From: Denis 'GNUtoo' Carikli

[coreboot] Re: AMD AGESA board removals

On Tue, 3 Dec 2019 19:29:48 +0200 Kyösti Mälkki wrote: > Hi Hi, > The process begins by uploading a fresh board-status result for the > board you volunteer to work on and announce this by replying to this > thread. I've done that for asrock/e350m1. Denis. pgpbZA2lwCd7F.pgp Description:

[coreboot] Re: AMD AGESA board removals

On Tue, 3 Dec 2019 19:29:48 +0200 Kyösti Mälkki wrote: > Hi Hi, > Regarding the deprecation of AGESA platforms due to ROMCC_BOOTBLOCK. > > As of 3rd December there is active development, while not much testing > yet, only for the following AGESA platform boards: > > * asrock/imb-a180 > *

[coreboot] Re: Ifdtool for modifying IFD 2.0?

On Wed, 16 Oct 2019 17:32:31 -0700 Rafael Send wrote: > Hi, > I'm trying to make some adjustments to my descriptor. > > The -D switch results in an error which goes something like "Density > modifications to IFD 2.0 not supported yet". > > Is there a version of the tool (or a different tool)

[coreboot] Re: Basic hardware documentation

On Thu, 10 Oct 2019 16:00:53 -0300 Rafael Machado wrote: > Hi Denis > > Are talking about this: > https://lennartb.home.xs4all.nl/coreboot/coreboot.html Yes. Thanks. Denis. pgpQcQjt3OcXq.pgp Description: OpenPGP digital signature ___ coreboot

[coreboot] Lenovo G505s to give for working on it

Hi, I was given a Lenovo G505s, but I would probably not have time to work on finishing to replace the nonfree software that is still needed for it. I was also given the opportunity to ship it to people interested in working on it. I've not looked into which exact hardware configuration it has,

[coreboot] Re: Basic hardware documentation

On Mon, 7 Oct 2019 11:52:44 +0200 Christoph Pomaska via coreboot wrote: > Hi, Hi, > I had the idea of contributing basic information about hardware > components to the coreboot documentation > in the style of "What is Super I/O?" and similar. > > What do other people think of that? I vaguely

[coreboot] Re: RAM init failing with some DIMMs on GM45 with "Timing overflow during read training."

On Tue, 17 Sep 2019 10:21:38 +0200 Nico Huber wrote: > Hi Denis, Hi, > >> Raw card type:D Is there more information on such "card type" somewhere? Is there a way to avoid buying such "card type"? > last time we encountered problems with type D DIMMs, we concluded that > it's not supposed

[coreboot] Boot loop on Thinkpad X200/GM45 with master.

Hi, I've a reboot loop on master on the Thinkpad X200. It's configured to run without the Management Engine firmware (which is not present on the flash chip). Here's the boot log: > coreboot-4.10-678-gdd12d53494b-dirty Mon Sep 16 13:42:10 UTC 2019 > romstage starting (log level: 8)... WARNING:

[coreboot] RAM init failing with some DIMMs on GM45 with "Timing overflow during read training."

Hi, I've bought two 4G DIMMs with the following characteristics: - Vendor: Corsair - Model: MACMEMORY - Markings: CMSA4GX3M1A1066C7 DDR3 - Chips markings: Corsair 256MB8DCJG HYE0001924 On a Thinkpad X200 with coreboot master, it gives me the following log: >

[coreboot] Re: Does NSA contribute to Coreboot?

On Mon, 24 Jun 2019 08:17:14 -0700 ron minnich wrote: > We're reviewing the STM code, of course. If you're going to worry > about something, worry about FSP 2.0 still being closed source. FSP is > not optional and we have no idea of all the things it does/can do. Not only that. For people that

Re: [coreboot] Lenovo G505S - spkmodem console sound, is correct? Please listen and tell

On Thu, 27 Sep 2018 22:36:47 + Peter Stuge wrote: > I tried decoding, resampling and normalizing the ogg file without > success so I suggest increasing amplitude at the source; move the mic > closer to the speaker and use the parecord | spkmodem-recv command as > documented in

Re: [coreboot] USB 2.0 EHCI debug dongle doesn't print logs (at Lenovo G505S)

On Sat, 29 Sep 2018 00:50:18 +0300 Ivan Ivanov wrote: > Thank you for spkmodem comments, now I'm trying out a more reliable > way - FT232H dongle - to extract the logs from AMD Lenovo G505S. [...] If the usb debug dongle you could also try adding grub as a payload and launching it from SeaBIOS.

Re: [coreboot] [URGENT] - The KCMA-D8 is going to be removed from coreboot unless people cough up a board status update

Hi, On Wed, 4 Apr 2018 18:36:56 -0400 "taii...@gmx.com" wrote: > This is a great board that many use and it DOES work - it needs a > status update ASAP to prevent it from being removed in the next > release. Is there more details on the policy? For instance how can I know in

[coreboot] Disabling ME >= 6.0 < 11 via the AltMeDisable bit

Hi, As I understand it: - For ME < 6.0, the ME firmware can be removed totally, and still have a functional computer. - For ME >= 6.0 (Nehalem) to ME < 11 (Broadwell), the All ME firmware can't be totally removed: the BUP module is required to have a functional computer. For such

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

On Thu, 14 Dec 2017 20:25:53 -0500 Youness Alaoui wrote: > In my opinion, the ME is indeed disabled because the entire ME > functionality is disabled, no ME processes are running, and the kernel > on its own is irrelevant, even if it keeps running. > However, I

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

On Fri, 8 Dec 2017 21:34:57 +0100 (CET) eche...@free.fr wrote: > For those who are interested in the Intel ME, the slides and white > papers > from the Black Hat Europe are public. > >

Re: [coreboot] Is Goryachy's JTAG hack a chance for free firmware ?

On Wed, 29 Nov 2017 23:39:27 +0100 "Enrico Weigelt, metux IT consult" wrote: > Hi folks, > > i'm curios whether Goryachy's JTAG hack is a chance for > getting rid of all proprietary ME/UEFI firmware. > > If i'm correct, the ME firmware (or parts of it) is signed, and > the CPU

Re: [coreboot] Hardware vendors offering systems with Intel ME disabled

Hi, On Thu, 7 Dec 2017 22:29:44 +0100 (CET) eche...@free.fr wrote: > [...] to this new initiative of Dell or System76?.. For Intel devices with chipsets more recent than the GM45, so far I know only the following manufacturers that "disables" the Management Engine: - Puri.sm which enables the HAP

Re: [coreboot] Hardware vendors offering systems with Intel ME disabled

On Thu, 07 Dec 2017 16:22:48 -0600 Timothy Pearson wrote: > While dell has not gone into detail on this offering, from what has > been described it is highly likely that they were setting the HAP bit. I would guess that too, especially since Dell was already part

[coreboot] Gerrit: Can't abandon patch

Hi, In the (javascript) web interface, I find no way to abandon a change. Through ssh I can't either: > $ ssh review.coreboot.org gerrit review --abandon 15072,1 > error: fatal: abandon not permitted > > fatal: one or more reviews failed; review output above 15072 is supposed to be the

Re: [coreboot] Easier accessibility for coreboot/flashrom wikipedias? What do you think?

On Fri, 19 May 2017 11:20:27 +0300 qma ster wrote: > Dear coreboot/flashrom mailing list members, Hi, > As you may have noticed it is not that easy or straightforward to > gain the edit rights for coreboot/flashrom wikipedias so the people > are mass migrating to the

Re: [coreboot] Intel ME The Way of the Static Analysis

On Tue, 25 Apr 2017 22:38:15 +0800 Shawn wrote: > slide: > https://www.troopers.de/downloads/troopers17/TR17_ME11_Static.pdf > > video: > https://www.youtube.com/watch?v=2_aokrfcoUk > Thanks a lot! This is very interesting. I probably missed something about the ROM bypass:

Re: [coreboot] Coreboot gamers?

On Sun, 2 Apr 2017 16:05:42 -0400 "taii...@gmx.com" wrote: > Hey any other coreboot gamers? Hi, > What are your specs, games do you play > and on what settings? I don't play often, and some of the times, it's to test if the GPU still works fine. I only play free software

Re: [coreboot] References to ich9gen in the wiki (was: Re: Fwd: Ethernet problem in x200)

Nico Huber wrote: > >> Pew, thanks for reminding me, that we have this in our wiki. [...] > Sorry, this was badly articulated. The "thanks" was meant sincere. There was indeed some missunderstanding from both sides, I'm happy that it's fixed and we can now understand each

Re: [coreboot] Fwd: Ethernet problem in x200

On Tue, 28 Mar 2017 19:05:15 +0200 Nico Huber wrote: [...] > > (3) Having a boot firmware without the management engine firmware. > > > > It is strongly advised to do (3) and follow the corresponding > > coreboot documentation. > > Strongly advised by who? In which scenario?

Re: [coreboot] [PATCH] nb/intel/nehalem/raminit.c: Add timeouts when waiting for heci.

On Mon, 27 Mar 2017 14:33:23 -0700 Andrey Petrov <andrey.pet...@intel.com> wrote: > Hi, > > On 03/27/2017 01:05 PM, Denis 'GNUtoo' Carikli wrote: > > Since until now, the code running on the management engine is: > > - Signed by its manufacturer > > - Proprietar

Re: [coreboot] [PATCH] nb/intel/nehalem/raminit.c: Add timeouts when waiting for heci.

On Mon, 27 Mar 2017 15:19:17 -0500 Timothy Pearson wrote: > In general static timeouts are not a good idea. Is there a reliable > way for coreboot to determine if the ME image has been > "cleaned" (i.e. can it parse the ME descriptor and not even search > for the

Re: [coreboot] Fwd: Ethernet problem in x200

On Mon, 27 Mar 2017 16:14:53 +0200 Zoran Stojsavljevic wrote: > [user@localhost projects]$ cat dmesg.txt | grep 00:19.0 > [0.151652] pci :00:19.0: *[8086:294c*] type 00 class 0x02 > [0.151694] pci :00:19.0: reg 0x10: [mem 0xe160-0xe161]

[coreboot] [PATCH] nb/intel/nehalem/raminit.c: Add timeouts when waiting for heci.

Signed-off-by: Denis 'GNUtoo' Carikli <gnu...@no-log.org> --- src/northbridge/intel/nehalem/raminit.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/src/northbridge/intel/nehalem/raminit.c b/src/northbridge/intel/nehalem/raminit.c index 122b8ac7cf..2706

Re: [coreboot] Lenovo Thinkpad X201: Coreboot incompatible with me_cleaner

On Tue, 21 Mar 2017 14:19:18 + Sam Kuper wrote: > Dear all, Hi, > Nicola Corna pointed out to me that adding a timeout at > https://github.com/coreboot/coreboot/blob/master/src/northbridge/intel/nehalem/raminit.c#L1756 > might solve this problem. > > (I guess the

Re: [coreboot] Lenovo Thinkpad X201: cannot boot encrypted Debian w/Coreboot & GRUB2

On Fri, 24 Mar 2017 03:16:27 + Sam Kuper wrote: > GNUtoo in 2013: > https://www.coreboot.org/index.php?title=Board:lenovo/x201=prev=11609 > > GNUtoo in 2013: > https://www.coreboot.org/index.php?title=Board:lenovo/x201=prev=11614 > > phcoder in 2013: >

Re: [coreboot] Lenovo Thinkpad X201: cannot boot encrypted Debian w/Coreboot & GRUB2

On Wed, 22 Mar 2017 16:03:28 + Sam Kuper wrote: > Is my interpretation plausible? In any case, how would more > experienced Corebooters suggest I proceed? Here's my configuration for the I945 and GM45 thinkpads. It probably will not help you to find and/or fix the

Re: [coreboot] [Resend] Tapping into the core (33C3)

On Tue, 17 Jan 2017 11:11:38 + Maxim Goryachy wrote: [...] > If I understand correctly, when DCI is disabled in the flash > descriptor, such attacks are not possible and the computer is safe. > > Unfortunately no, DCI can be activated through P2SB device at any >

[coreboot] Liberating people and beyond x86 Was: [Resend] Tapping into the core (33C3)

On Mon, 16 Jan 2017 16:34:06 -0500 "taii...@gmx.com" wrote: > Bootguard can be bypassed by simply swapping compatible CPU's from > two computers/laptops, correct? AFAIK, on many laptops the CPU is soldered now. Since such CPU are probably BGA, I don't see it as a viable option

[coreboot] [Resend] Tapping into the core (33C3)

Hi, I saw your presentation "Tapping into the core"[1] that you gave at the last CCC. As I understand from the slides DCI can be activated trough: - The flash descriptor - UEFI - The P2SB register Are skylake platform safe if: - DCI is disabled in the flash descriptor. - DCI is not activated by

Re: [coreboot] [GSOC 2016] Coreboot panic room

On Thu, 10 Mar 2016 22:34:45 + Antonello Dettori wrote: > Hello everyone, Hi, > I would like to concentrate most of my efforts towards improving and > upstreaming the previous efforts, implementing a way to easily access > the recovery mode when needed and further the

Re: [coreboot] Logs storage? Was: Target candidate: Dell Latitude E4300

On Thu, 17 Mar 2016 15:27:56 -0600 Martin Roth wrote: > I think that having OEM BIOS logs from supported boards does make a > lot of sense, but when I talked to Stefan about it before, he didn't > want to add unsupported boards. His thinking was that we didn't want > to be

[coreboot] How to repair Pomona clips, Was: Good source for SOIC clips

On Sat, 19 Mar 2016 20:19:00 +0100 thomasg wrote: > These are certainly much cheaper than the expensive ones available in > the "west" - though I don't know if the quality is adequate. > Should you order some it would probably be interesting to give > feedback on that.

Re: [coreboot] [GSoC 2016] ROM-O-Matic project

On Wed, 09 Mar 2016 04:24:04 + ron minnich wrote: > yeah, we had something like this in the linuxbios days. I think you > don't want to build it on demand, but rather have a bunch of > pre-built images that are known good. Once we get reproducible builds, we could: 1)

Re: [coreboot] [GSoC 2016] ROM-O-Matic project

On Thu, 17 Mar 2016 15:56:13 -0600 Martin Roth wrote: > As the project proposal says, first we want to just build roms that > are already present in the board status database. We have a config > already present for these, so we don't need to ask any configuration > options

[coreboot] Logs storage? Was: Target candidate: Dell Latitude E4300

On Tue, 1 Mar 2016 06:51:37 +0800 persmule wrote: > [dell_e4300_bios_flashrom.log text/x-log (42687 bytes)] > [dell_e4300_bios.layout text/plain (135 bytes)] Hi, What do you think about storing devices's log obtained while running the stock boot firmware somewhere? Before

Re: [coreboot] tpm api merge

On Wed, 9 Mar 2016 23:55:03 +0100 Alexander Couzens wrote: > So the question how can we merge this? As long we don't have further > testing, it's hard to decide. We won't catch all bugs. May be > chromeos have a tpm testing? How do you test a TPM? Would dumping its PCR sufficent?

Re: [coreboot] Introduction

On Tue, 8 Mar 2016 22:13:47 + David Parreira wrote: > Do you have a specifical project that you want to work on? > Should I propose a project? Beside hardware ports, work on related projects (payloads), there is also a list of infrastructure projects here:

[coreboot] A proposal against irreversible code signing.

Hi, Coreboot, Replicant, and other communities have some trouble with signed bootloaders/BIOS/UEFI. So would the following make sense? Here the goal is to have boot integrity while still protecting the user's freedom to modify all the software running on their hardware. The implementation

Re: [coreboot] Removed boards list.

On Tue, 9 Feb 2016 09:47:08 +0100 Patrick Georgi via coreboot wrote: > > Would it be possible to get such page updated (for instance by the > > commit author) when the commit has been pushed to master? > Maybe the board-status to wiki tool should check multiple versions

Re: [coreboot] Removed boards list.

On Tue, 9 Feb 2016 09:47:08 +0100 Patrick Georgi wrote: [...] > > Would it be possible to get such page updated (for instance by the > > commit author) when the commit has been pushed to master? > Maybe the board-status to wiki tool should check multiple versions of > the

[coreboot] Removed boards list.

Hi, When boards are removed, they are also automatically removed from the supported boards page[1] in the wiki. The unfortunate downside is that, assuming that coreboot worked fine on such boards in the past (and may still do), they don't show up in any list. A place where to put the list of

[coreboot] Thinkpad ECs (H8)

Hi, I just learned about (and watched) a presentation[1] that is about backdooring the Thinkpad ECs. This information might help with the task of writing a free software EC firmware[2]. The information is also very useful to get a better ideas of the threats due to having a non-free EC

[coreboot] Secure boot(against evil-maids) on Lenovo i945 laptops.

Hi, Use case: - Usually when people do full disk encryption, it's not really full disk, instead they still have a /boot in clear. So an evil maid attack can still be done, in two passes: 1) Clone the hdd, Infect the initramfs or the kernel. 2) Wait for the user to enter its password,

Re: [coreboot] X60: ethernet LED still on when machine is powered off or suspended

On Thu, 21 Aug 2014 15:41:02 -0700 ron minnich rminn...@gmail.com wrote: On Thu, Aug 21, 2014 at 2:10 PM, The Gluglug i...@gluglug.org.uk wrote: [...] On 21/08/14 22:08, The Gluglug wrote: A little quirk I noticed. If I put the machine in suspend while an ethernet cable is plugged in to a

Re: [coreboot] X60: ethernet LED still on when machine is powered off or suspended

On Fri, 22 Aug 2014 02:22:01 +0100 The Gluglug i...@gluglug.org.uk wrote: Haven't tried it on factory.bin. Will let you know. i945 doesn't have ME/AMT, as far as I know. I remember reading about such things in intel datasheets. I remember (very vaguely) reading about the fact that i945 can

Re: [coreboot] Success in replicating a fast boot time to the browser on a x60

On Wed, 2 Jul 2014 10:23:45 -0400 Charles Devereaux coreb...@guylhem.net wrote: Hello Hi, If anyone is interested, I could successfully replicate a similar boot time on a debian wheezy, with a modern coreboot chain loading to grub2, on a x60 tablet running at 1.66 GHz with a cheap SSD :

Re: [coreboot] bug YT as EHCI gadget for coreboot

On Fri, 05 Sep 2014 09:14:12 +0100 John Lewis jle...@johnlewis.ie wrote: On 05/09/14 07:17, Denis 'GNUtoo' Carikli wrote: 4. Use your rasberry and try to make g_dbgp work there, to test use the linux kernel with earlyprintk=dbgp. Note that earlyprintk=dbgp doesn't work out of the box

Re: [coreboot] bug YT as EHCI gadget for coreboot

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 03 Sep 2014 16:43:36 +0200 Marek Doležel xdole...@stud.feec.vutbr.cz wrote: Hello, I noticed you are in connection with buglabs community. I couldn't find any option to buy this device. I guess the device is developed only for Big

Re: [coreboot] Help for Coreboot project

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 10 Jul 2014 23:07:27 +0200 Rudolf Marek r.ma...@assembler.cz wrote: Hi Антон I think this could be used to develop something like native radeon video init. Yes, It can work: on my m4a785t-m, long time ago, The kernel could init the GPU,

Re: [coreboot] Help for Coreboot project

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 10 Jul 2014 23:07:27 +0200 Rudolf Marek r.ma...@assembler.cz wrote: Hi Антон I think this could be used to develop something like native radeon video init. Perhaps similar approach was used by ron co develop native intel video init.

Re: [coreboot] ISP header for x60, fallback: indicating normal boot from grub2

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 7 Jul 2014 20:56:12 -0400 Charles Devereaux coreb...@guylhem.net wrote: Problem is my pomona is not establishing reliable connections, unless I use a lot of duct tape. I'd be interested in using the ISP header if possible. My pomona clip

[coreboot] MMCONF (again) issues on Fam 10H

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, The fact that my M4A785T-M got unusable with master pushed me to retest that patch: 23:58 PaulePanter GNUtoo-irssi: git fetch http://review.coreboot.org/coreboot refs/changes/41/4541/1 git checkout FETCH_HEAD So instead of doing a checkout, I

Re: [coreboot] SeaVGABIOS with native vga init (Need testers)

On Sun, 16 Feb 2014 14:51:47 -0500 Kevin O'Connor ke...@koconnor.net wrote: There's also no cursor, which can probably be enhanced as well. Yes, I tested more, with seabios directly as a payload, for giving my old Lenovo x60 to someone and spending less time right now to explain him how to

Re: [coreboot] SeaVGABIOS with native vga init (Need testers)

On Wed, 12 Feb 2014 12:58:11 -0500 Kevin O'Connor ke...@koconnor.net wrote: I have recently put together a basic implementation of a vgabios for use with displays that are initialized by coreboot. Sorry, I've a huge mail backlog. To build this version of SeaVGABIOS, checkout the testing code

Re: [coreboot] Fwd: reset vector issue

Hi, ron minnich rminn...@gmail.com wrote: I read both, all parts, from 2004 to now. Muting this discussion. Peter, your comments are not helpful. Sorry I bothered you, folks. Have a nice day. I'm probably doing something wrong by continuing that discussion, but that kind of things seem

Re: [coreboot] BadBIOS Thoughts

On Sun, 03 Nov 2013 13:47:15 -0600 Alex mr.nuke...@gmail.com wrote: I'm sorry Ron, but you're just asking me to take your word for it. I can't do that. There's more secret code running on a Chromebook's firmware than there is free code. In fact, I would argue, most code where attack vectors

Re: [coreboot] BadBIOS Thoughts

On Sun, 3 Nov 2013 21:47:13 -0800 David Hendricks david.hendri...@gmail.com wrote: Anyway, if you can find more open Intel-based systems* I'd like to see 'em. The lenovo X60? *Before anyone suggests Minnowboard, don't. The pile of restrictively-licensed binary blobs necessary to boot those

Re: [coreboot] software hardening research project - request for advices to start

Hi, On Mon, 21 Oct 2013 18:14:38 +0200 Laurent Lesage laur...@2lconsult.be wrote: 3. is it possible to flash the BIOS without locking the board, i.e., is it always possible to recover a working bios if flashing process failed, or experimental BIOS is not working as expected. In that sense,

Re: [coreboot] Supported laptops (again), treacherous computing

On Mon, 15 Jul 2013 08:14:22 -0700 ron minnich rminn...@gmail.com wrote: I don't see how excluding the new, fixed version from coreboot helps anything. Further, it means you don't have bug-fixed microcode, which seems bad. It is at least a licensing problem: That microcode has a proprietary

Re: [coreboot] Supported laptops (again), treacherous computing

Hi, On Sat, 13 Jul 2013 22:18:50 +0400 Nikita Karetnikov nik...@karetnikov.org wrote: I mentioned Thinkpads for two reasons: I thought they don't need proprietary components, and they are quite popular among Coreboot people. [1]

Re: [coreboot] [x60s] Its alive! Its alive!

On Thu, 27 Jun 2013 19:22:15 +0200 Stefan Tauner stefan.tau...@student.tuwien.ac.at wrote: On Wed, 26 Jun 2013 15:59:54 -0700 Aaron Durbin adur...@chromium.org wrote: On Wed, Jun 26, 2013 at 3:58 PM, Stefan Tauner stefan.tau...@student.tuwien.ac.at wrote: One thing he did not mention

Re: [coreboot] coreboot on x60s

On Mon, 24 Jun 2013 12:55:16 +1000 oneofthem oneoft...@lavabit.com wrote: On Sun, Jun 23, 2013 at 02:09:57PM +0200, Denis 'GNUtoo' Carikli wrote: If you're not confident with the instructions provided at https://www.coreboot.org/Lenovo_x60x you could try to find someone in your area

Re: [coreboot] coreboot on x60s

On Sun, 23 Jun 2013 17:58:34 +1000 oneofthem oneoft...@lavabit.com wrote: Hey do you how to flash coreboot onto the x60s? I read the instructions here https://www.coreboot.org/Lenovo_x60x but I don't understand, mostly you will need: the flash source, a small patch for it, and the bucts

Re: [coreboot] Bricked Lenovo T60

On Fri, 21 Jun 2013 16:07:27 +0200 Gerd Hoffmann kra...@redhat.com wrote: Hi, Hi, Change the .write field to spi_chip_write_1 Yes, that one indeed should have been spi_chip_write_1. Sucessfully flashed coreboot, thanks to patch Damien mail and this correction. Yay! A few

Re: [coreboot] Bricked Lenovo T60

On Fri, 21 Jun 2013 09:26:11 -0700 ron minnich rminn...@gmail.com wrote: But if you do it, of course, you want to always be sure the 'fallback image' is a good one :-) In the case of SeaBIOS as a fallback payload, there is one more thing to take care of: The user must take care of making sure

[coreboot] Improving normal/fallback mecanism (Was: Bricked Lenovo T60)

On Fri, 21 Jun 2013 09:26:11 -0700 ron minnich rminn...@gmail.com wrote: the question about fallback is 'when do I tell the machine that the normal boot succeeded'? At LANL, we learned the best place: as LATE in the boot process as possible, long after LInux is up. You want to be sure, if you

Re: [coreboot] Fixed the bug of rs780 gfx port A

On Tue, 18 Jun 2013 14:53:09 -0600 David Hubbard david.c.hubbard+coreb...@gmail.com wrote: ASUS M4A785T-M: contact GNUtoo I cannot test right now: I'm relocating and while I took my mainboard, I don't have a power supply for it. Denis. -- coreboot mailing list: coreboot@coreboot.org

Re: [coreboot] Best Supported Laptop

Hi, On Sun, 2 Jun 2013 20:54:04 -0500 slhac tivist slhactiv...@gmail.com wrote: Which supported laptop is the most free? The Lenovo X60. According to the laptop section of: http://www.coreboot.org/Supported_Motherboards#Laptops That should probably be updated... The the status of the

Re: [coreboot] On loongson CPU or MIPS ARCH

On Mon, 29 Apr 2013 12:40:18 -0700 David Hendricks dhend...@google.com wrote: For romstage, we use a technique called cache-as-RAM to exploit the processor cache (or embedded SRAM, if available) as a temporary location to set up a stack and run C code. Vladimir pointed to me(on IRC) that

Re: [coreboot] [RFH] Test on hardware with GCC 4.7.3

On Mon, 22 Apr 2013 17:04:29 +0200 Paul Menzel paulepan...@users.sourceforge.net wrote: Dear coreboot folks, could you please test building coreboot for your hardware with GCC 4.7.3 and report back your results [1]? It also works on the Lenovo x60, I only did basic testing: it booted

Re: [coreboot] [RFH] Test on hardware with GCC 4.7.3

On Mon, 22 Apr 2013 17:04:29 +0200 Paul Menzel paulepan...@users.sourceforge.net wrote: Dear coreboot folks, could you please test building coreboot for your hardware with GCC 4.7.3 and report back your results [1]? Make sure to save your build with GCC 4.7.2 for comparison beforehand as

Re: [coreboot] [RFC] Improving early debugging as GSoC project

7. GDB Stub(and gdbwait) in romstage too. Denis. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [i915] Screen corruptions

On Sun, 14 Apr 2013 22:04:19 -0700 ron minnich rminn...@gmail.com wrote: What we do on ARM (see google/snow) for now is reserve a big chunk of memory in the coreboot tables for graphics. You could set the gtt to point to that. I've seen the framebuffer address for google/snow,I've also seen it

[coreboot] [i915] Screen corruptions

Hi, I'm still working on replacing the i915 option rom. The current code is here: http://review.coreboot.org/#/c/2998/ At the time of writing the Patch Set is the 5th. The status is the following: * I can set the screen color in coreboot. * During the boot, the screen is corrupted multiples

[coreboot] Microcodes

Hi, In src/cpu/intel/model_6fx/model_6fx_init.c there is: /* * This file is part of the coreboot project. * * Copyright (C) 2007-2009 coresystems GmbH * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License as *

Re: [coreboot] i915 status on x60.

On Sun, 3 Mar 2013 22:58:46 -0500 ron minnich rminn...@gmail.com wrote: setgtt is only for hardware with a gtt. Again, I'm not familiar with the hardware on this laptop. Does it have a gtt? it seems so(from the xf86-video-intel mentioned before): if (IS_G4X(pI830)) gtt =

Re: [coreboot] i915 status on x60.

On Sun, 3 Mar 2013 14:01:35 +0100 Denis 'GNUtoo' Carikli gnu...@no-log.org wrote: So here's the code: int dspbase = (plane == 0 ? DSPABASE : DSPBBASE); [...] int dspstride = (plane == 0) ? DSPASTRIDE : DSPBSTRIDE; [...] Stride = pScrn-displayWidth * pI830-cpp; [...] OUTREG(dspstride

Re: [coreboot] i915 status on x60.

Hi, Here are some updates: I've got screen to light up(power on + backlight) in userspace, I've put my forked code here: https://gitorious.org/gnutoo-for-coreboot/i915tool The branch is named working (thanks a lot to ron minnich for sharing his final/ directory for i915tool...without that I

Re: [coreboot] i915 status on x60.

On Sun, 3 Mar 2013 09:21:11 -0800 ron minnich rminn...@gmail.com wrote: I did not have time to read all your code, will try later. To get to the frame buffer on sandybridge, you just read one of the BARs, I think i't BAR 4. That won't work on the x60? I just found out that the bar2 where the

Re: [coreboot] i915 status on x60.

On Sun, 3 Mar 2013 20:35:48 +0100 Denis 'GNUtoo' Carikli gnu...@no-log.org wrote: common.c maps the framebuffer and then I do that with the virtual address: (gdb) set {int}0xa7d38000 = 0xff (gdb) p/x {int}0xa7d38000 $1 = 0x0 0xa7d38000 points or at the beginning of the bar, or at address

  1   2   >