[coreboot] riscv: how to running coreboot on HiFive Unleashed?
I try to running coreboot on HiFive Unleashed, but nothing come from uart. I tested by the following steps: 1. Write hifive-unleashed-a00-1.0-2018-03-20.gpt to TF card. 2. Change MSEL to 11 and boot linux 3. Copy coreboot.rom via scp 4. Write coreboot.rom to /dev/mtd0 by flashcp. 5. Change MSEL to 15 and boot coreboot. No response on uart. Do you have any suggestions? -- 王翔 安全研究员 广州市腾御安信息科技有限公司 广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboots Board Status have privacy issues for contributors
On Sun, Nov 25, 2018 at 9:25 AM wrote: > I was thinking of contributing to the Board Status but i dont want to > release any private data and wont contribute now. What is the usage of > the world to know what mac address the people are using? > Thanks for pointing out these issues. For what it's worth, the user must use the '-u' option to upload results. And as Arthur points out you can edit logs and such yourself to scrub any private data. The script just automates a few steps for convenience, though obviously we'd like a reasonably uniform data set to compare with. You're right that we don't need to know anyone's MAC address for coreboot development; however as others have pointed out a full kernel log is useful since firmware issues often manifest themselves there (memory map incorrect, devices not enabled, etc) so it's good to have them for comparison. Still, a pause as Mike suggested and perhaps a scary warning or two could be useful. Then there can be for example a simple live linux iso that people can boot > with LAN cable connected. No requirement of installation software, of > setting things up or anything like that. There is one - See util/board_status/set_up_live_image.sh . -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Hardware needed for flashing a T530
Mike Banon wrote: > CH341A is made by Jiangsu QinHeng Ltd., and there's a datasheet - > http://www.anok.ceti.pl/download/ch341ds1.pdf - according to which > this CH341A has just a few config registers, no internal memory for > any firmware It's a USB device; if you look at the USB protocol you'll quickly realise that it's quite likely that every single USB device runs firmware - you just never see it with some devices. > > Peter Stuge wrote: > > You can't possibly be equating Broadcom to TI in terms of openness? > > Indeed TI is more open than Broadcom, but still not completely open. Please be (much!!) more specific about how AM335x is "not completely open". You didn't answer whether you have looked at spruh73. > I don't know any single board computer that has been endorsed by Free > Software Foundation, Is that your primary metric, or do you rather try to find facts yourself? //Peter -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Hardware needed for flashing a T530
> Nico Huber wrote > Did you check that with an STM or how can you tell? CH341A is made by Jiangsu QinHeng Ltd., and there's a datasheet - http://www.anok.ceti.pl/download/ch341ds1.pdf - according to which this CH341A has just a few config registers, no internal memory for any firmware - and these CH341A based programmers don't have any extra memory chips on board, that means "the evil firmware" has nowhere to hide > Peter Stuge wrote: > You can't possibly be equating Broadcom to TI in terms of openness? Indeed TI is more open than Broadcom, but still not completely open. I don't know any single board computer that has been endorsed by Free Software Foundation, that means any of the existing SBCs require the non-free blobs to function. Maybe EOMA68 could become the first. On Mon, Nov 26, 2018 at 2:34 AM Nico Huber wrote: > > On 25.11.18 23:40, Mike Banon wrote: > >> If u have an Raspi or Beaglebone laying around , they are also suitable > >> for flashing > > Although there's a problem with > > Raspi/Beaglebone/any-other-SBC(single.board.computer)-except-EOMA68 I > > have to mention - they're running the non-free binary blobs, and > > CH341A or Bus Pirate are better in this relation: CH341A - no firmware > > at all > > Did you check that with an STM or how can you tell? > > Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Hardware needed for flashing a T530
On 25.11.18 23:40, Mike Banon wrote: >> If u have an Raspi or Beaglebone laying around , they are also suitable for >> flashing > Although there's a problem with > Raspi/Beaglebone/any-other-SBC(single.board.computer)-except-EOMA68 I > have to mention - they're running the non-free binary blobs, and > CH341A or Bus Pirate are better in this relation: CH341A - no firmware > at all Did you check that with an STM or how can you tell? Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Hardware needed for flashing a T530
Mike Banon wrote: > there's a problem with > Raspi/Beaglebone/any-other-SBC(single.board.computer)-except-EOMA68 I > have to mention - they're running the non-free binary blobs You can't possibly be equating Broadcom to TI in terms of openness? What's your experience with the actual products of those companies? Have you looked at spruh73? Put another way: What are your blob concerns (this is such a ridiculously simplified discussion) with AM335x? //Peter -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Hardware needed for flashing a T530
Hi Mike, On 25.11.18 23:40, Mike Banon wrote: > Hi Nico, please could you confirm that FT2232H (link to which you have > provided) could work as a debug dongle? At "menuconfig" I only see > USBDEBUG_DONGLE_FTDI_FT232H but not FT2232H , don't know how similar > they are to each other yes, it works. FT4232H should work too btw. The FT232H just implements a single port, the FT4232H four ports. But they should be compatible otherwise (at least I didn't see any distinction for them when looking at libftdi to write the debug support). Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ?==?utf-8?q? Hardware needed for flashing a T530
Thanks for your answers! Because I had an 10€ ebay coupon, I decided to buy a CH341A and a 10cm dupont female-female cable for just 0,74€ ;) Do you know how to check if the CH341A works correctly (like the correct voltage etc.)? Am So. 25. November 2018 23:40 CET, Mike Banon schrieb: Hi Nico, please could you confirm that FT2232H (link to which you have provided) could work as a debug dongle? At "menuconfig" I only see USBDEBUG_DONGLE_FTDI_FT232H but not FT2232H , don't know how similar they are to each other @kinky_nekoboi: > If u have an Raspi or Beaglebone laying around , they are also suitable for > flashing Although there's a problem with Raspi/Beaglebone/any-other-SBC(single.board.computer)-except-EOMA68 I have to mention - they're running the non-free binary blobs, and CH341A or Bus Pirate are better in this relation: CH341A - no firmware at all, just a few config registers ; Bus Pirate - completely open source firmware On Mon, Nov 26, 2018 at 1:36 AM kinky_nekoboi wrote: > > If u have an Raspi or Beaglebone laying around , they are also suitable for > flashing > > Am 25. November 2018 22:55:56 MEZ schrieb Nico Huber : >> >> Hi Yannik, >> >> On 25.11.18 20:05, Yannik Catalinac wrote: >>> >>> For the SPI programmer I decided to use a CH341A, but when I search for >>> it there are different CH341A. Which one should I buy? >> >> >> It shouldn't matter as long as it says to be compatible to SPI 25 >> series. There were reports about bad batches of every kind (e.g. >> wrong voltage regulator), FWIW. So there's always a risk. I would >> pick one with a location in Europe (i.e. not China) so you don't >> wait weeks and then realize you got a bad one. I have one with a >> black board btw. that works fine. >> >> As you asked for a German shop below, here[1] is a more expensive >> alternative to the CH341A. 5x the cost, up to 15x the speed (and >> can also work as a USB debugging device with coreboot; needs another >> TTL level UART for the other end, though). >> >>> >>> Which cables do you recommend? I read that I should use short ones, but >>> which cables exactly dou you recommend? A link to a german shop would be >>> very, very helpful! >> >> >> Reichelt has some rather expensive ones[2]. Work for me but I can't say >> if they are any better than random ones from eBay. For the latter search >> for `10cm dupont female-female` (Buchse-Buchse). >> >> Hope that helps, >> Nico >> >> [1] >> https://www.elv.de/elv-highspeed-mini-usb-modul-um-ft2232h-komplettbausatz.html >> Also needs a Mini-B (not the popular Micro-B) USB cable in case you >> don't have a spare one. >> [2] https://www.reichelt.de/ >> Search for: steckboard lbb > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Hardware needed for flashing a T530
Hi Nico, please could you confirm that FT2232H (link to which you have provided) could work as a debug dongle? At "menuconfig" I only see USBDEBUG_DONGLE_FTDI_FT232H but not FT2232H , don't know how similar they are to each other @kinky_nekoboi: > If u have an Raspi or Beaglebone laying around , they are also suitable for > flashing Although there's a problem with Raspi/Beaglebone/any-other-SBC(single.board.computer)-except-EOMA68 I have to mention - they're running the non-free binary blobs, and CH341A or Bus Pirate are better in this relation: CH341A - no firmware at all, just a few config registers ; Bus Pirate - completely open source firmware On Mon, Nov 26, 2018 at 1:36 AM kinky_nekoboi wrote: > > If u have an Raspi or Beaglebone laying around , they are also suitable for > flashing > > Am 25. November 2018 22:55:56 MEZ schrieb Nico Huber : >> >> Hi Yannik, >> >> On 25.11.18 20:05, Yannik Catalinac wrote: >>> >>> For the SPI programmer I decided to use a CH341A, but when I search for >>> it there are different CH341A. Which one should I buy? >> >> >> It shouldn't matter as long as it says to be compatible to SPI 25 >> series. There were reports about bad batches of every kind (e.g. >> wrong voltage regulator), FWIW. So there's always a risk. I would >> pick one with a location in Europe (i.e. not China) so you don't >> wait weeks and then realize you got a bad one. I have one with a >> black board btw. that works fine. >> >> As you asked for a German shop below, here[1] is a more expensive >> alternative to the CH341A. 5x the cost, up to 15x the speed (and >> can also work as a USB debugging device with coreboot; needs another >> TTL level UART for the other end, though). >> >>> >>> Which cables do you recommend? I read that I should use short ones, but >>> which cables exactly dou you recommend? A link to a german shop would be >>> very, very helpful! >> >> >> Reichelt has some rather expensive ones[2]. Work for me but I can't say >> if they are any better than random ones from eBay. For the latter search >> for `10cm dupont female-female` (Buchse-Buchse). >> >> Hope that helps, >> Nico >> >> [1] >> https://www.elv.de/elv-highspeed-mini-usb-modul-um-ft2232h-komplettbausatz.html >> Also needs a Mini-B (not the popular Micro-B) USB cable in case you >> don't have a spare one. >> [2] https://www.reichelt.de/ >> Search for: steckboard lbb > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Hardware needed for flashing a T530
If u have an Raspi or Beaglebone laying around , they are also suitable for flashing Am 25. November 2018 22:55:56 MEZ schrieb Nico Huber : >Hi Yannik, > >On 25.11.18 20:05, Yannik Catalinac wrote: >> For the SPI programmer I decided to use a CH341A, but when I search >for >> it there are different CH341A. Which one should I buy? > >It shouldn't matter as long as it says to be compatible to SPI 25 >series. There were reports about bad batches of every kind (e.g. >wrong voltage regulator), FWIW. So there's always a risk. I would >pick one with a location in Europe (i.e. not China) so you don't >wait weeks and then realize you got a bad one. I have one with a >black board btw. that works fine. > >As you asked for a German shop below, here[1] is a more expensive >alternative to the CH341A. 5x the cost, up to 15x the speed (and >can also work as a USB debugging device with coreboot; needs another >TTL level UART for the other end, though). > >> >> Which cables do you recommend? I read that I should use short ones, >but >> which cables exactly dou you recommend? A link to a german shop would >be >> very, very helpful! > >Reichelt has some rather expensive ones[2]. Work for me but I can't say >if they are any better than random ones from eBay. For the latter >search >for `10cm dupont female-female` (Buchse-Buchse). > >Hope that helps, >Nico > >[1] >https://www.elv.de/elv-highspeed-mini-usb-modul-um-ft2232h-komplettbausatz.html >Also needs a Mini-B (not the popular Micro-B) USB cable in case you >don't have a spare one. >[2] https://www.reichelt.de/ >Search for: steckboard lbb > >-- >coreboot mailing list: coreboot@coreboot.org >https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboots Board Status have privacy issues for contributors
I've already raised this board_status.sh issue a few months earlier, together with the proposed fix (which I forgot to transform into a patch, perhaps because no one replied to me) - https://mail.coreboot.org/pipermail/coreboot/2018-April/086488.html . It could be hard to create an automatic filter which will successfully erase all the information that you believe is private, and also there could be different estimates of what is private and what is not. Perhaps the easiest solution is just to insert a pause before uploading the results, so that a user could use this pause to remove the log parts that he considers as private. Also, this way only the user will be responsible for removing his private information and there wouldn't be any complains like "your script didn't remove X and some 3-letter-agency hacked me by using this knowledge" On Mon, Nov 26, 2018 at 12:03 AM Nico Huber wrote: > > On 25.11.18 18:24, j44...@goat.si wrote: > > the mac 70:3a:cb:bd:fd:e3 . This is probably some Google device his > > device is connecting to because the mac range is registered to Google > > Inc. Now i can lookup in public wifi databases and in some cases i then > > know where the users lives. > > You can also just ask them where they live. Whereby I want to say, not > everybody is in the same paranoid mode. > > > I was thinking of contributing to the Board Status but i dont want to > > release any private data and wont contribute now. What is the usage of > > the world to know what mac address the people are using? > > There is no usage. It just makes the script simpler that gathers the > information. > > > > > Please fix this to: > > No, you, please fix this. You are very welcome to contribute patches. > > > 1) Remove kernel log and replace it with "uname -r" to just know the > > kernel version. > > This makes no sense, nobody asked for the kernel version. We want to see > kernel messages. You can however implement a heuristic to filter per- > sonal information. > > > 2) Please make the contribution without the force of having to register > > to git. Make a public account that have just access to the > > board-status.git and set this public account into the code itself. > > You are free to set something like this up and redirect all pushes to > your Gerrit account. *After* you filtered spam. > > > Then > > there can be for example a simple live linux iso that people can boot > > with LAN cable connected. No requirement of installation software, of > > setting things up or anything like that. > > Yes, please implement that. Again patches are welcome. We don't lack > ideas, we lack the time to set things up. So once you are done with > that, feel free to ask what else you can do. > > Nico > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Hardware needed for flashing a T530
Hi Yannik, On 25.11.18 20:05, Yannik Catalinac wrote: > For the SPI programmer I decided to use a CH341A, but when I search for > it there are different CH341A. Which one should I buy? It shouldn't matter as long as it says to be compatible to SPI 25 series. There were reports about bad batches of every kind (e.g. wrong voltage regulator), FWIW. So there's always a risk. I would pick one with a location in Europe (i.e. not China) so you don't wait weeks and then realize you got a bad one. I have one with a black board btw. that works fine. As you asked for a German shop below, here[1] is a more expensive alternative to the CH341A. 5x the cost, up to 15x the speed (and can also work as a USB debugging device with coreboot; needs another TTL level UART for the other end, though). > > Which cables do you recommend? I read that I should use short ones, but > which cables exactly dou you recommend? A link to a german shop would be > very, very helpful! Reichelt has some rather expensive ones[2]. Work for me but I can't say if they are any better than random ones from eBay. For the latter search for `10cm dupont female-female` (Buchse-Buchse). Hope that helps, Nico [1] https://www.elv.de/elv-highspeed-mini-usb-modul-um-ft2232h-komplettbausatz.html Also needs a Mini-B (not the popular Micro-B) USB cable in case you don't have a spare one. [2] https://www.reichelt.de/ Search for: steckboard lbb -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboots Board Status have privacy issues for contributors
On 25.11.18 18:24, j44...@goat.si wrote: > the mac 70:3a:cb:bd:fd:e3 . This is probably some Google device his > device is connecting to because the mac range is registered to Google > Inc. Now i can lookup in public wifi databases and in some cases i then > know where the users lives. You can also just ask them where they live. Whereby I want to say, not everybody is in the same paranoid mode. > I was thinking of contributing to the Board Status but i dont want to > release any private data and wont contribute now. What is the usage of > the world to know what mac address the people are using? There is no usage. It just makes the script simpler that gathers the information. > > Please fix this to: No, you, please fix this. You are very welcome to contribute patches. > 1) Remove kernel log and replace it with "uname -r" to just know the > kernel version. This makes no sense, nobody asked for the kernel version. We want to see kernel messages. You can however implement a heuristic to filter per- sonal information. > 2) Please make the contribution without the force of having to register > to git. Make a public account that have just access to the > board-status.git and set this public account into the code itself. You are free to set something like this up and redirect all pushes to your Gerrit account. *After* you filtered spam. > Then > there can be for example a simple live linux iso that people can boot > with LAN cable connected. No requirement of installation software, of > setting things up or anything like that. Yes, please implement that. Again patches are welcome. We don't lack ideas, we lack the time to set things up. So once you are done with that, feel free to ask what else you can do. Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Fwd: Supported Motherboards
I need to pick a better email client, or remember to say "reply all" -- Forwarded message - From: Matt B Date: Sun, Nov 25, 2018 at 2:59 PM Subject: Re: [coreboot] Supported Motherboards To: I also don't see "drop it and if someone likes it they'll work to get it back to master" as being more than a band-aid solution. It doesn't do anything to raise the probability of bad code getting dealt with, but it does put the problem out of sight and out of mind. The reason people who use this laptop are so resistant is that they see it as a statement that the speaker doesn't care about fixing what's broken and would much rather it just disappear. (regardless of who happens to be using it) It's saying you want the other side just be quiet and go away, which isn't constructive. -Matt On Sun, Nov 25, 2018 at 2:43 PM Matt B wrote: > Hi, > > It seems that whenever someone mentions the ME (or one of a number of > other topics) the G505s is inevitably recommended, and people subsequently > get into a debate over the relative badness of the ME vs atomBIOS/microcode > ect. [1] This also leads to people lamenting the G505s for it's shitty > AGESA codebase [2], and arguments over dropping boards like the G505s from > master. If the thread gets really nasty, it gets into arguments over > corporate influence of coreboot. > > But this cycle of arguments doesn't get us anywhere and the G505s code > continues to languish. It hasn't been abandoned *yet* but it doesn't become > any less likely that some new feature will lead to it getting dropped [3]. > > I think this is tragic, since it's a still reasonably powerful laptop, > probably took a lot of porting work, and has advantages over a lot of > alternatives. [4] The fundamental problem seems to me to be that there are > a hell of a lot of people who use G505s (seems very popular with people who > run qubes), there haven't been a lot of people with the skill or > inclination [5] to do the work required to put it on par with [insert > favorite thinkpad]. The task of doing the cleanup or rewrite (whatever is > required) may not be the most immediately attractive or productive task, > but it seems like something that would make everybody a lot happier and > eliminate a lot of arguing in the long run. > > Now, I may be a G505s owner, but I'm certainly not qualified to work on > it's code. Rather than argue that "some developer" > should, I'd like to propose something different. I think we should have a > proper, technical discussion of what we want the G505s port to look like, > what the best means to get there is (cleanup or rewrite, for example), and > based on who wants to volunteer and who would be willing to do it under > contract, figure out how much it would cost. Then we ask the people who own > G505s or who want to see it improved to pony up the money to make that > happen in a crowd-funding campaign, like any other open source software > project would. [6] > > Then maybe we can firmly put this laptop on the list of "great to use > with coreboot" without this massive asterisk beside it. > > Sincerely, > -Matt > > [1] It's interesting to note that there has been some recent movement on > improving the atomBIOS situation a little bit. While I have a hard time > imagining a future where all the drivers are patched to not need atomBIOSs, > I can imagine a future where we compile and use open source > re-implementations of existing atomBIOSs. > https://www.phoronix.com/scan.php?page=news_item=Flashrom-AMD-SPI-Patches > [2] For an example, look no further that is the current workaround for > getting up-to-date microcode into these things, which I understand is borne > in part from buggyness in AGESA microcode loading code > [3] These rules are probably very reasonable, but I don't think there's > any way that people won't read them as malicious in contexts like these. > [4] To name a recent example, there are threads from this month that look > like discrete GPU support will come in the immediate future, along with > better support for variants with the A8 APU. > [5] Empirically, since this still hasn't been done. No offense to anyone > who's tried. > [6] Inspired by the recent talk about offering funding to paulk to work on > his open source EC firmware for the G505s. > > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] FYI: Raptor's new POWER9-based "Blackbird" open for pre-order
Hi all, Just for your interest, there's a new POWER9-based mainboard from Raptor called "Blackbird", with a much lower price point than the TalosII which seems to be more desktop class than server oriented: https://secure.raptorcs.com/content/BK1MB1/intro.html There's also a 4-core and an 8-core bundle: https://secure.raptorcs.com/content/BK1B01/purchase.html https://secure.raptorcs.com/content/BK1B02/purchase.html This could make for a nice coreboot target, since so much documentation is open, and since it shares the open source spirit with coreboot... Documentation is available on the wiki: https://wiki.raptorcs.com/wiki/Main_Page Cheers, Merlin PS: I know this isn't fully on-topic, so I hope nobody minds me sharing it here. PPS: There's a special pricing going on until monday midnight! -- Merlin Büge -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Further coreboot releases, setting new standards
"Jay Talbott" writes: > I know I don't post much here, but I feel like I need to chime in on this > thread... Perhaps it's time that SysPro becomes a louder voice in the > community. > > Bay Trail and Broadwell DE are both still very popular platforms, yet > neither one of them meets the cut for any of the three criteria. So I > caution against removing the support for either of them too hastily. Could you test with "select NO_RELOCATABLE_RAMSTAGE"? > > Yes, it can be a pain to keep maintaining old platforms, and certainly > support for platforms that are old enough that they are no longer being used > by anybody are good candidates for cleanup and > removal. It's not about old or new. For instance the Intel i440bx (20y old) is still supported by coreboot, uses many recent features like POSTCAR_STAGE and relocatable ramstage, so it would be flagged for cleanup and removal. > But support for platforms that are still popular and still actively being > used by people shouldn't be stripped out of the coreboot code base. > If they are still popular and actively used, it would mean that someone has interest towards achieving new coreboot standards? Pushing standards is not really about active use or not but about improving the code base. > My $0.02. > > - Jay > > Jay Talbott > SysPro Consulting, LLC > 3057 E. Muirfield St. > Gilbert, AZ 85297 > (480) 704-8045 > (480) 445-9895 (FAX) > jaytalb...@sysproconsulting.com > http://www.sysproconsulting.com > > Original Message > Subject: Re: [coreboot] Further coreboot releases, setting new standards > From: Arthur Heymans > Date: Fri, November 23, 2018 8:32 am > To: Patrick Georgi via coreboot > Cc: Patrick Georgi > > Patrick Georgi via coreboot writes: > > > Am Fr., 23. Nov. 2018 um 14:43 Uhr schrieb Arthur Heymans > : > > > > I'd argue for requiring the following: > > > > In which time frame? The next release, ie May 2019? In two releases, > > November 2019? > > > That is indeed worthy item of discussion. > > NO_RELOCATABLE_RAMSTAGE on x86 is only selected by: > NORTHBRIDGE_AMD_AMDFAM10, > NORTHBRIDGE_AMD_LX, > NORTHBRIDGE_VIA_VX900, > SOC_INTEL_FSP_BAYTRAIL, > SOC_INTEL_FSP_BROADWELL_DE > > POSTCAR_STAGE is selected by: > cpu/amd/agesa > cpu/amd/pi > mainboard/intel/galileo > northbridge/intel/i440bx > northbridge/intel/i945 > northbridge/intel/e7505 > northbridge/intel/gm45 > northbridge/intel/haswell > northbridge/intel/nehalem > northbridge/intel/pineview > northbridge/intel/sandybridge > northbridge/intel/sandybridge > northbridge/intel/x4x > soc/amd/stoneyridge > soc/intel/apollolake > soc/intel/cannonlake > soc/intel/denverton_ns > soc/intel/skylake > soc/intel/icelake > so all other x86 targets don't implement it and therefore lack > NO_CAR_GLOBAL_MIGRATION. > > C_ENVIRONMENT_BOOTBLOCK is even less used since it is a relatively new > feature (was introduced with INTEL_APOLLOLAKE and INTEL_SKYLAKE) so most > x86 targets don't implement it but there are already many patches for it > lying > around for review (like most targets in northbridge/intel/*). It is > however a very useful feature to have. > > So it would seem reasonable to drop NO_RELOCATABLE_RAMSTAGE in may 2019 > and mandate NO_CAR_GLOBAL_MIGRATION and C_ENVIRONMENT_BOOTBLOCK in > november 2019? Any thoughts on this? > > Nico also suggested to set the timeframe 2 weeks before the release, to > avoid last minute WIP patches attempting to tackle the issue right > before the release. > > -- > == > Arthur Heymans > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- == Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Hardware needed for flashing a T530
Hello, which hardware do you guys recommend for flashing a Lenovo Thinpad T530? As far as I know you need three things: 1. SPI programmer with USB connection and USB cable 2. SOIC8 clip 3. cables to connect the SPI programmer and the SOIC8 clip I'm sure with number 2, so I already bought a Pomona 5250 clip. For the SPI programmer I decided to use a CH341A, but when I search for it there are different CH341A. Which one should I buy? Which cables do you recommend? I read that I should use short ones, but which cables exactly dou you recommend? A link to a german shop would be very, very helpful! Thanks for helping Greetings -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Further coreboot releases, setting new standards
On 2018-11-23 04:32 PM, Arthur Heymans wrote: > Patrick Georgi via coreboot writes: > >> Am Fr., 23. Nov. 2018 um 14:43 Uhr schrieb Arthur Heymans >> : >> >> I'd argue for requiring the following: >> >> In which time frame? The next release, ie May 2019? In two releases, >> November 2019? >> > That is indeed worthy item of discussion. > > NO_RELOCATABLE_RAMSTAGE on x86 is only selected by: > NORTHBRIDGE_AMD_AMDFAM10, > NORTHBRIDGE_AMD_LX, > NORTHBRIDGE_VIA_VX900, > SOC_INTEL_FSP_BAYTRAIL, > SOC_INTEL_FSP_BROADWELL_DE > > POSTCAR_STAGE is selected by: > cpu/amd/agesa > cpu/amd/pi > mainboard/intel/galileo > northbridge/intel/i440bx > northbridge/intel/i945 > northbridge/intel/e7505 > northbridge/intel/gm45 > northbridge/intel/haswell > northbridge/intel/nehalem > northbridge/intel/pineview > northbridge/intel/sandybridge > northbridge/intel/sandybridge > northbridge/intel/x4x > soc/amd/stoneyridge > soc/intel/apollolake > soc/intel/cannonlake > soc/intel/denverton_ns > soc/intel/skylake > soc/intel/icelake > so all other x86 targets don't implement it and therefore lack > NO_CAR_GLOBAL_MIGRATION. > Not sure what to do here. I haven't looked at it and there's no documentation. > > C_ENVIRONMENT_BOOTBLOCK is even less used since it is a relatively new > feature (was introduced with INTEL_APOLLOLAKE and INTEL_SKYLAKE) so most > x86 targets don't implement it but there are already many patches for it lying > around for review (like most targets in northbridge/intel/*). It is > however a very useful feature to have. > > So it would seem reasonable to drop NO_RELOCATABLE_RAMSTAGE in may 2019 > and mandate NO_CAR_GLOBAL_MIGRATION and C_ENVIRONMENT_BOOTBLOCK in > november 2019? Any thoughts on this? > Sound like a good plan. All maintainers (via git log/gerrit/MAINTAINERS) should be notified now, if this is going to happen, to make sure that they are aware of the (bad) code quality. I don't think that it'll be a problem of time or money if everybody has been properly warned. > Nico also suggested to set the timeframe 2 weeks before the release, to > avoid last minute WIP patches attempting to tackle the issue right > before the release. > > -- > == > Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Supported Mainboard in coreboot is missing because of using LATE_CBMEM_INIT
j44...@goat.si writes: > Hello. I got a MSI MS6178 mainboard for coreboot based on the official wiki > page > https://www.coreboot.org/Board:msi/ms6178 > > I have followed the wiki to build coreboot but the board is missing in make > menuconfig here: https://www.coreboot.org/Build_HOWTO > > Then i find https://review.coreboot.org/c/coreboot/+/23300 > > Thus i run 'git checkout tags/4.7' > > But when trying to build a image i got following error: > > Cloning into 'seabios'... > fatal: https://review.coreboot.org/p/seabios.git/info/refs not valid: is this > a > git repository? > Makefile:18: recipe for target 'seabios' failed You can try to build the payload separately. > > Could someone fix the MSI MS6178 mainboard so that it can be used with the > recent coreboot? That would require that platform (i810) to have early cbmem init. > Thanks! -- == Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboots Board Status have privacy issues for contributors
j44...@goat.si writes: > > I was thinking of contributing to the Board Status but i dont want to release > any private data and wont contribute now. What is the usage of the world to > know > what mac address the people are using? > Feel free to edit the kernel log. > Please fix this to: > 1) Remove kernel log and replace it with "uname -r" to just know the kernel > version. The kernel log does contain other useful information, so dropping it would make the board status repo less useful. -- == Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Coreboots Board Status have privacy issues for contributors
I took a look into https://review.coreboot.org/cgit/board-status.git? The commit here https://review.coreboot.org/cgit/board-status.git/commit/?id=72945dee4c60b90cdf6c507f4847c26028a56a09 tells me for example that the MAC address from Paul Menzel is bc:5f:f4:c8:d3:98 . The mac address from the WLAN Router Patrick Georgi is using is based on this commit https://review.coreboot.org/cgit/board-status.git/commit/?id=addd59d8fb55dc62a7d8e9ec730612f63fc5d61a the mac 70:3a:cb:bd:fd:e3 . This is probably some Google device his device is connecting to because the mac range is registered to Google Inc. Now i can lookup in public wifi databases and in some cases i then know where the users lives. The mac address from Chris Thompson is 6c:f0:49:47:22:4d based on https://review.coreboot.org/cgit/board-status.git/commit/?id=da41a5a88bebc9ffbe2cbc9a38a5fba530496daf And the mac address from Denis 'GNUtoo' Carikli who is using parabola as os was using a Hitachi HDP725050GLA360 with firmware GM4OA52A and a second WDC WD5000AAKB-00YSA0 with firmware 12.01C02 and have switched now to a ST9160314AS with 0002SDM1 firmware. His mac address of one of his computers is bc:5f:f4:9c:b7:32 . In this computer he is using a KINGSTON SV300S37A240G with firmware 603ABBF0 . I was thinking of contributing to the Board Status but i dont want to release any private data and wont contribute now. What is the usage of the world to know what mac address the people are using? Please fix this to: 1) Remove kernel log and replace it with "uname -r" to just know the kernel version. 2) Please make the contribution without the force of having to register to git. Make a public account that have just access to the board-status.git and set this public account into the code itself. Then there can be for example a simple live linux iso that people can boot with LAN cable connected. No requirement of installation software, of setting things up or anything like that. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Supported Mainboard in coreboot is missing because of using LATE_CBMEM_INIT
Hello. I got a MSI MS6178 mainboard for coreboot based on the official wiki page https://www.coreboot.org/Board:msi/ms6178 I have followed the wiki to build coreboot but the board is missing in make menuconfig here: https://www.coreboot.org/Build_HOWTO Then i find https://review.coreboot.org/c/coreboot/+/23300 Thus i run 'git checkout tags/4.7' But when trying to build a image i got following error: Cloning into 'seabios'... fatal: https://review.coreboot.org/p/seabios.git/info/refs not valid: is this a git repository? Makefile:18: recipe for target 'seabios' failed Could someone fix the MSI MS6178 mainboard so that it can be used with the recent coreboot? Thanks! -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Supported Motherboards
On 11/23/2018 10:28 AM, Felix Held wrote: > I get the impressions that a few people are quite vocal on the mailing > list about keeping stuff in the master branch that fell into disrepair > and hinders the project in moving forward and improving things. I can agree yes some stuff that clearly no longer works should be removed from master but people were talking about for instance removing the native fam15h boards KGPE-D16 and KCMA-D8 (last and best owner controlled libre firmware x86 boards and arguably the best examples of coreboot ports and hw init code) because they thought they didn't have a working S3 mode without soliciting someone to test it until I reported back that it still works (I use it all the time and tested it in master). I feel as though at the current rate of people being too eager to remove still functional boards for arbitrary reasons there won't be any easily obtainable non development boards on master - another side issue is that coreboot repos don't contain the libs required to compile the older versions which are becoming increasingly unavailable with some only downloadable from a single site hence I suggest the direct hosting of them rather than requiring people to download from third party websites that may or may not work in the future. There needs to be some type of solution to this issue or in so many years coreboot master will no longer be an open source firmware project since it will only be able to initiate new x86 systems that happen to require binary blobs. I have never met a comp-sci/comp-engineering graduate or anyone in a computer field who has heard of coreboot and that needs to change - there needs to be some type of advertising so that there can be more than a few wizards capable of the dark arts of firmware editing and who have the time and resources to deal with arbitrary continued maintenance. > but those few people seem to mostly complain, but don't either contribute > patches to be merged in upstream master or hire people to fix things. I have provided technical support to over 100 coreboot users and have enticed many more to procure a supported board and start using it, I also donate to projects and provide hardware to developers when I can...the ways you say are not the only ways to contribute :D -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Further coreboot releases, setting new standards
Dear Jay, Am Freitag, den 23.11.2018, 19:20 -0700 schrieb Jay Talbott: > I know I don't post much here, but I feel like I need to chime in on > this thread... Perhaps it's time that SysPro becomes a louder voice > in the community. > > Bay Trail and Broadwell DE are both still very popular platforms, yet > neither one of them meets the cut for any of the three criteria. So I > caution against removing the support for either of them too hastily. It’d be nice if you gave a little bit more background, what your company does. I can’t find any commits from you for example. git log --author=sysproc > Yes, it can be a pain to keep maintaining old platforms, and > certainly support for platforms that are old enough that they are no > longer being used by anybody are good candidates for cleanup and > removal. But support for platforms that are still popular and still > actively being used by people shouldn't be stripped out of the > coreboot code base. How should coreboot upstream know, what is popular or not? So it’s good that you engage with the community. On the other hand, you didn’t answer any of the issues raised by Arthur, that maintaining outdated chipsets and boards puts the burden on – often freetime – developers. How can SysPro help here improve the boards and implement the things Arthur raised? It’d be nice to have SysPro as a more active member of the coreboot community by contributing code, documentation, or money. If that is not possible, please answer, what the problem would be for you to just use the current code from a separate branch. Kind regards, Paul PS: Your mailer doesn’t set the References header field, causing the threading to be broken. PPS: Please also at least send a plain text part. A lot of people prefer to look at that, and it also works better with the mailing list archive. (I’d even prefer to not get any HTML stuff at all. The Linux Kernel Mailing List even rejects such messages.) [1]: https://mail.coreboot.org/pipermail/coreboot/2018-November/087852.html signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
