Re: [coreboot] Chromebox debugging.
Sorry for not including all you asked for Kyösti, I've not had much time to spend on this. So you are saying if lsusb -v reports a 'Debug descriptor' I should be able to use that port as the EHCI debug port on the target? When you say 'dmesg from the other end', you mean the target end(the Chromebox)? How do I get this? The Coreboot build the Chromebox ships with has USB debugging right?. Do I need to compile a new kernel to see it? Tim. Here is the sudo lsusb -v (From my laptop not the Chromebox): Bus 003 Device 006: ID 0525:c0de Netchip Technology, Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0525 Netchip Technology, Inc. idProduct 0xc0de bcdDevice0.00 iManufacturer 0 iProduct0 iSerial 0 bNumConfigurations 0 Debug descriptor: bLength 4 bDescriptorType10 bDebugInEndpoint 0x81 bDebugOutEndpoint0x01 Device Status: 0x (Bus Powered) On the phone I see this in /proc/kmsg while connecting the phone to different USB ports on the Chromebox: 4[ 680.485443] USB connected! 6[ 680.485473] musb_pullup2 - Enabling USB Pullups 4[ 680.485473] Enable usb 6[ 687.774627] MUSB BUS RESET as b_peripheral 6[ 687.774688] musb RESET! 7[ 687.774749] dbgp gadget: setup: desc device 7[ 687.774810] dbgp gadget: setup complete: 0, 18/18 6[ 687.847717] MUSB BUS RESET as b_peripheral 6[ 687.847747] musb RESET! 7[ 687.847747] dbgp gadget: disconnected 7[ 687.859619] dbgp gadget: setup: desc device 7[ 687.859619] dbgp gadget: setup complete: 0, 18/18 7[ 687.859863] dbgp gadget: setup: failure req 6 v 200 7[ 687.860321] dbgp gadget: setup: failure req 6 v 200 7[ 687.860656] dbgp gadget: setup: failure req 6 v 200 6[ 710.459197] MUSB BUS RESET as b_peripheral 6[ 710.459228] musb RESET! 7[ 710.459289] dbgp gadget: disconnected 7[ 710.459320] dbgp gadget: setup: desc device 7[ 710.459381] dbgp gadget: setup complete: 0, 18/18 6[ 710.530242] MUSB BUS RESET as b_peripheral 6[ 710.530273] musb RESET! 7[ 710.530273] dbgp gadget: disconnected 7[ 710.540527] dbgp gadget: setup: desc device 7[ 710.540557] dbgp gadget: setup complete: 0, 18/18 7[ 710.540649] dbgp gadget: setup: failure req 6 v 200 7[ 711.141265] dbgp gadget: setup: failure req 9 v 0 6[ 716.865600] cpcap_usb_det: SenseBits = 0x4114 6[ 716.865631] cpcap_usb_det: SenseBit = CPCAP_BIT_CHRGCURR1_S 6[ 716.865661] cpcap_usb_det: SenseBit = CPCAP_BIT_DP_S_LS) 6[ 716.865661] cpcap_usb_det: SenseBit = CPCAP_BIT_ID_FLOAT_S 6[ 716.865692] cpcap_usb_det: SenseBit = CPCAP_BIT_SESSVLD_S 6[ 716.967895] cpcap_usb_det: SenseBits = 0x4010 6[ 716.967926] cpcap_usb_det: SenseBit = CPCAP_BIT_CHRGCURR1_S 6[ 716.967926] cpcap_usb_det: SenseBit = CPCAP_BIT_ID_FLOAT_S 6[ 717.069213] cpcap_usb_det: SenseBits = 0x4010 6[ 717.069213] cpcap_usb_det: SenseBit = CPCAP_BIT_CHRGCURR1_S 6[ 717.069244] cpcap_usb_det: SenseBit = CPCAP_BIT_ID_FLOAT_S 6[ 717.171142] cpcap_usb_det: SenseBits = 0x4010 6[ 717.171173] cpcap_usb_det: SenseBit = CPCAP_BIT_CHRGCURR1_S 6[ 717.171173] cpcap_usb_det: SenseBit = CPCAP_BIT_ID_FLOAT_S 6[ 717.272369] cpcap_usb_det: SenseBits = 0x4010 6[ 717.272369] cpcap_usb_det: SenseBit = CPCAP_BIT_CHRGCURR1_S 6[ 717.272369] cpcap_usb_det: SenseBit = CPCAP_BIT_ID_FLOAT_S 6[ 717.373901] cpcap_usb_det: SenseBits = 0x4010 6[ 717.373931] cpcap_usb_det: SenseBit = CPCAP_BIT_CHRGCURR1_S 6[ 717.373931] cpcap_usb_det: SenseBit = CPCAP_BIT_ID_FLOAT_S 6[ 717.491210] cpcap_usb_det: SAMPLE_2 cable may not be fully inserted 6[ 717.592773] cpcap_usb_det: SenseBits = 0x4010 6[ 717.592803] cpcap_usb_det: SenseBit = CPCAP_BIT_CHRGCURR1_S 6[ 717.592834] cpcap_usb_det: SenseBit = CPCAP_BIT_ID_FLOAT_S 6[ 717.592864] cpcap_usb_det notify_accy: accy=NONE 6[ 717.592895] cpcap spi2.0: notify_accy: accy=4 4[ 717.605804] USB disconnected! 4[ 717.605834] Disable usb 6[ 717.605834] musb_pullup2 - Disabling USB Pullups 7[ 717.605865] dbgp gadget: disconnected 6[ 720.975646] cpcap_usb_det: cable connected. 6[ 720.976379] cpcap_usb_det: SenseBits = 0x401c 6[ 720.976409] cpcap_usb_det: SenseBit = CPCAP_BIT_CHRGCURR1_S 6[ 720.976440] cpcap_usb_det: SenseBit = CPCAP_BIT_ID_FLOAT_S 6[ 720.976470] cpcap_usb_det: SenseBit = CPCAP_BIT_SESSVLD_S 6[ 720.976470] cpcap_usb_det: SenseBit = CPCAP_BIT_VBUSVLD_S 6[ 720.976501] cpcap_usb_det: Sense Pattern = SENSE_USB 6[ 720.976531] cpcap_usb_det: USB or USB_FLASH 6[ 720.976562] cpcap_usb_det notify_accy: accy=USB 6[ 720.976562] cpcap spi2.0: notify_accy: accy=0 4[ 720.976593] USB connected! 6[ 720.976623] musb_pullup2 - Enabling USB Pullups 4[ 720.976654] Enable usb I can sent you the complete log outside the list if you need it. On Fri, Jan 24, 2014 at 1:07 AM,
[coreboot] Compilation Error building FILO
Hi, I am experiencing a problem with building filo. I am getting the following error: /../coreboot/payloads/filo/build/libpayload/lib/libpayload.a(keyboard.libc.o): In function `keyboard_disconnect': keyboard.c:(.text+0x208): undefined reference to `keyboard_wait_write' make: *** [/../coreboot/payloads/filo/build/filo] Error 1 I have tried various guides to try to build but I cannot get it to work. Does anybody else have the same problem? Or how can I fix it? Regards, Raymond -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Chromebox debugging.
On 01/24/2014 12:18 PM, Timothy Potter wrote: Sorry for not including all you asked for Kyösti, I've not had much time to spend on this. So you are saying if lsusb -v reports a 'Debug descriptor' I should be able to use that port as the EHCI debug port on the target? Hi I think my first reply was quite clear on what information I need to assist you solve it. But I am too close to see if some obvious details from my instructions were missing. This is more easily solved if you come to discuss on #coreboot. You should then write a tutorial for our wiki or at least reply here with the steps were you went wrong the first time. Kyösti -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] coreboot port for macbook2,1
Hallo, Would you help me on a coreboot port? I just installed coreboot on a Thinkpad X60 following the wiki. Now I want it on this mid-2007 macbook2,1 too. I read some pages in the wiki and started to collect information about the macbook. it seems it has no superIO chip and I dont know what to think of the ectool output. As I understood by now, not knowing how the ec might interfere with the bios or coreboot is one of the big obstacles, no? I hope that once I would try a coreboot flash, recovery might be possible by an external programmer (which I do not have, yet). the flash chip is the same as on the X60 (I've read the factory bios already) as is the northbridge and southbridge. an usb debug port seems available. I've put the log files here: http://macbook.donderklumpen.de/coreboot/ Any comment about what you think about this and how I should proceed is very much welcome! thanks Mono -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot port for macbook2,1
Mono wrote: how I should proceed Spend somewhere between months and years learning tools and x86 firmware, and proceed to then spend much less than that on creating the actual port. I know that this isn't very helpful. It isn't realistic to expect the kind of help that I'm afraid you might need. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] cmos.layout upgradability
Hello, all. Due to my failue to foresee this problem if one upgrades X60 coreboot, you need to manually reset CMOS config or your trackpad may not work as option trackpad_enable will get a garbage value. While I admit my part of fault, I feel like we should have a way to update options safely. I see following possibilities: 1) Hide ourselves and tell that on upgrade you always have to clear CMOS. I don't think it's really an option as users will continue just running flashrom and in case of external flashing, CMOS reset may require full power removal with cell battery sometimes in difficult to access places inside laptop. 2) Have some version field to check and if it mismatches reset CMOS to default. To avoid having to maintain version manually I propose to checksum option table and write 16-bit result to CMOS. 16-bit should give enough confidence without excessively using CMOS. I've made a prototype at http://review.coreboot.org/#/c/4790/4 . If we can agree that it's a right approach, I'll make this prototype into complete patch (mostly missing is laborous adding of version field) 2a) instead of having separate field we could make XOR layout checksum into CMOS checksum. This would save 2 bytes but will break any existing users if they check checksum. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Fwd: Re: coreboot port for macbook2,1
Original Message Subject: Re: [coreboot] coreboot port for macbook2,1 Date: Sat, 25 Jan 2014 01:23:12 +0100 From: Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com To: Mono m...@posteo.de On 24.01.2014 23:20, Mono wrote: Hallo, Would you help me on a coreboot port? I just installed coreboot on a Thinkpad X60 following the wiki. Now I want it on this mid-2007 macbook2,1 too. I read some pages in the wiki and started to collect information about the macbook. it seems it has no superIO chip and I dont know what to think of the ectool output. As I understood by now, not knowing how the ec might interfere with the bios or coreboot is one of the big obstacles, no? I hope that once I would try a coreboot flash, recovery might be possible by an external programmer (which I do not have, yet). the flash chip is the same as on the X60 (I've read the factory bios already) as is the northbridge and southbridge. an usb debug port seems available. I've put the log files here: http://macbook.donderklumpen.de/coreboot/ Any comment about what you think about this and how I should proceed is very much welcome! Good news is that other than EC and some minor points, your macbook is a copy of X60. With some luck a qualified dev can do it in a week (you may want to post bounty for it). You need to get console. EHCI debug would be the best option on your laptop. http://www.coreboot.org/EHCI_Debug_Port#Finding_the_USB_debug_port Take USB 2.0 stick and plug it into different port until it appears as device one on bus 3. You'll have to make a USB debug dongle or buy one (short supply). You'll also need to find your flash chip. Your laptop has this chip: http://orzparts.com/index.php?main_page=product_infoproducts_id=732 You'll have to teardown the whole laptop, looking at every chip which seems similar. Remember to discharge from static electricity before opening your laptop and not to wear anything that produces it. This has a risk of breaking your laptop, proceed at your own risk, you've been warned. thanks Mono signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] cmos.layout upgradability
On Saturday, January 25, 2014 12:51:25 AM Vladimir 'φ-coder/phcoder' Serbinenko wrote: Hello, all. Due to my failue to foresee this problem if one upgrades X60 coreboot, you need to manually reset CMOS config or your trackpad may not work as option trackpad_enable will get a garbage value. While I admit my part of fault, I feel like we should have a way to update options safely. I see following possibilities: 1) Hide ourselves and tell that on upgrade you always have to clear CMOS. I don't think it's really an option as users will continue just running flashrom and in case of external flashing, CMOS reset may require full power removal with cell battery sometimes in difficult to access places inside laptop. 2) Have some version field to check and if it mismatches reset CMOS to default. To avoid having to maintain version manually I propose to checksum option table and write 16-bit result to CMOS. 16-bit should give enough confidence without excessively using CMOS. I've made a prototype at http://review.coreboot.org/#/c/4790/4 . If we can agree that it's a right approach, I'll make this prototype into complete patch (mostly missing is laborous adding of version field) 2a) instead of having separate field we could make XOR layout checksum into CMOS checksum. This would save 2 bytes but will break any existing users if they check checksum. You mean it won't write the cmos.default after upgrade? And why would you need to reset CMOS if trackpad is disabled? # nvramtool -a # nvramtool -w trackpad_enable=Enable -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Fwd: Re: coreboot port for macbook2,1
On 25.01.2014 01:23, Vladimir 'φ-coder/phcoder' Serbinenko wrote: Original Message Subject: Re: [coreboot] coreboot port for macbook2,1 Date: Sat, 25 Jan 2014 01:23:12 +0100 From: Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com To: Mono m...@posteo.de On 24.01.2014 23:20, Mono wrote: Hallo, Would you help me on a coreboot port? I just installed coreboot on a Thinkpad X60 following the wiki. Now I want it on this mid-2007 macbook2,1 too. I read some pages in the wiki and started to collect information about the macbook. it seems it has no superIO chip and I dont know what to think of the ectool output. As I understood by now, not knowing how the ec might interfere with the bios or coreboot is one of the big obstacles, no? I hope that once I would try a coreboot flash, recovery might be possible by an external programmer (which I do not have, yet). the flash chip is the same as on the X60 (I've read the factory bios already) as is the northbridge and southbridge. an usb debug port seems available. I've put the log files here: http://macbook.donderklumpen.de/coreboot/ Any comment about what you think about this and how I should proceed is very much welcome! Good news is that other than EC and some minor points, your macbook is a copy of X60. With some luck a qualified dev can do it in a week (you may want to post bounty for it). You need to get console. EHCI debug would be the best option on your laptop. http://www.coreboot.org/EHCI_Debug_Port#Finding_the_USB_debug_port Take USB 2.0 stick and plug it into different port until it appears as device one on bus 3. I meant port 1 on bus managed by ehci_pci (exact bus numbers are unstable) You'll have to make a USB debug dongle or buy one (short supply). You'll also need to find your flash chip. Your laptop has this chip: http://orzparts.com/index.php?main_page=product_infoproducts_id=732 You'll have to teardown the whole laptop, looking at every chip which seems similar. Remember to discharge from static electricity before opening your laptop and not to wear anything that produces it. This has a risk of breaking your laptop, proceed at your own risk, you've been warned. thanks Mono signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] cmos.layout upgradability
On 25.01.2014 01:28, mrnuke wrote: On Saturday, January 25, 2014 12:51:25 AM Vladimir 'φ-coder/phcoder' Serbinenko wrote: Hello, all. Due to my failue to foresee this problem if one upgrades X60 coreboot, you need to manually reset CMOS config or your trackpad may not work as option trackpad_enable will get a garbage value. While I admit my part of fault, I feel like we should have a way to update options safely. I see following possibilities: 1) Hide ourselves and tell that on upgrade you always have to clear CMOS. I don't think it's really an option as users will continue just running flashrom and in case of external flashing, CMOS reset may require full power removal with cell battery sometimes in difficult to access places inside laptop. 2) Have some version field to check and if it mismatches reset CMOS to default. To avoid having to maintain version manually I propose to checksum option table and write 16-bit result to CMOS. 16-bit should give enough confidence without excessively using CMOS. I've made a prototype at http://review.coreboot.org/#/c/4790/4 . If we can agree that it's a right approach, I'll make this prototype into complete patch (mostly missing is laborous adding of version field) 2a) instead of having separate field we could make XOR layout checksum into CMOS checksum. This would save 2 bytes but will break any existing users if they check checksum. You mean it won't write the cmos.default after upgrade? Not it won't. Checksum covers the same range and is at same position. So checksum is still valid. And why would you need to reset CMOS if trackpad is disabled? # nvramtool -a # nvramtool -w trackpad_enable=Enable You could do it in this particular case but user isn't required to know this. And settings may be something more drammatic. It may happen that the system doesn't boot with garbage settings at all. The fact that you have to handle garbage in saved option indicates that something is wrong. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
