October 2014 - coreboot - mail.coreboot.org

Standard Microsystems LPC47B387 I/O Controller
by None Oct. 26, 2014

Oct. 26, 2014

The source code for SuperIOTool says of the Standard Microsystems (SMSC/SMC) LPC47B387: 'We cannot find a public datasheet for this Super I/O.' This still seems to be the case. However, I found a Hewlett-Packard manual called 'Technical Reference Guide: HP Compaq d330 and d530 Series Personal Computers' (file name '340154_rev001_us.pdf', Document Part Number 340154-001). It gives some information on that I/O Controller, that maybe is enough to have SuperIOTool (and maybe, CoreBoot) support it. Here is page 4-30, with minor additions: [quote:] The LPC47B387 I/O controller contains various functions such as the keyboard/mouse interfaces, diskette interface, serial interfaces, and parallel interface. While the control of these interfaces uses standard AT-type I/O addressing (as described in Chapter 5), the configuration of these functions uses indexed ports unique to the LPC47B387. In these [Hewlett-Packard] systems, hardware strapping selects I/O addresses 02Eh and 02Fh at reset as the Index/Data ports for accessing the logical devices within the LPC47B387. Table 4-16 lists the PnP standard control registers for the LPC47B387. Table 4-16 LPC47B387 I/O Controller Control Registers Index Function Reset Value 02h Configuration Control 00h 03h Reserved 07h Logical Device (Interface) Select: 00h 00h = Diskette Drive I/F 01h = Reserved 02h = Reserved 03h = Parallel I/F 04h = Serial I/F (UART 1/Port A) 05h = Serial I/F (UART 2/Port B) 06h = Reserved 07h = Keyboard I/F 08h = Reserved 09h = Reserved 0Ah = Run-time Registers (GPIO Config.) 0Bh = SMBus Configuration 20h Super I/O ID Register (SID) 56h 21h Revision -- 22h Logical Device Power Control 00h 23h Logical Device Power Management 00h 24h PLL/Oscillator Control 04h 25h Reserved 26h Configuration Address (Low Byte) 27h Configuration Address (High Byte) 28-2Fh Reserved NOTE: For a detailed description of registers refer to appropriate SMC documentation. [But there isn't any. The manual has things inherited from its predecessor manual.] The configuration registers are accessed through I/O registers 2Eh (index) and 2Fh (data), after the configuration phase has been activated by writing 55h to I/O port 2Eh. The desired interface (logical device) is initiated by firmware selecting logical device number of the 47B347 using the following sequence: 1. Write 07h to I/O register 2Eh. 2. Write value of logical device to I/O register 2Fh. 3. Write 30h to I/O register 2Eh. 4. Write 01h to I/O register 2Fh (this activates the interface). Writing AAh to 2Eh deactivates the configuration phase. [end quote] The next page doesn't relate to SuperIOTool, but may be useful in making CoreBoot support the two motherboards used in the machines given in the title of the manual. All but one of the machines use an ASUS P4SD motherboard (which is similar to their P4SD-LA). ASUS don't give information on it. Hewlett-Packard just refer to it as Part Number 323091-001 and don't let on that it's made by ASUS. [quote:] The [Hewlett-Packard] systems covered in this guide utilize the following specialized functions built into the LPC47B387 I/O Controller: Power/Hard drive LED control The I/O controller provides color and blink control for the front panel LEDs used for indicating system events (refer to Table 4-14). Intruder sensing Supported on SFF, DT, MT, and CMT [Small Form Factor, Desktop, Microtower, and Configurable Minitower] form factors, battery-backed D-latch logic internal to the LPC47B387 is connected to the hood sensor switch to record hood (cover) removal. Hood lock/unlock Supported on SFF, DT, MT, and CMT [as above] form factors, logic internal to the LPC47B387 controls the lock bar mechanism. I/O security The parallel, serial, and diskette interfaces may be disabled individually by software and the LPC47B387s disabling register locked. If the disabling register is locked, a system reset through a cold boot is required to gain access to the disabling (Device Disable) register. Processor present/speed detection One of the battery-backed general-purpose inputs (GPI26) of the LPC47B387 detects if the processor has been removed. The occurrence of this event is passed to the [Intel south bridge] ICH5 that will, during the next boot sequence, initiate the speed selection routine for the processor. Legacy/ACPI power button mode control The LPC47B387 receives the pulse signal from the systems power button and produces the PS On signal according to the mode (legacy or ACPI) selected. Refer to Chapter 7 for more information regarding power management. [end quote] I don't think there is anything else useful on this I/O Controller in the manual. Regards, Niall Kennedy

1 0

sourcing 128MB flash chips for an X60 with coreboot
by Charles Devereaux Oct. 25, 2014

Oct. 25, 2014

Hello I would like to replace the flash chip with something larger, to add a minimal linux distribution and test some security ideas. I selected a few chips based on flashrom support, but I can't find any of them on my usual websites. On ebay, I can't find them in SOIC8 package. Yet IIRC, someone did that with a x60 running coreboot (just can't find the URL at the moment). Hopefully that person is even on the list! Would you have a recommended source to get 2 or 3 of them? ideally: M25P128 possible: MX25L128 05D N25Q128.3E W25Q128.V (because non-volatile write bit chips are produced by Macronix and Winbond) Thanks Charles

1 0

Re: [coreboot] elc next year
by Peter Stuge Oct. 24, 2014

Oct. 24, 2014

ron minnich wrote: > is in dublin. How do people feel about dublin? I was looking into Dublin connections when the Aer Lingus web site destroyed the state of my web browser. I for one am not very excited. //Peter

2 1

Re: [coreboot] elc next year
by John Lewis Oct. 23, 2014

Oct. 23, 2014

I may well be back the other side of the Irish sea this time next year, but yeah, I'll definitely come to that! John. On 23/10/14 22:07, ron minnich wrote: > is in dublin. How do people feel about dublin? I'm sure John Lewis > hates the idea :-). ron >

1 0

elc next year
by ron minnich Oct. 23, 2014

Oct. 23, 2014

is in dublin. How do people feel about dublin? I'm sure John Lewis hates the idea :-). ron

1 0

Re: [coreboot] x60 - question about rfkill and wwan/bluetooth status
by Peter Stuge Oct. 21, 2014

Oct. 21, 2014

Charles Devereaux wrote: > Thanks for your cryptic answers. I will try to extrapolate some > meaning out of them. If rfkill does not work in your Linux system and you want to fix that then you need to find out *why* it doesn't work in your system. Asking others if it works in their systems tells you nothing about why, and doesn't bring you closer to whatever is missing in coreboot. //Peter

1 0

Re: [coreboot] x60 - question about rfkill and wwan/bluetooth status
by Peter Stuge Oct. 21, 2014

Oct. 21, 2014

Peter Stuge wrote: > > rfkill > > Find out what the kernel requires and implement it in coreboot. Charles Devereaux wrote: > rfkill Please see above. //Peter

2 1

Re: [coreboot] x60 - question about rfkill and wwan/bluetooth status
by Peter Stuge Oct. 21, 2014

Oct. 21, 2014

Charles Devereaux wrote: > WWAN It works just fine. The enable bit is in EC register 0x30 bit 6. > rfkill Find out what the kernel requires and implement it in coreboot. //Peter

2 1

Re: [coreboot] x60 - question about rfkill and wwan/bluetooth status
by Peter Stuge Oct. 21, 2014

Oct. 21, 2014

Charles Devereaux wrote: > bluetooth BT has a separate enable bit. It is completely unrelated to wwan. //Peter

1 0

x60 - question about rfkill and wwan/bluetooth status
by Charles Devereaux Oct. 21, 2014

Oct. 21, 2014

Hello I am quite interested in WWAN support. My previous findings were reported on http://www.coreboot.org/pipermail/coreboot/2014-September/078538.html At the moment, using a branch based on a libreboot5, along with patch #4056, it works quite well, but I do not have rfkill support (cf http://www.coreboot.org/pipermail/coreboot/2014-September/078542.html) or any way to turn WWAN off. Basically, there is no WWAN rfkill entry if you do "rfkill list" Also, I noticed that while rfkill block 0 does turn off the wifi led, rfkill block for bluetooth does not turn turn off its led (or even echo '5-2' > /sys/bus/usb/drivers/usb/unbind) My belief is some ACPI entries are missing to handle that. I am going back into the ACPI table investigation, but I'm curious whether anyone has had good results with WWAN, ie : - if rfkill shows a WWAN entry - if rfkill block reduces power consumption (cf /proc/acpi/battery/BAT0/state) and turns off the LED. I would also be interested to know if rfkill block bluetooth does turns off the LED (the power consumption change might be too low to be noticeable) Thanks Charles

1 0