[coreboot] Re: SuzyQable - ChromeOS Debug Cable
Hello! It wasn't a question. Not really. I was asking the group at-large to see how many of us are aware of them things. You, Matt, were the first. And on the document that I mentioned that the Sparkfun page has linked, describing what devices were supported, and naturally were not, at the bottom was one of us also., see here https://sites.google.com/a/chromium.org/dev/chromium-os/developer-information-for-chrome-os-devices It turns out that the page you referenced, is also there, it is where everything on the subject migrated to. As for me, I am leaning towards two things, one of obtaining the cable, and two is obtaining one of the known working devices. My problem is that the model I met the same day I bought this guy, is not listed. It's the Dell Chromebook who's advertiser was a Classical Music fan. (He or they used a Beethoven Rondo, "Rage over a lost penny") it was well done and seemed to be choreographed to the music. Soon I hope. However I have WSL enabled on this machine, can I use that to build but not necessarily run the Chrome OS images that the Google folk want us to build and try out? As for on what I'm still thinking of what for that. - Gregg C Levine gregg.drw...@gmail.com "This signature fought the Time Wars, time and again." On Fri, Jan 17, 2020 at 1:01 PM Matt DeVillier wrote: > > sorry, what exactly is your question? I have one of these cables, works > great for flashing/debugging Chromebooks via CCD > > the updated Chromium CCD docs can be found at: > https://chromium.googlesource.com/chromiumos/platform/ec/+/master/docs/case_closed_debugging_cr50.md > > On Fri, Jan 17, 2020 at 11:33 AM Gregg Levine wrote: >> >> Hello! >> Does the thing at https://www.sparkfun.com/products/14746 create a >> response with regards to anyone? >> >> On their documents tab they present the now wrong link where to find >> more information about how the cable works. And of course they also >> link to those devices that might be interested in working with it. >> >> Call me curious, but I'm interested in seeing how many of us recognize >> the unique nature of it. >> - >> Gregg C Levine gregg.drw...@gmail.com >> "This signature fought the Time Wars, time and again." >> ___ >> coreboot mailing list -- coreboot@coreboot.org >> To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: A Hardware enthusiast view on the usefulness of open source Firmwares like Coreboot
Mike Banon wrote: > It would've been helpful if your article had your e-mail in the end of > it or a reply form - I've stumbled upon your article some time ago, > but didn't find a quick way to share my feedback and got distracted by > something else, maybe the others did too... I didn't include an E-Mail because I posted this mostly in forums where other registered users could already reply in public, instead of doing so privately. > 1) Thanks for describing CH341A, as it is a simple, reliable and > affordable flashrom-supported SPI programmer. However, there's a > problem that some CH341A give 5V voltage instead of 3.3V - although, > as the time passes, these incorrect CH341A models will disappear, it > could be worth mentioning this problem so that your reader will test > the voltage of his CH341A before using it. By the way, even the > "incorrect ones" may be fixed by a small hardware mod. The focus was pretty much on describing the convenience of a socketed SPI Flash EEPROM and how these could be easily reflashed with an external reprogrammer, then put the CH341A as an example of how cheap and accessible those tools actually are (FAR cheaper than having to purchase a cheap Processor just to boot, and without needing fancy ECs/BMCs potentially increasing the Motherboard BoM). It was not about describing the reprogrammer itself. Also, as far that I know there are 1.8V SPI Flash EEPROMs, which requires support from the reprogrammer, too. I don't know whenever the 3.3V versions are the mainstream ones or if there are major uses for the 1.8V and 5V versions. I suppose that anyone that is actually going to use a reprogrammer will do its homework by reading any instructions and compatibility list anyways as to not screw up. > 2) I didn't like your opinion of SeaBIOS, that it's just "mostly used > to support legacy OSes and PCIe Cards with Option ROMs that have only > a BIOS compatible Device Firmware." Remember that I'm an almost Windows-only user. I can't see any reason why a person with a blank drive would go for BIOS-MBR instead of UEFI-GPT in a new Windows install, unless they already have a MBR formatted drive that they want to reuse without repartitioning. Also, since Windows ONLY works in these two modes, it means that if you want to use SeaBIOS because you don't like TianoCore, you're limited to MBR and its 2 TB boot disk limitation. This would work fine right now because with a rather mainstream build being a 512 GiB/1 TiB SSD plus a big HD, you could partition the SSD with MBR and install Windows in BIOS mode, whereas the big HD could be formatted as GPT and Windows could still use it for storage with no issues. In 2-3 years or so when you average SSD size is 2 TiB, SeaBIOS for bare metal Windows wouldn't cut it any longer. > 3) It a bit puzzles me why you didn't mention any interesting > floppy-based OS like Kolibri in the "floppy part". Windows 3.1 may > seem interesting, however there wouldn't be any updates or software > for it, it's stuck at whatever level has been reached during its' > lifetime, while a lot of the other floppy OS projects - i.e. some of > those I'm offering with csb_patcher.sh script (KolibriOS, FreeDOS, > MichalOS, Snowdrop, Fiwix, Memtest, Tatos, Plop, FloppyBird) - are > still being developed. At least you've mentioned a FreeDOS, but there > are many interesting floppy projects - including those with a > minimalistic Linux environment, and PicoBSD - which haven't been > mentioned even in brief. Perhaps that's because your Tianocore payload > does not support the floppies, so you didn't have a chance to explore > this wonderful world personally. I really feel this part is a bit > short and could be really expanded. In example, if KolibriOS supports > your Ethernet controller, you could access the Internet right from > your BIOS and IRCC chat with your friends. Oh, you just made me remember the sea of hobby OSes that you could find at OSDev and FASM (Flat Assembler) Forums. Still, your average Hardware enthusiast may not even care about those if they don't do something to enchant its Windows experience, or solve a particular issue. The reason why I mentioned Windows 3.1 was because there was a recent article about it in a non-extremely-niche website, whereas I don't recall the last time I heared anything about the others if you're not looking specifically for them in places that cater to hobbyst OS developers (I did mentioned Memtest, though). Embedding FreeDOS serves a purpose: It may allow you to perform a Software flash of either your Motherboard Firmware or a PCI Card without needing to make a booteable USB Flash Drive. I suppose that you could download a binary, copy it to a local disk ESP (EFI System Partition), then use embedded FreeDOS to read the file there to flash it, or do the same with a data-only USB Flash Drive. It could be redundant if you can do the same from the EFI Shell, though, which in some Motherboards is
[coreboot] Re: SuzyQable - ChromeOS Debug Cable
On Sat, Jan 18, 2020 at 12:46 AM Mike Banon wrote: > Is that something like a cable with two built-in FT232H chips ? (to > function as a USB dongle) > no, the CCD debug functionality is in the Google security chip (CR50) which detects the special debug cable (https://www.sparkfun.com/products/14746 -- schematics linked) on a specific port and then enables the features according to the CCD state (open/locked) ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: SuzyQable - ChromeOS Debug Cable
Is that something like a cable with two built-in FT232H chips ? (to function as a USB dongle) ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] A Hardware enthusiast view on the usefulness of open source Firmwares like Coreboot
Here it is: https://zirblazer.github.io/htmlfiles/coreboot.html?ver=123 I took my time to write the linked Wall of Text® with the purpose of educating/influencing Hardware enthusiasts communities about the need to push for open source Firmwares, and perhaps with even more luck, Motherboards for x86 platforms with open Hardware designs. These are my personal thoughts and nearly all the input I have on this matter. You will notice that there is a major difference regarding my approach and nearly everyone else that you have read talking about this matter previously. I'm not of the "INTEL ME/AMD PSP VIOLATES MY PRIVACY!1!1!1" and "THE NSA AND USA GOVERMENT ARE SPYING ON ME!" crowd. I have an actual agenda regarding functional issues where I think that an open source Firmware could kick propietary Firmware butt, and I cover it with enough detail as to drive that point. Sadly, after having spammed it around for two weeks, I got almost no feedback. I found that extremely dissapointing, as I believe that Hardware enthusiasts are perhaps the widest audience that would love to be able to freely tinker with the Firmware. I have been personally affected with Firmware related bugs, limitations or issues on all the computers I built for myself, so I fail to understand why there isn't far more people from these communities attemping to push an open source Firmware as a major Motherboard feature, more so considering how used we are to see Motherboard manufacturers failing to give the expected level of support for their products. So, when you do hit these Firmware issues, is like headbutting a solid brick wall. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: How can My linux kernel detect gpio or pinctrl on denverton platform ?
Hi, Looking at harcuvar board and denverton_ns SoC sources it looks like the GPIO controller is not defined in ACPI. It may be causing the probe to fail for pinctrl in Linux. There is simply no GPIO ASL code for denverton_ns. For example refer to soc/intel/skylake/acpi/gpio.asl. Regards, -- Michał Żygowski Firmware Engineer http://3mdeb.com | @3mdeb_com On 15.01.2020 15:13, cooljason0...@gmail.com wrote: > Hi, > > Linux kernel- 4.14. confing debug gpio and pinctrl-denverton, pinctrl-intel. > Coreboot-4.10 using denverton and harcuvar. > However, linux kernel not dectect gpio and pinctrl. > Thanks. > Jason > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Booting Linux kernel with nosmp required on Lenovo T60 (ATI/AMD)
Hi, Well my system have only 4.10-637 coreboot version, so I don't know if it is relevant. My Kontron 986LCD-M (supported by coreboot) does the SMP without a problem. Kernel 4.20.0-rc2 (I didn't see any problem with current slackware kernel too). GPU is radeon RX460, kernel parameters "amdgpu.ppfeaturemask=0xfffb amdgpu.dc=1 earlyprintk=serial,ttyS0,115200,keep pci=assign-busses,pcie_scan_all,realloc raid=noautodetect acpi_enforce_resources =lax video=1440x900MR fbcon=map:0 memory_corruption_check=0 resume=/dev/sda1 resume_offset=260096" (but there are most likely some redundant ones - accumulated from testing). Suspend to HDD doesn't work (I think). I've had to modify coreboot's devicetree as some superio devices requires to be defined even if not used (otherwise the resource allocator goes mad). Petr Dne 17. 01. 20 v 13:58 Paul Menzel napsal(a): > Dear coreboot folks, > > > On 2019-12-15 11:54, Paul Menzel wrote: > >> On the Lenovo T60 (with AMD/ATI graphics) the Linux kernel (4.9, >> 4.19, 5.3, 5.4) hangs after starting user space. As SeaBIOS, GRUB, >> payloads and FreeDOS work, I tried to limit the number of CPUs, and >> booting Linux with `nosmp` gave me a booting system. It worked with >> older coreboot versions, so I think it’s a regression. I am able to >> reproduce this with coreboot 4.11 and 4.11-422-g1a5c3bb7fa. >> >> Is somebody else seeing this issue? Maybe on some i945 desktop board, >> so it would be easier to bisect? > > Just as an update, here is the description. > >> nosmp [SMP] Tells an SMP kernel to act as a UP kernel, >> and disable the IO APIC. legacy for "maxcpus=0". > > So, after seeing some IRC discussion in #coreb...@irc.freenode.net, > the tests below were done. > > System *boots* with one of: > > 1. maxcpus=0 (equivalent nosmp) > 2. maxcpus=1 > 3. nolapic (with e1000 warning about missing MSI-X > > System does *not* boot with one of: > > 1. maxcpus=2 > 2. noapic > > But first, it’d be great if other i945 device users could confirm > this. > > > Kind regards, > > Paul > > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Booting Linux kernel with nosmp required on Lenovo T60 (ATI/AMD)
Dear coreboot folks, On 2019-12-15 11:54, Paul Menzel wrote: > On the Lenovo T60 (with AMD/ATI graphics) the Linux kernel (4.9, > 4.19, 5.3, 5.4) hangs after starting user space. As SeaBIOS, GRUB, > payloads and FreeDOS work, I tried to limit the number of CPUs, and > booting Linux with `nosmp` gave me a booting system. It worked with > older coreboot versions, so I think it’s a regression. I am able to > reproduce this with coreboot 4.11 and 4.11-422-g1a5c3bb7fa. > > Is somebody else seeing this issue? Maybe on some i945 desktop board, > so it would be easier to bisect? Just as an update, here is the description. > nosmp [SMP] Tells an SMP kernel to act as a UP kernel, > and disable the IO APIC. legacy for "maxcpus=0". So, after seeing some IRC discussion in #coreb...@irc.freenode.net, the tests below were done. System *boots* with one of: 1. maxcpus=0 (equivalent nosmp) 2. maxcpus=1 3. nolapic (with e1000 warning about missing MSI-X System does *not* boot with one of: 1. maxcpus=2 2. noapic But first, it’d be great if other i945 device users could confirm this. Kind regards, Paul smime.p7s Description: S/MIME Cryptographic Signature ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: A Hardware enthusiast view on the usefulness of open source Firmwares like Coreboot
Good day Zir, It would've been helpful if your article had your e-mail in the end of it or a reply form - I've stumbled upon your article some time ago, but didn't find a quick way to share my feedback and got distracted by something else, maybe the others did too... 1) Thanks for describing CH341A, as it is a simple, reliable and affordable flashrom-supported SPI programmer. However, there's a problem that some CH341A give 5V voltage instead of 3.3V - although, as the time passes, these incorrect CH341A models will disappear, it could be worth mentioning this problem so that your reader will test the voltage of his CH341A before using it. By the way, even the "incorrect ones" may be fixed by a small hardware mod. 2) I didn't like your opinion of SeaBIOS, that it's just "mostly used to support legacy OSes and PCIe Cards with Option ROMs that have only a BIOS compatible Device Firmware." Perhaps this statement has been affected by your personal Tianocore-mostly experience - however, if you'd look at the board_status reports contributed by our community, ~90% of them have SeaBIOS as payload, and judging by the mailing list threads I find these stats pretty close to reality. SeaBIOS popularity is well justified by its' simplicity: less than 50k lines of good readable code, weights a few KB and "just works". Tianocore is quite bloated in comparison and seems to be more difficult to configure and get it working properly. Maybe that's why SeaBIOS is still a default coreboot payload - and really, there's nothing Tianocore can do that SeaBIOS theoretically couldn't. I've been using coreboot for a few years and haven't found any good enough reason to switch from SeaBIOS to Tianocore. You may argue that UEFI is much more popular nowadays, however it's only because the newer PCs had UEFI preinstalled; nobody asked the people if they want UEFI or not, this choice has been kinda forced upon them. Also, I haven't encountered any UEFI-only OS yet; if such an OS would be created one day - maybe just for the purpose of being the first UEFI-only "modern OS" - well that's an intentional reduction of potential userbase for no valid technical reasons. 3) It a bit puzzles me why you didn't mention any interesting floppy-based OS like Kolibri in the "floppy part". Windows 3.1 may seem interesting, however there wouldn't be any updates or software for it, it's stuck at whatever level has been reached during its' lifetime, while a lot of the other floppy OS projects - i.e. some of those I'm offering with csb_patcher.sh script (KolibriOS, FreeDOS, MichalOS, Snowdrop, Fiwix, Memtest, Tatos, Plop, FloppyBird) - are still being developed. At least you've mentioned a FreeDOS, but there are many interesting floppy projects - including those with a minimalistic Linux environment, and PicoBSD - which haven't been mentioned even in brief. Perhaps that's because your Tianocore payload does not support the floppies, so you didn't have a chance to explore this wonderful world personally. I really feel this part is a bit short and could be really expanded. In example, if KolibriOS supports your Ethernet controller, you could access the Internet right from your BIOS and IRCC chat with your friends. 4) By attempting to stay further from "anti-spy crowd", it seems like the information security advantage of coreboot has been almost skipped - i.e. Ctrl+F by Computrace gives no results. Maybe it's not a big loss, considering this security part is well covered at the other articles - however, it may be worth considering expanding this part if you'd like your article to be truly wholesome. 5) Try to shrink your "wall of text" while preserving as much information as possible. Aside from the issues above, your article really seems great and well-written, but it takes some hard work to get through it instead of TLDR hops between the interesting parts. If you could succeed in compressing, will be much easier to read. That's just my personal opinion, thank you for a good read and I wish you the best in your adventures. Best regards, Mike ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] SuzyQable - ChromeOS Debug Cable
Hello! Does the thing at https://www.sparkfun.com/products/14746 create a response with regards to anyone? On their documents tab they present the now wrong link where to find more information about how the cable works. And of course they also link to those devices that might be interested in working with it. Call me curious, but I'm interested in seeing how many of us recognize the unique nature of it. - Gregg C Levine gregg.drw...@gmail.com "This signature fought the Time Wars, time and again." ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: SuzyQable - ChromeOS Debug Cable
sorry, what exactly is your question? I have one of these cables, works great for flashing/debugging Chromebooks via CCD the updated Chromium CCD docs can be found at: https://chromium.googlesource.com/chromiumos/platform/ec/+/master/docs/case_closed_debugging_cr50.md On Fri, Jan 17, 2020 at 11:33 AM Gregg Levine wrote: > Hello! > Does the thing at https://www.sparkfun.com/products/14746 create a > response with regards to anyone? > > On their documents tab they present the now wrong link where to find > more information about how the cable works. And of course they also > link to those devices that might be interested in working with it. > > Call me curious, but I'm interested in seeing how many of us recognize > the unique nature of it. > - > Gregg C Levine gregg.drw...@gmail.com > "This signature fought the Time Wars, time and again." > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
