[coreboot] Re: BIOS chip address range?
Rafael Send wrote: > If I theoretically had a flash chip that was larger than 128Mb, it > requires 3-4 byte addressing. The de facto standard commands all use 3 byte addresses. > Does / could coreboot support such large memory, or would the > limitation live somewhere else in the system? coreboot doesn't need to know about SPI. (It does, e.g. to enable block locks for some chips, but that's unrelated to booting.) The platform hardware exposes the SPI flash mapped at top of 4 GByte of physical address space. The platform hardware would have to know to use 4 byte address commands. I don't know if any platforms do - I guess that they don't. //Peter ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] GSoC 2019
Hi, I am Daniel, a computer engineering student at the National University of Singapore. I am interested in extending Ghidra to support the analysis of firmware images. However, I am unsure whether this would be a sufficiently big project for GSoC, and whether I should have an additional one. If that's the case, I would like to also work on porting the GRUB2 payload to the RISC-V architecture. Apart from that, to familiarize myself with the code review process of coreboot, I have made a simple change to cpu/ti/am335x, fixing warnings from checkpatch. May I know who can I add to review it? The patch can be found at https://review.coreboot.org/c/coreboot/+/32119 . Last but not least, may I ask for the scope of GSoC, should I ask questions more on the mailing list or IRC? I am looking forward to learning from you all. Thanks. Regards, Daniel Lim ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] FSP2.0 DQ byte map
Hi, I am wondering what is the format of CPU-DRAM DQ byte map for FSP-M configuration. Typically there are 64 DQ lanes per non-ECC SODIMM/DIMM (correct me if I'm wrong) for DDR4 for example. But the DQ map is an 2x12 array, so I assume 12 bytes for each channel (why not 8 bytes?). My questions are: 1. Why there are more bytes in array than DQ lanes? 2. How should I define the DQ map? Does 0xFF or 0x00 mean 1 to 1 mapping? 3. Some FSP2.0 mainboards have values like 0x0F and 0xF0 in their mappings which looks like 1 byte swap, but there are also 0xCC and 0x33. What is the difference? The DQS mapping is clear to me (rather obvious as there are only 8 DQS which matches the 2x8 array). I know about 3 Rcomp resistors of the chipset and what they are for, but what RcompTarget is? In the code I can see function `mainboard_fill_rcomp_strength_data` and begin to wonder what rcomp strength is (not Rcomp Target?). How to correctly fill RcompTarget FSP-M configuration? Any tips and pointers appreciated. Regards, -- Michał Żygowski Firmware Engineer http://3mdeb.com | @3mdeb_com ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: FSP2.0 DQ byte map
Hi Michal, On 29.03.19 16:49, Michal Zygowski wrote: > I am wondering what is the format of CPU-DRAM DQ byte map for FSP-M > configuration. Typically there are 64 DQ lanes per non-ECC SODIMM/DIMM > (correct me if I'm wrong) for DDR4 for example. But the DQ map is an > 2x12 array, so I assume 12 bytes for each channel (why not 8 bytes?). My > questions are: > > 1. Why there are more bytes in array than DQ lanes? it's actually not an array but a rather complex structure. You can find some clues in the Skylake FSP Integration Guide [1] and also in coreboot header files [2]. I have no idea why the documentation was removed from future guides. > 2. How should I define the DQ map? Does 0xFF or 0x00 mean 1 to 1 mapping? If you have DDR4 (SO)DIMMs, you probably shouldn't. [2] mentions that it's for memory-down configurations with LPDDR3 only. And, AFAIR, an investigation into the deep of the KBL FSP source didn't find any relation to DDR4. > I know about 3 Rcomp resistors of the chipset and what they are for, but > what RcompTarget is? > In the code I can see function `mainboard_fill_rcomp_strength_data` and > begin to wonder what rcomp strength is (not Rcomp Target?). How to > correctly fill RcompTarget FSP-M configuration? Please tell me if you find out ;) even Intel developers working on coreboot don't know. Some insider came back quoting identifiers from comments in the FSP header... identifiers nowhere to be found in source/documentation. My guess is that the targets are either computed or even measured by some very confidential tool. Nico [1] https://github.com/IntelFsp/FSP/raw/master/SkylakeFspBinPkg/Docs/SkylakeFspIntegrationGuide.pdf [2] https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/broadwell/include/soc/pei_data.h#n236 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: BIOS chip address range?
Hello Rafael, On 28.03.19 17:12, Rafael Send wrote: > Where would I generally find information about what controls the flash chip? in the datasheet of the chip that is connected to the BIOS flash. What chip that is, is not always easy to answer. If you don't have access to the board's schematics, visual inspection might help. What Peter told us, btw., applies only to x86 platforms. If you target x86, coreboot support for more than 16MiB will be hard, because that is the limit what is memory mapped. To access more than 16MiB on x86, you'd need a SPI driver (which coreboot has) and use that to access files (which is the harder part, because coreboot on x86 is special). Please tell us more about your target hardware and use case. Usually, you don't need that much flash for coreboot. So there may be other options to consider (e.g. a SPI driver in your payload). Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: GSoC 2019
I think extending ghidra is a great idea, and it is more than enough for a gsoc. On Fri, Mar 29, 2019 at 6:03 AM Daniel Lim wrote: > > Hi, > > I am Daniel, a computer engineering student at the National University > of Singapore. > > I am interested in extending Ghidra to support the analysis of > firmware images. However, I am unsure whether this would be a > sufficiently big project for GSoC, and whether I should have an > additional one. If that's the case, I would like to also work on > porting the GRUB2 payload to the RISC-V architecture. > > Apart from that, to familiarize myself with the code review process of > coreboot, I have made a simple change to cpu/ti/am335x, fixing > warnings from checkpatch. May I know who can I add to review it? The > patch can be found at https://review.coreboot.org/c/coreboot/+/32119 . > > Last but not least, may I ask for the scope of GSoC, should I ask > questions more on the mailing list or IRC? > > I am looking forward to learning from you all. Thanks. > > Regards, > Daniel Lim > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: BIOS chip address range?
Hi Nico- Can you clarify what you mean by coreboot on x86 is special? Does that mean even if 3-byte addresses are supported (which would allow addressing more than 128Mb / 16MiB of memory), it specifically doesn't work on x86? I'm looking at the coreboot port that was done for the Thinkpad X210, which is a Chinese custom motherboard that updates the X201 form factor with an i7-8650U / i7-8550u / i5-8250U CPU, and just for the hell of it I'm wondering what the largest piece of BIOS memory is I can get on there. Hardware-wise, I can get up to 512Mb / 64MiB into the chip form factor. If we can address it, that opens up interesting possibilities for embedding full OS distributions there (such as my previous question about TinyCore). Gruß, R On Fri, Mar 29, 2019 at 10:10 AM Nico Huber wrote: > > Hello Rafael, > > On 28.03.19 17:12, Rafael Send wrote: > > Where would I generally find information about what controls the flash chip? > > in the datasheet of the chip that is connected to the BIOS flash. What > chip that is, is not always easy to answer. If you don't have access to > the board's schematics, visual inspection might help. > > What Peter told us, btw., applies only to x86 platforms. If you target > x86, coreboot support for more than 16MiB will be hard, because that is > the limit what is memory mapped. To access more than 16MiB on x86, you'd > need a SPI driver (which coreboot has) and use that to access files > (which is the harder part, because coreboot on x86 is special). > > Please tell us more about your target hardware and use case. Usually, > you don't need that much flash for coreboot. So there may be other > options to consider (e.g. a SPI driver in your payload). > > Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: BIOS chip address range?
On 29.03.19 19:08, Rafael Send wrote: > Hi Nico- > Can you clarify what you mean by coreboot on x86 is special? on x86, there are two ways to access a SPI flash chip: 1. you can ask the SPI controller via a register based interface to access the flash chip. 2. by default, the flash chip contents of the BIOS region* of the flash chip is memory mapped (i.e. you can read from it just like you read from RAM). 1. may support >16MiB chips/regions. 2. is usually limited to 8MiB or 16MiB depending on the chipset. I would guess 16MiB in your case, but I can't promise. 2. is used by coreboot. However, with some additional code you can also use 1. *Intel shares the flash chip with other chipset components, e.g. ME firmware. > > Does that mean even if 3-byte addresses are supported (which would allow > addressing more than 128Mb / 16MiB of memory), it specifically doesn't work > on x86? No. The x86 thing is just a current software limitation that can be lifted. But still, there may be chips (e.g. EC) between the flash and the Intel chipset that may have their own limits. > > I'm looking at the coreboot port that was done for the Thinkpad X210, which > is a Chinese custom motherboard that updates the X201 form factor with an > i7-8650U / i7-8550u / i5-8250U CPU, and just for the hell of it I'm > wondering what the largest piece of BIOS memory is I can get on there. > Hardware-wise, I can get up to 512Mb / 64MiB into the chip form factor. If > we can address it, that opens up interesting possibilities for embedding > full OS distributions there (such as my previous question about TinyCore). The chipset supports up to two chips of 64MiB each. But I don't know if the flash is directly connected. In case of a full OS in flash, I would suggest a SPI driver in the OS kernel, anyway. Otherwise, you'd have to let coreboot load a lot of data from flash at once and that would slow it down (but that doesn't have to be a concern). Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: BIOS chip address range?
'Tag- Good information. However, as I'm an EE not a SW engineer I wouldn't be able to make any modifications to coreboot code myself (at least not without a lot of time & study). Hardware modifications on the other hand are easier for me. Also, I was incorrect about the largest part I can get in the correct footprint. It's actually "only" 256Mb / 32MiB. R On Fri, Mar 29, 2019 at 12:03 PM Nico Huber wrote: > On 29.03.19 19:08, Rafael Send wrote: > > Hi Nico- > > Can you clarify what you mean by coreboot on x86 is special? > > on x86, there are two ways to access a SPI flash chip: 1. you can ask > the SPI controller via a register based interface to access the flash > chip. 2. by default, the flash chip contents of the BIOS region* of > the flash chip is memory mapped (i.e. you can read from it just like > you read from RAM). > > 1. may support >16MiB chips/regions. > > 2. is usually limited to 8MiB or 16MiB depending on the chipset. I > would guess 16MiB in your case, but I can't promise. > > 2. is used by coreboot. However, with some additional code you can > also use 1. > > *Intel shares the flash chip with other chipset components, e.g. > ME firmware. > > > > > Does that mean even if 3-byte addresses are supported (which would allow > > addressing more than 128Mb / 16MiB of memory), it specifically doesn't > work > > on x86? > > No. The x86 thing is just a current software limitation that can be > lifted. But still, there may be chips (e.g. EC) between the flash and > the Intel chipset that may have their own limits. > > > > > I'm looking at the coreboot port that was done for the Thinkpad X210, > which > > is a Chinese custom motherboard that updates the X201 form factor with an > > i7-8650U / i7-8550u / i5-8250U CPU, and just for the hell of it I'm > > wondering what the largest piece of BIOS memory is I can get on there. > > Hardware-wise, I can get up to 512Mb / 64MiB into the chip form factor. > If > > we can address it, that opens up interesting possibilities for embedding > > full OS distributions there (such as my previous question about > TinyCore). > > The chipset supports up to two chips of 64MiB each. But I don't know if > the flash is directly connected. > > In case of a full OS in flash, I would suggest a SPI driver in the OS > kernel, anyway. Otherwise, you'd have to let coreboot load a lot of data > from flash at once and that would slow it down (but that doesn't have to > be a concern). > > Nico > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] QQ/
DDR RComp calculation is explained in the CPU platform design guide. If you are an Intel licensee, you can request this document by number - 561280 for KBL. There seems to be also a whitepaper you can ask your OEM rep for. The actual values are calculated based on memory topology and board layout and then fine-tuned through measurement. Basically, if you are a system designer, you have the documents and know how to do it, and if you are not, then these values are calculated by the manufacturer/BIOS writer so your only recourse is to find out from them. Similarly, DQ array is filled according to the information supplied by the system designer. Intel CPUs allow certain freedom in routing the memory pins to simplify the board layout task. The pin map should be filled for DQ/DQS according to the physical connectivity chosen by the system designer. Bottom line - it's not something you can figure out by looking at a motherboard From: Nico Huber Sent: Friday, March 29, 2019 10:03 AM To: Michal Zygowski; coreboot@coreboot.org Subject: [coreboot] Re: FSP2.0 DQ byte map Hi Michal, On 29.03.19 16:49, Michal Zygowski wrote: > I am wondering what is the format of CPU-DRAM DQ byte map for FSP-M > configuration. Typically there are 64 DQ lanes per non-ECC SODIMM/DIMM > (correct me if I'm wrong) for DDR4 for example. But the DQ map is an > 2x12 array, so I assume 12 bytes for each channel (why not 8 bytes?). My > questions are: > > 1. Why there are more bytes in array than DQ lanes? it's actually not an array but a rather complex structure. You can find some clues in the Skylake FSP Integration Guide [1] and also in coreboot header files [2]. I have no idea why the documentation was removed from future guides. > 2. How should I define the DQ map? Does 0xFF or 0x00 mean 1 to 1 mapping? If you have DDR4 (SO)DIMMs, you probably shouldn't. [2] mentions that it's for memory-down configurations with LPDDR3 only. And, AFAIR, an investigation into the deep of the KBL FSP source didn't find any relation to DDR4. > I know about 3 Rcomp resistors of the chipset and what they are for, but > what RcompTarget is? > In the code I can see function `mainboard_fill_rcomp_strength_data` and > begin to wonder what rcomp strength is (not Rcomp Target?). How to > correctly fill RcompTarget FSP-M configuration? Please tell me if you find out ;) even Intel developers working on coreboot don't know. Some insider came back quoting identifiers from comments in the FSP header... identifiers nowhere to be found in source/documentation. My guess is that the targets are either computed or even measured by some very confidential tool. Nico [1] https://github.com/IntelFsp/FSP/raw/master/SkylakeFspBinPkg/Docs/SkylakeFspIntegrationGuide.pdf [2] https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/broadwell/include/soc/pei_data.h#n236 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: GSoC 2019 - HW bringup
Martin, Thank you for the reply. I think I will stick with one of the suggested project ideas for GSoC, but I will definitely continue to work on ports for my hardware on the side. Regarding the Ghidra loader project idea, is there an assigned mentor? I have some questions regarding the scope of the project. In addition to a loader for firmware images, I think scripts for importing common UEFI types/structures/GUIDs could be useful. Similar scripts [1, 2] are available for IDA Pro. Having such tools for Ghidra could assist with UEFI reverse engineering. [1] https://github.com/snare/ida-efiutils [2] https://github.com/danse-macabre/ida-efitools Thank you again. I look forward to contributing to this project. Alex On Thu, Mar 28, 2019 at 11:16 AM Martin Roth wrote: > Hi Alex, > I think that porting the gigabyte platform could be at least part of > a GSOC project. The port by itself probably wouldn't be enough to be > considered a full project, since much of the work can already be done > automatically by autoport. > > I'd probably discourage the HP port due to the age of the platform and > the possible difficulty with the embedded controller, but wouldn't > strictly rule it out as a gsoc project. > > Martin > > On Wed, Mar 27, 2019 at 12:40 PM Alex James > wrote: > > > > Hello, > > > > I am a student interested in contributing to coreboot as part of GSoC > 2019. I have seen the ideas list on the documentation page, and I am > considering working on fixing issues reported by Coverity Scan, and maybe > additional work on firmware RE tools. However, I would like to know if > ports to new mainboards/systems would be an acceptable project. I have an > Ivy Bridge desktop (Gigabyte GA-Z77X-UD5H) as well as a Arrandale laptop > (HP Pavilion dv7), and I am interested in porting coreboot to these > platforms. I do have some experience with UEFI programming in C (as well as > x86(_64) ASM). > > > > Thank you. > > Alex James > > ___ > > coreboot mailing list -- coreboot@coreboot.org > > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
