Re: [coreboot] coreboot port for macbook2,1
Hallo, On Mon, Feb 03, 2014 at 10:16:30PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: CY8C24794-24LFXI My guess: it's part of keyboard + touchpad Do you already know which port is USBdebug one? Yes, I found out with a USB stick, dmesg and lsusb -t. Did you already test USB debug with dbgp? Yes, I tested USB debug for the Thinkpad X60, I assume it would work the same for Macbook. Um, there are much more 00's than for the Thinkpad X60. Not sure what this means Different firmware. Most likely less functions are on it (keyboard and touchpad are on USB and handled by another chip). You'll need to make directory ec/apple/h8 for it and no code from lenovo/h8 will be reusable. What about those Block Protect things? Forget them for now, you'll be flashing externally until you have working version anyway I updated the webpage about what I did ( http://macbook.donderklumpen.de/coreboot/ ). At the moment I am looking at x60's romstage.c because I'd plan to copy as much as possible from it. At the function static void ich7_enable_lpc(void) I got stuck. I can make some guesses, but don't know where the details are documented. If you could point me to any documentation, I'd love to read it. I tried ich7 datasheet and LPC Interface Specification but did not spot what the function ich7_enable_lpc does. By comparing the output of lspci -nnvvvxxx -s 00:1f.0 on the Thinkpad with coreboot and the Macbook with factory bios I get the following: on the Thinkpad $ lspci -nnvvvxxx -s 00:1f.0 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge [8086:27b9] (rev 02) Subsystem: Lenovo ThinkPad T60/R60 series [17aa:2009] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Capabilities: [e0] Vendor Specific Information: Len=0c ? Kernel driver in use: lpc_ich Kernel modules: intel_rng, lpc_ich, leds_ss4200 00: 86 80 b9 27 07 00 10 02 02 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 aa 17 09 20 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 40: 01 05 00 00 80 00 00 00 81 04 00 00 10 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 80 80 80 80 d0 00 00 00 80 80 80 80 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 10 02 0d 1f 01 16 7c 00 e1 15 0c 00 81 16 1c 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: ac 06 00 00 30 00 00 00 13 1c 0a 00 00 03 00 00 b0: 00 00 f0 00 00 00 00 00 00 00 02 0a 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 33 22 11 00 67 45 00 00 cf ff 00 00 08 00 00 00 e0: 09 00 0c 10 b4 02 24 17 00 00 00 00 00 00 00 00 f0: 01 c0 d1 fe 00 00 00 00 86 0f 02 00 00 00 00 00 and on the Macbook $ lspci -nnvvvxxx -s 00:1f.0 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge [8086:27b9] (rev 02) Subsystem: Intel Corporation Device [8086:7270] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Capabilities: [e0] Vendor Specific Information: Len=0c ? Kernel driver in use: lpc_ich Kernel modules: intel_rng, lpc_ich, leds_ss4200 00: 86 80 b9 27 07 00 10 02 02 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 70 72 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 40: 01 04 00 00 80 00 00 00 01 05 00 00 10 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 80 80 80 80 d0 00 00 00 80 80 80 80 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 10 00 07 38 81 06 0c 00 41 16 0c 00 00 00 00 00 90: 01 03 1c 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 04 02 00 00 01 00 00 00 13 1c 0a 00 00 03 00 00 b0: 00 00 f0 00 00 00 00 00 08 80 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 33 22 00 00 67 45 00 00 00 ff 00 00 00 00 00 00 e0: 09 00 0c 10 b4 02 24 17 00 00 00 00 00 00 00 00 f0: 01 c0 d1 fe 00 00 00 00 86 0f 02 00 00 00 00 00 In the Thinkpad output I can spot the values written by coreboot: 0xd0 at 0x64 // Enable Serial IRQ, this is the same for what the Macbook outputs, but where can I read that this enables serial IRQ? 0x0210 and 0x1f0d at 0x80 and 0x82 // decode ranges, the Macbook outputs different values here 0x1601, 0x007c, 0x15e1, 0x000c, 0x1681, 0x001c from 0x84 to 0x8e // the Thinkpad has three ranges while the Macbook seems to have two ranges only with differnt values. So how would I modify the ich7_enable_lpc function? Should I try to reproduce what the factory bios sets? Other from the values set in this function a few
Re: [coreboot] coreboot port for macbook2,1
On 08.02.2014 15:27, Mono wrote: Hallo, On Mon, Feb 03, 2014 at 10:16:30PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: CY8C24794-24LFXI My guess: it's part of keyboard + touchpad Do you already know which port is USBdebug one? Yes, I found out with a USB stick, dmesg and lsusb -t. Did you already test USB debug with dbgp? Yes, I tested USB debug for the Thinkpad X60, I assume it would work the same for Macbook. I meant that you can use debug port as early printk device. It's recommended to check dongle this way if your dongle is the real dbgp dongle. Um, there are much more 00's than for the Thinkpad X60. Not sure what this means Different firmware. Most likely less functions are on it (keyboard and touchpad are on USB and handled by another chip). You'll need to make directory ec/apple/h8 for it and no code from lenovo/h8 will be reusable. What about those Block Protect things? Forget them for now, you'll be flashing externally until you have working version anyway I updated the webpage about what I did ( http://macbook.donderklumpen.de/coreboot/ ). At the moment I am looking at x60's romstage.c because I'd plan to copy as much as possible from it. At the function static void ich7_enable_lpc(void) I got stuck. I can make some guesses, but don't know where the details are documented. If you could point me to any documentation, I'd love to read it. I tried ich7 datasheet and LPC Interface Specification but did not spot what the function ich7_enable_lpc does. By comparing the output of lspci -nnvvvxxx -s 00:1f.0 on the Thinkpad with coreboot and the Macbook with factory bios I get the following: on the Thinkpad $ lspci -nnvvvxxx -s 00:1f.0 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge [8086:27b9] (rev 02) Subsystem: Lenovo ThinkPad T60/R60 series [17aa:2009] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Capabilities: [e0] Vendor Specific Information: Len=0c ? Kernel driver in use: lpc_ich Kernel modules: intel_rng, lpc_ich, leds_ss4200 00: 86 80 b9 27 07 00 10 02 02 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 aa 17 09 20 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 40: 01 05 00 00 80 00 00 00 81 04 00 00 10 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 80 80 80 80 d0 00 00 00 80 80 80 80 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 10 02 0d 1f 01 16 7c 00 e1 15 0c 00 81 16 1c 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: ac 06 00 00 30 00 00 00 13 1c 0a 00 00 03 00 00 b0: 00 00 f0 00 00 00 00 00 00 00 02 0a 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 33 22 11 00 67 45 00 00 cf ff 00 00 08 00 00 00 e0: 09 00 0c 10 b4 02 24 17 00 00 00 00 00 00 00 00 f0: 01 c0 d1 fe 00 00 00 00 86 0f 02 00 00 00 00 00 and on the Macbook $ lspci -nnvvvxxx -s 00:1f.0 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge [8086:27b9] (rev 02) Subsystem: Intel Corporation Device [8086:7270] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Capabilities: [e0] Vendor Specific Information: Len=0c ? Kernel driver in use: lpc_ich Kernel modules: intel_rng, lpc_ich, leds_ss4200 00: 86 80 b9 27 07 00 10 02 02 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 70 72 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 40: 01 04 00 00 80 00 00 00 01 05 00 00 10 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 80 80 80 80 d0 00 00 00 80 80 80 80 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 10 00 07 38 81 06 0c 00 41 16 0c 00 00 00 00 00 90: 01 03 1c 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 04 02 00 00 01 00 00 00 13 1c 0a 00 00 03 00 00 b0: 00 00 f0 00 00 00 00 00 08 80 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 33 22 00 00 67 45 00 00 00 ff 00 00 00 00 00 00 e0: 09 00 0c 10 b4 02 24 17 00 00 00 00 00 00 00 00 f0: 01 c0 d1 fe 00 00 00 00 86 0f 02 00 00 00 00 00 In the Thinkpad output I can spot the values written by coreboot: 0xd0 at 0x64 // Enable Serial IRQ, this is the same for what the Macbook outputs, but where can I read that this enables serial IRQ? 0x0210 and 0x1f0d at 0x80 and 0x82 // decode ranges, the Macbook outputs different values here 0x1601, 0x007c, 0x15e1, 0x000c, 0x1681, 0x001c from 0x84 to 0x8e // the Thinkpad has three ranges
Re: [coreboot] HP Chromebook 14 (Falco)
ron minnich wrote: That sounds like upstream has failed completely. there is a delta in time between when it is working in the chromium repo and it makes it to upstream. .. We've always had this situation. It's not new. That just means that we haven't improved in a very long time. :\ It's just plain wrong to characterize this as a failure. I disagree. I do think it means that the project isn't fitting its contributors so well. Note that I am explicitly not saying and not thinking that it is a failure of any contributor. If the project could change to work somehow differently and that would help contributors then I think that's something we should consider identifying and doing. It's a natural consequence of the fact that companies can't always immediately push all their work upstream. What's the difference from Linux kernel development again? Expecting anything else is unrealistic. I don't think expectations are too usefule but I think it's what we should strive towards? //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] HP Chromebook 14 (Falco)
On Saturday, February 08, 2014 05:30:38 PM Peter Stuge wrote: If the project could change to work somehow differently and that would help contributors then I think that's something we should consider identifying and doing. Allow git merging. Forced cherry-picking is a PITA for almost everybody. The patches would still go through the same review process, but once the branch is go, the entire branch gets merged at once. Objections? It's a natural consequence of the fact that companies can't always immediately push all their work upstream. What's the difference from Linux kernel development again? See @above. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] HP Chromebook 14 (Falco)
Am Samstag, den 08.02.2014, 13:23 -0600 schrieb mrnuke: Allow git merging. Forced cherry-picking is a PITA for almost everybody. The patches would still go through the same review process, but once the branch is go, the entire branch gets merged at once. Objections? cherry-pick was chosen because it's the only mode where gerrit adds review information to the commit message. merges could potentially provide the same (in the merge commit), but they currently don't. Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] HP Chromebook 14 (Falco)
On Sat, Feb 8, 2014 at 8:30 AM, Peter Stuge pe...@stuge.se wrote: ron minnich wrote: I disagree. I do think it means that the project isn't fitting its contributors so well. Note that I am explicitly not saying and not thinking that it is a failure of any contributor. If you have some idea, then propose it. Best to propose something then just say this is wrong. If the project could change to work somehow differently and that would help contributors then I think that's something we should consider identifying and doing. who is the we here? Who identifies, and what do they do? And how do you manage the fact that companies may do development that for a number of reasons can not be released immediately? It's a natural consequence of the fact that companies can't always immediately push all their work upstream. What's the difference from Linux kernel development again? Nothing. Most companies I know of that use Linux, and contribute to upstream, deal with the issue of upstream vs. what is done in the company and the time delay involved. They have the same time delta issue with their internal patches vs. upstream. So we're not different. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] HP Chromebook 14 (Falco)
Hello! For what's worth since at the moment I'm a spectator and sometimes comments maker, I agree. Once when trying to build a kernel that was closer to the term unique rather then the generic one that normally traveled with one of my systems, I came across references to certain items that had Google's fingerprints on it. I asked about it here, and sure enough the response was that it was invented for the Google servers, and was sent as contribution to the Linux Kernel community. I wasn't able to make my unique kernel work, but it was an interesting job. And I'm still interested in figuring out further how I can contribute to this particular example of software running hardware properly. - Gregg C Levine gregg.drw...@gmail.com This signature fought the Time Wars, time and again. On Sat, Feb 8, 2014 at 4:03 PM, ron minnich rminn...@gmail.com wrote: On Sat, Feb 8, 2014 at 8:30 AM, Peter Stuge pe...@stuge.se wrote: ron minnich wrote: I disagree. I do think it means that the project isn't fitting its contributors so well. Note that I am explicitly not saying and not thinking that it is a failure of any contributor. If you have some idea, then propose it. Best to propose something then just say this is wrong. If the project could change to work somehow differently and that would help contributors then I think that's something we should consider identifying and doing. who is the we here? Who identifies, and what do they do? And how do you manage the fact that companies may do development that for a number of reasons can not be released immediately? It's a natural consequence of the fact that companies can't always immediately push all their work upstream. What's the difference from Linux kernel development again? Nothing. Most companies I know of that use Linux, and contribute to upstream, deal with the issue of upstream vs. what is done in the company and the time delay involved. They have the same time delta issue with their internal patches vs. upstream. So we're not different. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] HP Chromebook 14 (Falco)
On Sat, Feb 8, 2014 at 2:01 PM, Gregg Levine gregg.drw...@gmail.com wrote: Once when trying to build a kernel that was closer to the term unique rather then the generic one that normally traveled with one of my systems, I came across references to certain items that had Google's fingerprints on it. I asked about it here, and sure enough the response was that it was invented for the Google servers, and was sent as contribution to the Linux Kernel community. Which pretty much makes my point; that code was doubtless in use for quite some time before release. It's the way it works, not just at Google. Companies develop and perfect this stuff, and release comes later, and upstreaming is never a small effort. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] LinuxTag in Berlin from May 8–10, 2014
Dear coreboot folks, just a short announcement that after FOSDEM last weekend the next free software event (in Europe(?)) is going to be LinuxTag in Berlin from May 8–10, 2014. The location is going to be different this year. Since several years it won’t be happening at Messe Berlin but at STATION BERLIN [2]. So please mark that in your calender and let’s see what we can come up with coreboot wise for that event. Thanks, Paul [1] http://linuxtag.de/2014/en/ [2] http://www.station-berlin.de/en/location_directions/location.html signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] LinuxTag in Berlin from May 8-10, 2014
I hope it is a different group running it. If it's the same group, prepare for frustration in the arrangements ... ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] LinuxTag in Berlin from May 8-10, 2014
ron minnich wrote: I hope it is a different group running it. If it's the same group, prepare for frustration in the arrangements ... I've been taking coreboot to LinuxTag since 2007 and haven't had too many issues; the organizers do a good job, but they're all volunteers. Previous years Messe Berlin (the fairground company) has been sponsoring LinuxTag with exhibition halls and booth furniture. This year it's a different location and Messe Berlin isn't involved at all. Everything is handled by the main organizers. I think this change has great potential and can mean a much smoother ride for everyone involved. My impression of Messe Berlin over the years is that they're pretty bureacratic. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] LinuxTag in Berlin from May 8–10, 2014
On 08.02.2014 23:13, Paul Menzel wrote: Dear coreboot folks, just a short announcement that after FOSDEM last weekend the next free software event (in Europe(?)) is going to be LinuxTag in Berlin from May 8–10, 2014. I won't be able to attend The location is going to be different this year. Since several years it won’t be happening at Messe Berlin but at STATION BERLIN [2]. So please mark that in your calender and let’s see what we can come up with coreboot wise for that event. Thanks, Paul [1] http://linuxtag.de/2014/en/ [2] http://www.station-berlin.de/en/location_directions/location.html signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
