coreboot December 2017

coreboot@coreboot.org

68 participants
177 discussions

Re: [coreboot] G505s with Coreboot unable to run any version of Qubes
by Ivan Ivanov 30 Dec '17

30 Dec '17

Hi Emil, thank you very much for your report. Regarding Qubes 3.2 : at the Qubes HCL list I wrote: "after Qubes R3.2 installation it cant boot - cant reach GRUB Boot Menu because MBR (or GRUB) is corrupted. Use grub2-install to fix it (read more) Everything else is OK " https://groups.google.com/forum/#!msg/qubes-users/TS1zfKZ7q8w/JQFkVF4xBgAJ If you fix your GRUB as described ^^^ you may be able to finally boot Qubes 3.2 Please test it and let me know the results Live 3.1 was buggy, full 3.1 would have worked. Haven't tested 4.0 - can't speak about it Best regards, Ivan 2017-12-28 1:19 GMT+03:00 Emil Novik via coreboot <coreboot(a)coreboot.org>: > Hey, I'm having some heavy trouble getting my laptop to run Qubes and I > first thought I was having issues with the OS. But after digging into the > logs I managed to get(crashes too early during boot to get any persistent > logs, had to write most by hand) it feels more like an issue with my > Coreboot built. > > So there are the details : > - G505s with integrated HD 8650G + discrete R5 M230 graphics. > - Coreboot 4.6-2477-g6ab3edac3c-dirty with processor microcode patch > (change-ID: Ibbfee47ce1d5081640d6924e2b12f5213a7fcadb). > - Runs Debian Stretch fine. > - Fails to start Qubes 3.2 / 4.0 rc3 / Live 3.1. > - I added the vgabios.rom for the integrated card with menuconfig and the > one for the discrete card with cbfstool. > - Coreboot.rom, .config and full make output as attachment. > > > Some more error data I gathered from coreinfo's Bootlog : > > Failed to enable LTR for dev = PCI: 01:00.0 > Failed to enable LTR for dev = PCI: 02:00.0 > ... > I2C: 01:50 missing read_resources > I2C: 01:51 missing read_resources > PNP: 00ff.1 missing read_resources > ... > Warning: Can't write PCI_INTR 0xC00/0xC01 registers because > 'mainboard_picr_data' or 'mainboard_intr_data' tables are NULL > Warning: Can't write PCI IRQ assignments because 'mainboard_pirq_data' > structure does not exist > ... > ASSERTION ERROR: file > 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 > ASSERTION ERROR: file > 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 > ASSERTION ERROR: file > 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 > ASSERTION ERROR: file > 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 > ASSERTION ERROR: file > 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 > ASSERTION ERROR: file > 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 > ASSERTION ERROR: file > 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 > ASSERTION ERROR: file > 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 > ASSERTION ERROR: file > 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 > ASSERTION ERROR: file > 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 > ASSERTION ERROR: file > 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 > ASSERTION ERROR: file > 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 > ASSERTION ERROR: file > 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 > ASSERTION ERROR: file > 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 > ASSERTION ERROR: file > 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 > ASSERTION ERROR: file > 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 > ASSERTION ERROR: file > 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 > ASSERTION ERROR: file > 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 > ... > Manufacturer: ef > SF: Detected W25Q32 with sector size 0x1000, total 0x400000 > ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425 > ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425 > ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425 > ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425 > Manufacturer: ef > SF: Detected W25Q32 with sector size 0x1000, total 0x400000 > ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425 > ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425 > ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425 > ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425 > ASSERTION ERROR: file 'src/drivers/amd/agesa/state_machine.c', line 309 > ... > EEPROM not found > EEPROM not found > EEPROM not found > EEPROM not found > EEPROM not found > EEPROM not found > EEPROM not found > ... > I2C: 01:50 (unknown) > I2C: 01:51 (unknown) > ... > APIC: 11 (unknown) > APIC: 12 (unknown) > APIC: 13 (unknown) > PCI: 01:00.0 (unknown) > PCI: 02:00.0 (unknown) > PNP: 00ff.0 (unknown) > > > "..." are parts I didn't write down as they didn't show any obvious > errors(but I'm bad at seeing them) and it would take me a loooong time to > write down the full log as I can't export it as far as I know, if you need > any more information from it, I can write down any part missing. > > Output of "cbfstool coreboot.rom print" after I added the optionrom for the > R5 M230 discrete graphic card : > Name Offset Type Size Comp > cbfs master header 0x0 cbfs header 32 none > fallback/ramstage 0x80 stage 129247 none > config 0x1f9c0 raw 263 none > revision 0x1fb00 raw 582 none > payload_revision 0x1fd80 raw 239 none > apu/amdfw 0x1fec0 raw 131072 none > fallback/romstage 0x3ff00 stage 320556 none > cmos_layout.bin 0x8e3c0 cmos_layout 1164 none > pci1002,990b.rom 0x8e8c0 optionrom 61952 none > fallback/postcar 0x9db40 stage 13268 none > fallback/dsdt.aml 0xa0f80 raw 9435 none > img/coreinfo 0xa34c0 payload 102712 none > img/nvramcui 0xbc640 payload 141628 none > fallback/payload 0xdefc0 payload 67370 none > payload_config 0xef740 raw 1611 none > pci1002,6665.rom 0xefe00 optionrom 32768 none > (empty) 0xf7e80 null 3112984 none > s3nv 0x3efec0 raw 32768 none > (empty) 0x3f7f00 null 31192 none > bootblock 0x3ff900 bootblock 1424 none > > What happened when I tried to boot each version of Qubes : > > Live 3.1 : > mce: Unable to init device /dev/mcelog (rc: -16) > radeon 000:04:00:0: Invalid ROM contents > radeon 000:04:00:0: Invalid ROM contents > [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM > radeon 000:04:00:0: Fatal error during GPU init > [TTM] Memory type 3 has not been initialized > SQUASHFS error: squashfs_read_data failed to read block 0x5cb75d68 > SQUASHFS error: Unable to read data cache entry [0x5cb75d68] > SQUASHFS error: Unable to read page, block 0x5cb75d68, size af0 > SQUASHFS error: Unable to read data cache entry [0x5cb75d68] > SQUASHFS error: Unable to read page, block 0x5cb75d68, size af0 > EXT4-fs error (device dm-0): ext4_find_entry:1289: inode #41642: comm > plymouthd: reading directory lblock 0 > (Hangs at the Qubes graphical loading screen, with loading bar full.) > > 3.2 (Install looked fine) : > Hangs at "Booting from Hard Disk..." in SeaBIOS on every try > > 4.0 rc3 : > [ FAILED ] Failed to start Load Kernel Modules. > ... > [ OK ] Reached target Basic System. > (Hangs for about 10secs, followed by 5s of black screen) > BUG: Unable to handle NULL pointer dereference at (null) > (followed by a lot of output likely concerning the error and quickly back to > boot) > Sadly too much output and disappearing too fast for me to get anything out > of it if all I can do is read and type to export it. Tried Ctrl+S/Ctrl+Q to > "pause" it but nope, also checked that the laptop should not reboot in case > of kernel panic but it still does... > > Thanks to anyone that could help me find what's wrong and how to fix it :) > > --- > Emil Novik > > > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Doubt about SPD init in Skylake
by 王翔 30 Dec '17

30 Dec '17

The system must initialize some arrays before initializing the SPD in order to execute FspMemoryInit. I do not know what these arrays do, and how do I get these values when porting new motherboard. These codes exist on the SKYLAKE platform which using FSP2.0. Call path : fsp_memory_init->do_fsp_memory_init->platform_fsp_memory_init_params_cb->mainboard_memory_init_params array list : FSPM_UPD->FspmConfig->DqByteMapCh0 FSPM_UPD->FspmConfig->DqByteMapCh1 FSPM_UPD->FspmConfig->DqsMapCpu2DramCh0 FSPM_UPD->FspmConfig->DqsMapCpu2DramCh1 FSPM_UPD->FspmConfig->RcompResistor FSPM_UPD->FspmConfig->RcompTarget If you can help me extremely grateful ! ! ! ------------------ 王翔安全研究员广州市腾御安信息科技有限公司广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024

3 2

Re: [coreboot] BDX-DE PCI init fail
by Zoran Stojsavljevic 30 Dec '17

30 Dec '17

> I still have same issue even tried to comment out > the 1f.3 device in ./src/mainboard/intel/camel- > backmountain_fsp/devicetree.cb then rebuild coreboot. You wrote that you submitted the log. Is this the full log? I doubt. I do NOT see physical memory layout as well as MTRR layout. Could you, please, submit the full/complete log? Which payload are you using? SeaBIOS? Thank you, Zoran On Fri, Dec 29, 2017 at 5:58 AM, Hilbert Tu(杜睿哲_Pegatron) <Hilbert_Tu(a)pegatroncorp.com> wrote: > Hi David, > > > > Thanks for your information. > > I still have same issue even tried to comment out the 1f.3 device in > ./src/mainboard/intel/camelbackmountain_fsp/devicetree.cb then rebuild > coreboot. > > Could you let me know how to do that? > > > > -Hilbert > > > > From: David Hendricks [mailto:david.hendricks@gmail.com] > Sent: Friday, December 29, 2017 9:46 AM > To: Hilbert Tu(杜睿哲_Pegatron) > Cc: coreboot(a)coreboot.org > Subject: Re: [coreboot] BDX-DE PCI init fail > > > > Hi Hilbert, > > Have you had any luck? I have a board with a similar problem. Commenting out > the entry for device 1f.3 in devicetree.cb seemed to help (I copied > src/mainboard/intel/camelbackmountain_fsp for my project). > > > > On Wed, Dec 27, 2017 at 2:17 AM, Hilbert Tu(杜睿哲_Pegatron) > <Hilbert_Tu(a)pegatroncorp.com> wrote: > > Hi, > > > > I am porting coreboot on Intel BDX-DE platform and it gets stuck when init > PCI 00:1f.3. This device should be SMBus, serial management bus. But I don’t > know why this happened. Does anyone can give me some hint? Attached is my > boot up log. Thanks in advance. > > > > -Hilbert > > This e-mail and its attachment may contain information that is confidential > or privileged, and are solely for the use of the individual to whom this > e-mail is addressed. If you are not the intended recipient or have received > it accidentally, please immediately notify the sender by reply e-mail and > destroy all copies of this email and its attachment. Please be advised that > any unauthorized use, disclosure, distribution or copying of this email or > its attachment is strictly prohibited. > 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。 > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot > > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system
by Lewis, Ian (Microstar Laboratories) 30 Dec '17

30 Dec '17

ron minnich wrote > how are you different in this case from Motorola, who had to put their linux source on a web site? companies resold motorola phones. Or the many switch vendors who sell network switches that run coreboot/linuxbios? or irobot, who use it still on the packbot? > Or how are you different from just about every vendor that sells embedded ARM boards that run u-boot? We are, because of the nature of our customers, very different from all of your example use cases, except perhaps the people who sell embedded ARM boards. Motorola phone: They sell their product to people (well, companies) who set out to make GPL licensed products, typically for a large market. The customer of Motorola makes no modifications to the Motorola phone, or at least no significant modifications. There is no difficulty for such a prospective reseller of such a product to comply with GPL. There are lots of sales to cover the initial costs. But, most importantly, the Motorola reseller is typically not making a new product. They are reselling the Motorola product, perhaps as a private label, to an end user who will receive Motorola's packaging and notifications (at first boot, perhaps - I do not actually know how). As far as I can see (well, guess), network switch purchasers are almost always end users (corporate or personal). And, it is my guess - after spending the past week and a half trying to understand GPL's implications - that there are many, many small resellers of network switches in complete systems that are out of compliance with GPL because they do not even think about the issue. As a side note, our customers are a bit like this kind of reseller of a complete system that happens to contain a network switch, though the analogy is not great because the network switch is in some sense a complete system, while what we make is not. Still, if I sell a network installation to a small shop, and I fail to give the recipient of my system that includes that switch the GPL license and a place to get the source code, I am in violation of GPL. I do not want this to happen to my customers. iRobot is making an end use product, not a product that someone else is going to take and build into something very different from the iRobot product. Again, a lot like Motorola and their phone. If NewEgg sells an iRobot product, they just pass through the iRobot package - with everything in it - so (I think, though I am not quite sure) they are in compliance as long as iRobot was. I suspect that NewEgg just assumes that iRobot got their licensing right. My reading of GPL is that NewEgg actually has their own obligation under GPL separate from iRobot's, but I would guess they do not worry about it much. They are not making anything. They are just reselling. ARM boards that run u-boot: The target customer base is aiming to take advantage of the ARM board to make a product at a low cost (typically), and most of them are well aware of GPL and its implications. This is somewhat like us. Some of the uses have very small markets - as most of our customers do. But, we do not have a customer base that is aware of GPL and intend to use it from the beginning. A typical customer of ours might sell 50 systems in a year and consider that a very good year. They sell each system for a lot of money (typically) and they are not spending a lot of time thinking about licensing. Most (a guess) probably do not even have an in-house counsel, let alone a license management department. Asking them to take on new licensing obligations is an impediment to adoption of our product. How many of our customers already easily deal with GPL, I do not know, but I doubt it is a big fraction. You may not see that as a big issue, and if you were our customer it would not be a big issue for you. But, many of our customers hardly even formally license their own products to their customers; they go install them. My point is that our market is not an end use market where the licensing almost does not matter once the end user has the product in hand. And, it is not a big OEM market where the licensing is a triviality. And, our market is not Makers, say, who know - and want to be - buying GPL licensed products so that they can hack around in them. Our market is for small OEMs - or OEMs who work inside big companies, but with small customer bases, which is even worse because here there is a legal department, but our customer has next to no chance of getting their attention - who make low volume specialized products - an industrial turbine monitoring system, say - that typically sell infrequently for relatively high prices and they want our part of the system to just work with as little thought as possible. Their focus is on their application area. If we can help them without getting in their way, they may use us. If we look like a nuisance, they will go elsewhere (maybe to an ARM board and building their own hardware for measurement - but then it is not my job to see that they properly handle GPL). Unlike someone selling an ARM board, that part of our code happens to be GPL is of no interest to these customers at all (that is, it is not a reason to adopt us, as it might be if we made ARM boards). And, licensing is not something a typical customer of ours wants to think about (not that the ARM board customer wants to either). The ARM board manufacturer, based on a lot of experience on my part, only worries about their own compliance. They do not worry about their customer's compliance as we do. If we can make it so that our customers do not have to think about it, then there is likely not much of a problem. But, so far, it is not at all clear to me that we can reach that level of transparency. To try to clarify: I do not want to just comply with GPL. I easily see how to do that by now. I want to make it so that my customer does not have to think about it when they sell their system. If I try to make them think about it, I am about certain that will be a reason to not use our product. You might not believe that, but I do. The issue is one of marketing and selling, not of engineering or even law. > Also, why do you mention GPL V3? Coreboot is 2 or later. > What about the many systems that run all kinds of GPL V2 embedded software? What's different between you and them? The module we are using uses both Coreboot (GPLv2) and SeaBIOS (GPLv3). > What I'm trying to say is that problem seems to have been solved. I get the feeling you are new to dealing with this question, and are trying to solve it yourself, without talking to people who have already solved it? I am not trying to solve the problem by myself. I did not just read the GPL license and try to determine its implications. I have been, for the past week and a half, reading materials produced by people who do understand GPL and have successfully used it. I have looked for products like ours where such licensing has been employed where the customer base was developers who are not open source developers. I have yet to find a good match, by which I do not mean to imply there is not one around. I am on this group exactly to learn what our obligations are and what we need to do to make a product that would work for our customer base using GPL licensing.

1 0

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system
by ron minnich 30 Dec '17

30 Dec '17

On Fri, Dec 29, 2017 at 5:20 PM Lewis, Ian (Microstar Laboratories) < ilewis(a)mstarlabs.com> wrote: > > > The real problem comes with our potential OEM and VAR customers - the most > valuable customers for our potential product from a turnover perspective. > If we attempt to sell them a GPL licensed product, we oblige them to > conform with GPL licensing to be able to sell their systems to their > customers. I am about certain that, unless we make it trivially easy to > conform, this will put off a good fraction of our prospective customers. > Even if we make it trivially easy to conform, unless it is almost > automatic, I am concerned that it may still put off too many potential > OEM/VAR customers. And, our customers would not be behaving in an > nonsensical way. Many of them employ no firmware engineers who they could > use to determine whether they were actually in compliance with GPL, even if > they did not mind the added licensing on their product. > how are you different in this case from Motorola, who had to put their linux source on a web site? companies resold motorola phones. Or the many switch vendors who sell network switches that run coreboot/linuxbios? or irobot, who use it still on the packbot? Or how are you different from just about every vendor that sells embedded ARM boards that run u-boot? Also, why do you mention GPL V3? Coreboot is 2 or later. What about the many systems that run all kinds of GPL V2 embedded software? What's different between you and them? What I'm trying to say is that problem seems to have been solved. I get the feeling you are new to dealing with this question, and are trying to solve it yourself, without talking to people who have already solved it? thanks ron

1 0

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system
by Lewis, Ian (Microstar Laboratories) 30 Dec '17

30 Dec '17

ron minnich wrote: >> First we need to figure out whether we are willing/able to move forward with a product that includes GPL licensed code at all. > this part I do not understand. There are so many embedded systems out there with GPL code in firmware, what is the unique property of your product that makes it impractical? The issue for us is that most of our customers are not end users. Well, actually, we have many, many more end use customers than reseller customers, but end use customers represent a small fraction of our product sales. The bulk of our products sales are to OEM (Original Equipment Manufacturer) or VAR (Value Added Reseller - that is, consultant) customers who resell a system of their own that contains our product as a component. GPL creates no particular problem for us when we sell to a university - one of our main sources of end-use customers - that will use our device to perform specific experiments in their own lab. We would need no more than a piece of paper in the box plus a medium to carry the source code that corresponds to the firmware (or a website, for that matter). Since our end user in this case would build their setup and run it themselves and never distribute it, there would be next to no issue once we met our obligations under GPL. Though, even here I have a bit of a concern because I read GPLv3 to obligate us to provide our customer a way to replace the firmware, not just provide the source for it, and currently we do not have an external means to allow this on any of our products. Still, this is more of a technical issue than a legal or marketing one. We would most likely not lose a single end use customer sale because our product included a GPL license for a portion of the system. The real problem comes with our potential OEM and VAR customers - the most valuable customers for our potential product from a turnover perspective. If we attempt to sell them a GPL licensed product, we oblige them to conform with GPL licensing to be able to sell their systems to their customers. I am about certain that, unless we make it trivially easy to conform, this will put off a good fraction of our prospective customers. Even if we make it trivially easy to conform, unless it is almost automatic, I am concerned that it may still put off too many potential OEM/VAR customers. And, our customers would not be behaving in an nonsensical way. Many of them employ no firmware engineers who they could use to determine whether they were actually in compliance with GPL, even if they did not mind the added licensing on their product. So, the root issue here is that - because of the nature of our customers - we are not just putting ourselves under GPL. We are putting our prospective customers under GPL too, and that will - I guarantee it - put off some fraction of our potential best customers. What I do not know is what fraction that would be and whether we want to find out. Ian

1 0

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system
by ron minnich 30 Dec '17

30 Dec '17

On Fri, Dec 29, 2017 at 3:55 PM Lewis, Ian (Microstar Laboratories) < ilewis(a)mstarlabs.com> wrote: > > > > First we need to figure out whether we are willing/able to move forward > with a product that includes GPL licensed code at all. > this part I do not understand. There are so many embedded systems out there with GPL code in firmware, what is the unique property of your product that makes it impractical?

1 0

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system
by Lewis, Ian (Microstar Laboratories) 29 Dec '17

29 Dec '17

Hello Ron, Thank you for the suggestion and the offer. The processor module is VEX-SOM from DMP/ICOP: http://www.icop.com.tw/en/product/System-On-Module-VEX-SOM/VEX-SOM.html, which runs a Vortex86EX processor. Your idea is a good one. However, I do not think it makes sense to separate the code yet. First we need to figure out whether we are willing/able to move forward with a product that includes GPL licensed code at all. It really is not ideal for our customer base no matter how you look at it. But, VEX-SOM is very attractive for us for a low-end product, and maybe attractive enough to be able to make sense of placing the GPL requirement on at least some of our customers. If you were willing, I would very much like to take advantage of your expertise to separate the relevant code if we do decide to move forward with a product. Ian From: ron minnich [mailto:rminnich@gmail.com] Sent: Friday, December 29, 2017 2:17 PM To: Lewis, Ian (Microstar Laboratories) Cc: Peter Stuge; coreboot(a)coreboot.org Subject: Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system suggestion: you might want to figure out what subset of the source you actually use in your product, i.e. what files are used in your build, then create a subset of the coreboot source tree containing only this files, then lzma -9 that file. I suspect it would be pretty small, but if you want to tell me what board this is I'm willing to give it a try. ron

1 0

Re: [coreboot] smd work
by Tim S 29 Dec '17

29 Dec '17

Personally I like hot air reflow for multi-pin parts. Something cheapish like an Ayoue works fine - I think Walmart has the 888A hot-air/solder-iron station listed for <$70 (I use the Ayoue 852 myself at home, because I have a very nice solder station already). The trick with hot air is not getting the air speed too high, do that and you'll start blowing off small SMD resistors and caps all over your workspace. Get it too hot and you scorch the plastic packaged parts. Can't beat hot air though for re-attaching parts, get some solder paste from (anywhere really), and put the paste in a small modeling or plastic gluing syringe, and under a decent magnification, you can apply solder paste directly to the bare cold pads (don't drink coffee that day). Drop the part on the paste (just like a pick an place machine), and it'll stick there with surface tension until you reflow (heat) the part. IMHO the nicest thing about this method is that even if you drop the part a bit off alignment, the surface tension of the heated paste will pull the legs onto the pads. There are good YouTube videos for this method. If you need to reattach a larger part like an IO controller or a chipset/BGA, you'll want to heat both sides of the board so it doesn't warp. Also for holding things in place you don't intend to remove, get some Kapton tape (the brownish-orange transparent stuff) and cover the "keep out" areas. Kapton sticks at temperatures up to 500°C is non-conductive, just make sure you let the board cool down again before you remove the tape, or you'll have tape covered in the parts you were trying not to remove... Get used to this stuff, the leg-less parts are becoming the norm in the thinner form factors especially. -Tim Date: Thu, 28 Dec 2017 17:47:54 +0000 > From: ron minnich <rminnich(a)gmail.com> > To: coreboot <coreboot(a)coreboot.org> > Subject: [coreboot] smd work > Message-ID: > <CAP6exY+K-9UJizGxQd3QJaOOw+XsaPR13sW44dPzasSQJKZUYg@mail. > gmail.com> > Content-Type: text/plain; charset="utf-8" > > A friend of mine wants to do some SPI rework. He wants a 16M part in his > chromebook, not 8M. (hmm, so do I). Given the huge expertise of this group, > I wonder if you have advice about equipment he should get. > > Soldering irons? hot air guns? magic wands? > > thanks > > ron >

1 0

Can someone submit a KCMA-D8 board status?
by Taiidan＠gmx.com 29 Dec '17

29 Dec '17

As it is almost identical to the KGPE-D16 I am sure it still works with the latest coreboot so I was wondering if someone could compile and submit a board status so that it doesn't get removed. It would be pretty silly for a year old $15K board port to end up removed. Thanks!

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot December 2017