coreboot October 2016

coreboot@coreboot.org

55 participants
148 discussions

Building Intel SoC Apollo Lake with DDR3L+PMIC
by morris.wang 11 Oct '16

11 Oct '16

Hello, I am building coreboot image for Apollo Lake. My designed mainboard comes with DDR3L SODIMMs + PMIC. To my knowledge, RVP1 board is for DDR3L SODIMMs and discrete VRs. RVP2 board is for LPDDR3 and PMIC. If I selected under coreboot configuration: Mainboard --> Mainboard vendor (Intel) Mainboard model (Apollolake DDR3 RVP1) How to modify VR type from Discrete to PMIC??? Kind regards, Morris

3 2

smbus_xxx functions
by Haleigh Novak 10 Oct '16

10 Oct '16

Hello All, Firstly this is sort of building off of the suggestions from the "i2c_writeb vs i2c_raw_write output" thread; I have looked into the smbus_xxx() functions and they might do the trick. So basically what I am trying to do is send the POSTcodes to somewhere I can read them and at the moment the most convenient choices were i2c, spi and now smbus; with smbus looking the most promising. So the easiest way (i thought) would be to modify post_code() function in coreboot/src/console/post.c just temporarily adding a modification at the end of the function. I have included the 'device/smbus.h' header - at the suggestion of Mr. Werner, Mr. Kyosti, and Mr. Laurie - to allow for use (or so I thought) of the smbus functions. The following is a my output from a clean make. I do not know if the email will send in plain text indented as I have it so the error carrot is pointing up under the '->' between 'ops' and 'ops_smbus_bus'; the error instance of the error in post.c is within the #include set as well as seen below post.c(22) is '#include <device/smbus.h>'. ______________________________________________________________________ # # configuration written to /home/test/coreboot_2/coreboot/.config # HOSTCC util/sconfig/lex.yy.o HOSTCC util/sconfig/sconfig.tab.o HOSTCC util/sconfig/main.o HOSTCC util/sconfig/sconfig (link) SCONFIG mainboard/asrock/imb-a180/devicetree.cb HOSTCC nvramtool/cli/nvramtool.o HOSTCC nvramtool/cli/opts.o HOSTCC nvramtool/cmos_lowlevel.o HOSTCC nvramtool/cmos_ops.o HOSTCC nvramtool/common.o HOSTCC nvramtool/compute_ip_checksum.o HOSTCC nvramtool/hexdump.o HOSTCC nvramtool/input_file.o HOSTCC nvramtool/layout.o HOSTCC nvramtool/accessors/layout-common.o HOSTCC nvramtool/accessors/layout-text.o HOSTCC nvramtool/accessors/layout-bin.o HOSTCC nvramtool/lbtable.o HOSTCC nvramtool/reg_expr.o HOSTCC nvramtool/cbfs.o HOSTCC nvramtool/accessors/cmos-mem.o HOSTCC nvramtool/nvramtool (link) OPTION option_table.h CC bootblock/mainboard/asrock/imb-a180/static.o CC bootblock/arch/x86/boot.o GEN generated/bootblock.ld CP bootblock/arch/x86/bootblock.ld HOSTCC util/romcc/romcc (this may take a while) ROMCC generated/bootblock.inc Warning: Nonexistent include path: `src/vendorcode/amd/agesa/f16kb/Lib' CC bootblock/arch/x86/bootblock_romcc.o CC bootblock/arch/x86/cpu_common.o GEN build.h CC bootblock/arch/x86/id.o CC bootblock/arch/x86/memcpy.o CC bootblock/arch/x86/memset.o CC bootblock/arch/x86/mmap_boot.o CC bootblock/arch/x86/walkcbfs.o CC bootblock/commonlib/cbfs.o CC bootblock/commonlib/lz4_wrapper.o CC bootblock/commonlib/mem_pool.o CC bootblock/commonlib/region.o CC bootblock/console/die.o CC bootblock/console/post.o In file included from src/console/post.c:22:0: src/include/device/smbus.h: In function 'ops_smbus_bus': src/include/device/smbus.h:30:27: error: dereferencing pointer to incomplete type 'struct device_operations' bops = bus->dev->ops->ops_smbus_bus; ^ make: *** [build/bootblock/console/post.o] Error 1 ______________________________________________________________________ I have tried the following without avail: ~ rearranging the #include statements (does not to help at all) ~ looking at the makefile output of an unmodified bootable version I have of coreboot (used for reference and a fresh start if needed) to see if the files contain smbus.h in the inclusions - some do but much further down in the makefile output and the 'smbus.h' is in quotes not <> because it is in the same folder as the referencing file ~ googling "dereferencing pointer to incomplete type", "dereferencing pointer to incomplete struct type", "dereferencing coreboot pointer to incomplete type", etc - which the results are 99% solved by including a header file but the two I need ('device.h' and 'smbus.h') are included ~ adding 'struct device_operations;' to the top of the file - both 'post.c' and 'smbus.h' ~ figuring out where all the structs referenced in the 'bops = ....' they are all in 'src/include/device/device.h' which is included in 'post.c' and 'smbus.h' ~ checking if there are any guards and they either match or arent there ex: in 'device.h' the 'device_operations' struct is in a 'ifndef(__SIMPLE_DEVICE__) guard so I made sure that 'post.c' and 'smbus.h' are not _SIMPLE_DEVICE_ ~ going in 'smbus.h' to set the bus->dev->ops to equal a 'struct device_operations' pointer and using said pointer to get 'ops_smbus_bus' with a cast ~ replacing '->' with '.' I feel like I don't really understand the error because either coreboot provides a 'special case' scenario here, or that I am completely missing something, or that I do not understand the transactions as well as I thought. Thank you for your time. HN

1 0

AMD platform: IO-APIC => Local APIC delivery modes
by Andriy Gapon 10 Oct '16

10 Oct '16

I apologize that my questions are not about coreboot and I am sort of hijacking the forum. But I think that this is a place where people with good knowledge of the hardware can be found. Maybe my issue will be of interest to you as well. And I hope to get some help. Maybe even some secrets shared :-) First, the hardware that I am talking about: it's a typical consumer system with a Family 10h AMD processor, SB700 southbridge and 780G northbridge: http://www.gigabyte.com/products/product-page.aspx?pid=3004#sp What I want to achieve is to get an interrupt generated by a SuperIO chip (external to the chipset) delivered to a CPU as a NMI. The interrupt is IRQ3 connected to pin 3 of the IO-APIC and everything just works if I forget about NMI: device -> IO-APIC pin 3 -> (fixed mode interrupt message) -> Local APIC -> interrupt handler at the configured vector. NMI is what makes it interesting. So, the first thing I tried is simply to set the NMI delivery mode for the pin. Unfortunately, that does not work, the system gets reset as soon as the interrupt is generated. So, my first question is: can that be made to work at all? Perhaps, there are some registers that need to be correctly programmed in the chipset or in the processor for that to work. Or maybe it can not work at all. For example, for Intel ICH9R southbridge it is documented that SMI, NMI and INIT must not be used. I couldn't find any such restriction explicitly stated for the AMD chipsets. So, I decided to not give up and to try to use the legacy interrupt mode to get what I want. I think that that's how Linux NMI watchdog driver used to work. So, I programmed LINT0 and LINT1 for NMI delivery mode (on all cores, all two of them), enabled legacy PIC (I guess that it's built into the chipset) and made sure that the interrupt is unmasked. But absolutely nothing happened when the interrupt is generated. >From this I concluded that the PIC is not connected to the CPUs. Just to be sure that I didn't make any mistake with the PIC programming I decided to check that the only other possibility worked, that is, that the PIC is connected to pin 0 of the IO-APIC. By default the pin was masked (by the OS, I guess), so I programmed it to ExtINT delivery mode with the BSP as the physical destination (also edge-triggered, active high). What I observed next was a bit surprising. Every time I generated the interrupt the target CPU would set bit 6 (received illegal vector) in its Local APIC's error status register. I concluded that the interrupt got routed from the PIC to the pin 0 of the IO-APIC, but then there was a problem delivering the ExtINT message. I looked for mentions of ExtINT in the Family 10 BKDG and stumbled upon the LintEn bit in F0x68 register. The bit is described as such: > LintEn: local interrupt conversion enable. Read-write. 1=Enables the conversion of broadcast > ExtInt and NMI interrupt requests to LINT0 and LINT1 local interrupts, respectively, before deliver- > ing to the local APIC. This conversion only takes place if the local APIC is hardware enabled. LINT0 > and LINT1 are controlled by APIC350 and APIC360. 0=ExtInt/NMI interrupts delivered unchanged. The bit was unset. I decided to set it and see what happens. Much to my surprise I got NMIs delivered to both cores. Then I remembered that I still had NMI delivery mode set for LINT0 on both of them. And this happened despite the destination being programmed to zero (the BSP's APIC ID), not the broadcast address. Another weird thing was that the 'received illegal vector' bit was still getting set. So, I got what I wanted but in a complex configuration: device -> PIC -> IO-APIC pin 0 -> (ExtINT) -> (converted to LINT0) -> NMI I decided to simplify that scheme a little bit to this: device -> IO-APIC pin 3 -> (ExtINT) -> (converted to LINT0) -> NMI so that I didn't have to enable the PIC. That is, I reprogrammed the pin 3 to ExtINT delivery mode, masked pin 0 and disabled PIC. But that didn't work. Regardless of how LintEn was set I was getting just the bad vector errors without NMI. Then I decided to incrementally go back to working configuration. I enabled PIC - still no NMI. I unmasked IRQ3 - got NMI! Pin 0 was still masked. So, this working configuration was slightly different from the original working configuration: device -> PIC [IRQ3 unmasked] -> IO-APIC pin 0 -> (Masked) \-> IO-APIC pin 3 -> (ExtINT) -> (converted to LINT0) -> NMI So, the interrupt was going through the APIC route, but the legacy stuff had to be enabled for ExtINT to be converted to LINT0. I think that this is an interesting discovery: PIC's configuration affects how the IO-APIC communicates to the Local APICs. I went over the BKDG and SB7x0 documentation (RRG, RPG) and only PCI_Reg 62h of device 20 function 0 in SB7x0 caught my eye. Namely, K8_INTR, MT3_Set and MT3_Auto bits. They all are about K8 INTR [NMI] message. On my system the register is set to 0x24, that is K8_INTR is set, but MT3_Set and MT3_Auto are not... In the coreboot source code I see that the register is set up with exactly the same value in src/southbridge/amd/sb700/early_setup.c. And, for what it's worth, bit 5 (0x20 mask) is documented as "reserved". I would greatly appreciate if anyone could tell me how to configure the system to get NMIs working in the simplest possible fashion. That is, without enabling PIC. And preferably without requiring the message to LINTn conversion with LintEn. I will be happy with just magic setting. But if there will be an explanation of what the settings do and how interrupt routing works within the chipset and between the chipset and the CPU, then that would be terrific! I hope that this was not a boring read. Thank you! -- Andriy Gapon

2 12

Skylake S3 resume failure (without relocatable ramstage)
by Trammell Hudson 10 Oct '16

10 Oct '16

When my Skylake system comes out of S3 it fails to resume and ends up going back through the normal boot path. Console output durng resume: coreboot-4.4-1781-g2fcabb8-heads Wed Oct 5 01:45:23 UTC 2016 ramstage starting... FSP_INFO_HEADER not set! Enumerating buses... Enabling Common Clock Configuration ASPM: Enabled L1 done Allocating resources... Reading resources... CPU_CLUSTER: 0 missing read_resources Done reading resources. Setting resources... PNP: 0c09.0 missing set_resources Done setting resources. Done allocating resources. (and then it reboots) My guess is that this is due to the hacks to disable the relocatable ramstage: > CONFIG_RELOCATABLE_RAMSTAGE: > The reloctable ramstage support allows for the ramstage to be built > as a relocatable module. The stage loader can identify a place > out of the OS way so that copying memory is unnecessary during an S3 > wake. When selecting this option the romstage is responsible for > determing a stack location to use for loading the ramstage. I filed an issue on the tracker related to the ramstage problem and am trying to debug it with Aaron: https://ticket.coreboot.org/issues/78 -- Trammell

1 1

Re: [coreboot] i2c_writeb vs i2c_raw_write output
by Haleigh Novak 10 Oct '16

10 Oct '16

?Thank you Julius for the explanation, I really appreciate it especially since in my googling I didn't manage to gather the information you provided in your last paragraph. Also thank you both Duncan and Kyösti for the suggestions/direction for my continuation of this project, I will defiantly look into the smbuss_xxx() functions. And thank you as well Punit for bringing the writing requirements back to forefront. Thank you again everyone I really appreciate it. HN ________________________________ From: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Sent: Saturday, October 8, 2016 7:57 PM To: Duncan Laurie Cc: Julius Werner; Haleigh Novak; coreboot Subject: Re: [coreboot] i2c_writeb vs i2c_raw_write output On Sun, Oct 9, 2016 at 2:09 AM, Duncan Laurie <dlaurie(a)chromium.org<mailto:dlaurie@chromium.org>> wrote: On Fri, Oct 7, 2016 at 5:51 PM, Julius Werner <jwerner(a)chromium.org<mailto:jwerner@chromium.org>> wrote: Also, I think all of these functions only work on non-x86 devices right now so they're probably not really helpful to you (I'd be surprised if they even compile and link for your board). The I2C API is unfortunately one of those areas where x86 and non-x86 coreboot still lead very separate side-by-side lives right now. For x86 you probably need the i2c_dev_xxx() functions, which should in theory work Skylake and Apollolake do support the I2C API and associated convenience functions. (finally!) The i2c driver used is common for intel chipsets since haswell(core) and baytrail(atom), it just needs a bit of glue layer to map bus number to a base address. I added the i2c_dev_* variants around the same time in order to support drivers where the bus+address comes from devicetree, but the functions that take a bus+address will work too. similar but I have no experience with them. You might also need to use the smbus_xxx() functions instead (SMBUS is some kinda-the-same-but-not-quite thing related to I2C on x86 that I never bothered to fully understand). I agree this is likely what is needed for the ASROCK IMB-A180 as it looks like there is an smbus driver in the southbridge. Look for i2c_smbus_send_byte() in include/device/smbus.h which is implemented in southbridge/amd/agesa/hudson/smbus.c -duncan I have not used this particular Beagle i2c/spi reade. As part of the protocol, i2c/smbus master expects there is a slave device that first acknowledges it address, and then also each byte you send to it. Maybe this Beagle has a switch for that, but I think it acts more as LA just snooping on the bus. So you may need to add an actual i2c device (micro or PCF8574) on the bus for the master side to work at all. Kyösti On Thu, Sep 29, 2016 at 3:10 PM, Haleigh Novak <haleigh(a)edt.com<mailto:haleigh@edt.com>> wrote: > Hello All, > > > I am currently trying to send POST codes from Coreboot (downloaded > approximately a month ago) to a Beagle I2C/SPI reader, specifically via i2c. > I don't know the register needed for i2c_writeb() so I figured I would use > i2c_raw_write(). In general since I have been unable to locate anything > explaining the difference between the two functions I would really > appriciate it if someone could explain it or direct me to where I can find > documentation. I am hoping that the explaination/resource will either tell > me where / or direct me to how I can figure out where the i2c_raw_write will > write to (if it will just write directly to the Beagle or somewhere else)? > Or would it be better to send it to a register with i2c_writeb()? I am > running Coreboot on an ASROCK Mainboard, model IMB-A180. > > > Thank you. > > > HN > > > -- > coreboot mailing list: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> > https://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> https://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Attempt to porting coreboot to Gigabyte ga-945gcm-s2l
by Arthur Heymans 10 Oct '16

10 Oct '16

Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com> writes: > Hello Arthur, > > CPUID 1067x? Penryn? > https://en.wikipedia.org/wiki/Penryn_(microprocessor) ?! This is indeed the cpu which I used to run tests with. This board should also work with older LGA775 cpu I think. (even though coreboot has problems with CAR on this P4 HT 630 I also tried) > It is long time off any radar screen for INTEL IOTG support, I can tell to you this... Started production in 2007! :-(( WTH you need Coreboot on this one? What is INTEL IOTG support? > "The WBINVD instruction is a privileged instruction. When the processor is running in protected mode, the CPL of a program or procedure must be 0 to > execute this instruction. This instruction is also a serializing instruction (see "Serializing Instructions" in Chapter 8 of the IA-32 Intel Architecture Software > Developer's Manual, Volume 3)." > > Question to you: do you execute this instruction (WBINVD) in Ring 0 (kernel) mode? If you do, and it still hangs, I have for you a good suggestion: try to replace > WBINVD with INVD and see if you'll hang (simple logic stands behind > what I read there: > http://x86.renejeschke.de/html/file_module_x86_id_325.html). No idea, but I can certainly try it. > If you hang: your problem is for sure/100% NOT raminit (in other words MRC); > If you do NOT hang, and continue: raminit (MRC) might be (but not > certainly???) your problem. If you hang later (while accessing DDRAM), > then it is obvious! ;-) What I don't understand is that this is just southbridge code which is used by other boards too and that this instruction causes no issues to those other boards in the coreboot tree (like thinkpad x60). Having read all the i945 raminit code (this is not MRC but native coreboot code AFAIK) it does seem to be written with 667MHz fsb (945gm laptops like thinkpad x60)and 533MHz fsb (945gc inteld945gclf) in mind. So I will soon try to confirm this theory with 533MHz fsb cpu. > > Good luck with this one, > Zoran Kind regards -- Arthur Heymans

2 1

IOMMU on Skylake / Chell?
by Trammell Hudson 09 Oct '16

09 Oct '16

I've successfully built a coreboot firmware and Linux bootloader payload for the Chell Chromebook with Skylake, which then kexec's Xen / Qubes from the eMMC. Both of them are reporting that the IOMMU is not in use, and there is no DMAR entry in the ACPI table, which I believe is what they are looking for for enabling the IOMMU. The Xen console prints: > (XEN) I/O virtualization disabled And qubes-hcl reports: > I/O MMU: Not active What's involved in enabling it? How soon in the boot process can it be turned on? -- Trammell

1 0

Re: [coreboot] i2c_writeb vs i2c_raw_write output
by Kyösti Mälkki 08 Oct '16

08 Oct '16

On Sun, Oct 9, 2016 at 2:09 AM, Duncan Laurie <dlaurie(a)chromium.org> wrote: > > On Fri, Oct 7, 2016 at 5:51 PM, Julius Werner <jwerner(a)chromium.org> > wrote: > >> Also, I think all of these functions only work on non-x86 devices >> right now so they're probably not really helpful to you (I'd be >> surprised if they even compile and link for your board). The I2C API >> is unfortunately one of those areas where x86 and non-x86 coreboot >> still lead very separate side-by-side lives right now. For x86 you >> probably need the i2c_dev_xxx() functions, which should in theory work >> > > > Skylake and Apollolake do support the I2C API and associated convenience > functions. (finally!) The i2c driver used is common for intel chipsets > since haswell(core) and baytrail(atom), it just needs a bit of glue layer > to map bus number to a base address. > > I added the i2c_dev_* variants around the same time in order to support > drivers where the bus+address comes from devicetree, but the functions that > take a bus+address will work too. > > > >> similar but I have no experience with them. You might also need to use >> the smbus_xxx() functions instead (SMBUS is some >> kinda-the-same-but-not-quite thing related to I2C on x86 that I never >> bothered to fully understand). >> >> > > I agree this is likely what is needed for the ASROCK IMB-A180 as it looks > like there is an smbus driver in the southbridge. Look for > i2c_smbus_send_byte() in include/device/smbus.h which is implemented in > southbridge/amd/agesa/hudson/smbus.c > > > > -duncan > I have not used this particular Beagle i2c/spi reade. As part of the protocol, i2c/smbus master expects there is a slave device that first acknowledges it address, and then also each byte you send to it. Maybe this Beagle has a switch for that, but I think it acts more as LA just snooping on the bus. So you may need to add an actual i2c device (micro or PCF8574) on the bus for the master side to work at all. Kyösti > On Thu, Sep 29, 2016 at 3:10 PM, Haleigh Novak <haleigh(a)edt.com> wrote: >> > Hello All, >> > >> > >> > I am currently trying to send POST codes from Coreboot (downloaded >> > approximately a month ago) to a Beagle I2C/SPI reader, specifically via >> i2c. >> > I don't know the register needed for i2c_writeb() so I figured I would >> use >> > i2c_raw_write(). In general since I have been unable to locate anything >> > explaining the difference between the two functions I would really >> > appriciate it if someone could explain it or direct me to where I can >> find >> > documentation. I am hoping that the explaination/resource will either >> tell >> > me where / or direct me to how I can figure out where the i2c_raw_write >> will >> > write to (if it will just write directly to the Beagle or somewhere >> else)? >> > Or would it be better to send it to a register with i2c_writeb()? I am >> > running Coreboot on an ASROCK Mainboard, model IMB-A180. >> > >> > >> > Thank you. >> > >> > >> > HN >> > >> > >> > -- >> > coreboot mailing list: coreboot(a)coreboot.org >> > https://www.coreboot.org/mailman/listinfo/coreboot >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot >> > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] i2c_writeb vs i2c_raw_write output
by Duncan Laurie 08 Oct '16

08 Oct '16

On Fri, Oct 7, 2016 at 5:51 PM, Julius Werner <jwerner(a)chromium.org> wrote: > Also, I think all of these functions only work on non-x86 devices > right now so they're probably not really helpful to you (I'd be > surprised if they even compile and link for your board). The I2C API > is unfortunately one of those areas where x86 and non-x86 coreboot > still lead very separate side-by-side lives right now. For x86 you > probably need the i2c_dev_xxx() functions, which should in theory work > Skylake and Apollolake do support the I2C API and associated convenience functions. (finally!) The i2c driver used is common for intel chipsets since haswell(core) and baytrail(atom), it just needs a bit of glue layer to map bus number to a base address. I added the i2c_dev_* variants around the same time in order to support drivers where the bus+address comes from devicetree, but the functions that take a bus+address will work too. > similar but I have no experience with them. You might also need to use > the smbus_xxx() functions instead (SMBUS is some > kinda-the-same-but-not-quite thing related to I2C on x86 that I never > bothered to fully understand). > > I agree this is likely what is needed for the ASROCK IMB-A180 as it looks like there is an smbus driver in the southbridge. Look for i2c_smbus_send_byte() in include/device/smbus.h which is implemented in southbridge/amd/agesa/hudson/smbus.c -duncan > On Thu, Sep 29, 2016 at 3:10 PM, Haleigh Novak <haleigh(a)edt.com> wrote: > > Hello All, > > > > > > I am currently trying to send POST codes from Coreboot (downloaded > > approximately a month ago) to a Beagle I2C/SPI reader, specifically via > i2c. > > I don't know the register needed for i2c_writeb() so I figured I would > use > > i2c_raw_write(). In general since I have been unable to locate anything > > explaining the difference between the two functions I would really > > appriciate it if someone could explain it or direct me to where I can > find > > documentation. I am hoping that the explaination/resource will either > tell > > me where / or direct me to how I can figure out where the i2c_raw_write > will > > write to (if it will just write directly to the Beagle or somewhere > else)? > > Or would it be better to send it to a register with i2c_writeb()? I am > > running Coreboot on an ASROCK Mainboard, model IMB-A180. > > > > > > Thank you. > > > > > > HN > > > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > https://www.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] i2c_writeb vs i2c_raw_write output
by punit vara 07 Oct '16

07 Oct '16

+1 Julius. As an extra note you should also remember master can only enter writing mode after reading mode and slave can enter into reading mode only after writing mode. On Sat, Oct 8, 2016 at 6:21 AM, Julius Werner <jwerner(a)chromium.org> wrote: > I2C is a very simple bus format with some common conventions attached > to it that are followed by most (but not all) devices. You can find a > pretty good summary of how it works on Wikipedia: > https://en.wikipedia.org/wiki/I2C > > For devices which follow this convention, the device exposes registers > that usually have a 1-byte register address and contain somewhere > between 1 to 4 bytes of data (the convention isn't super strict in > many aspects, so a lot of it is device dependent). In order to write > to a register you're supposed to make two consecutive transactions > (with what's called a "repeated start" in between): one transaction > that writes the 1-byte register address, and one transaction that > writes the 1-4 bytes of data you want to write into that register. > Similarly, for a read you first do a write transaction with the > register address, followed by a read transaction where the device will > return the register contents. > > i2c_readb() and i2c_writeb() are convenience wrappers that encapsulate > this whole thing for registers containing 1-byte values for you. This > is what you want for most devices, but sometimes you have a device > that doesn't adhere to the conventions and needs special treatment > (e.g. maybe it doesn't really have a concept of registers at all and > just treats all data as a single stream or something). For those cases > you have i2c_read_raw() and i2c_write_raw(): these just directly read > or write any amount of raw bytes you want out on the bus. Therefore, > 'val = i2c_readb(1, 2, 3, 4)' is roughly equivalent to 'reg = 3 && > i2c_write_raw(1, 2, &reg, 1) && i2c_read_raw(1, 2, &val, 1)'. > > Also, I think all of these functions only work on non-x86 devices > right now so they're probably not really helpful to you (I'd be > surprised if they even compile and link for your board). The I2C API > is unfortunately one of those areas where x86 and non-x86 coreboot > still lead very separate side-by-side lives right now. For x86 you > probably need the i2c_dev_xxx() functions, which should in theory work > similar but I have no experience with them. You might also need to use > the smbus_xxx() functions instead (SMBUS is some > kinda-the-same-but-not-quite thing related to I2C on x86 that I never > bothered to fully understand). > > On Thu, Sep 29, 2016 at 3:10 PM, Haleigh Novak <haleigh(a)edt.com> wrote: >> Hello All, >> >> >> I am currently trying to send POST codes from Coreboot (downloaded >> approximately a month ago) to a Beagle I2C/SPI reader, specifically via i2c. >> I don't know the register needed for i2c_writeb() so I figured I would use >> i2c_raw_write(). In general since I have been unable to locate anything >> explaining the difference between the two functions I would really >> appriciate it if someone could explain it or direct me to where I can find >> documentation. I am hoping that the explaination/resource will either tell >> me where / or direct me to how I can figure out where the i2c_raw_write will >> write to (if it will just write directly to the Beagle or somewhere else)? >> Or would it be better to send it to a register with i2c_writeb()? I am >> running Coreboot on an ASROCK Mainboard, model IMB-A180. >> >> >> Thank you. >> >> >> HN >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

1 0

← Newer
1
...
9
10
11
12
13
14
15
Older →

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 October 2016