[coreboot] Re: IRQ routing: how to do the mainboard_picr_data/_intr_data structures?
Dear Naresh, please check the attached archive for these files (and tell if there's anything else I need to show) On Thu, Nov 5, 2020 at 8:08 PM Naresh G. Solanki wrote: > > Can you give following output with coreboot and OEM bios. > lspci -vvvk > dmesg > cat /proc/interrupt > > > On Thu, 5 Nov, 2020, 6:29 pm Mike Banon, wrote: >> >> Still need your help, friend >> >> On Sat, Oct 24, 2020 at 11:15 AM Mike Banon wrote: >> > >> > Although I found this article >> > https://www.coreboot.org/Creating_Valid_IRQ_Tables , I'm not sure if >> > it applies to mainboard_picr_data/_intr_data : considering a problem >> > from my previous msg - where a copy-paste of old picr/intr data >> > structures gave the bad results. Could you please clarify if this >> > article is still valid for these new data structures? If not, how to >> > get the correct values for mainboard_picr_data/_intr_data using Linux? >> > >> > >> > On Tue, Oct 20, 2020 at 6:23 PM Mike Banon wrote: >> > > >> > > Dear friends, I'm trying to properly program the IRQ tables for Lenovo >> > > G505S, because the old IRQ routing is bad and doesn't work for a >> > > simple OS like Kolibri. Full details are in the comments under this >> > > change: >> > > >> > > https://review.coreboot.org/c/coreboot/+/46587/ >> > > >> > > When I used the old picr_data/intr_data values of G505S for the new >> > > structures, I got only 1 IRQ working. However, with a copy-paste of >> > > AM1I-A - surprisingly 12 IRQs and a laptop boots, but still some >> > > problems. Please advise how to compose mainboard_picr_data/_intr_data >> > > and also a intel_irq_routing_table, your help will be very much >> > > appreciated. >> > > >> > > Best regards, >> > > Mike Banon >> ___ >> coreboot mailing list -- coreboot@coreboot.org >> To unsubscribe send an email to coreboot-le...@coreboot.org cmp.tar.gz Description: application/gzip ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Is HP ProLiant DL360e Gen8 supported in Coreboot?
Hello! I'm trying to find if my hardware supports Coreboot. I found 1 table which is retired, second that is probably not retired and then current documentation that doesn't seem to say as much. So, sorry if I missed it. Will Coreboot work with HP ProLiant DL360e Gen8? Flashrom worked ok but not great. Northbridge is Intel Sandy Bridge-E 07, Southbridge Intel X79 05. References: https://www.coreboot.org/Supported_Chipsets_and_Devices https://coreboot.org/status/board-status.html https://support.hpe.com/hpesc/public/docDisplay?docId=c03361169&docLocale=en_US https://browser.geekbench.com/geekbench3/1879558 https://doc.coreboot.org/mainboard/index.html https://doc.coreboot.org/northbridge/intel/sandybridge/index.html Flashrom log: flashrom v1.2 on Linux 5.4.0-42-generic (x86_64) flashrom is free software, get the source code at https://flashrom.org Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Found chipset "Intel C60x/X79". Enabling flash write... FREG0: Flash Descriptor region (0x-0x) is read-only. FREG2: Management Engine region (0x0001-0x001f) is locked. Not all flash regions are freely accessible by flashrom. This is most likely due to an active ME. Please see https://flashrom.org/ME for details. At least some flash regions are read protected. You have to use a flash layout and include only accessible regions. For write operations, you'll additionally need the --noverify-all switch. See manpage for more details. OK. Found Macronix flash chip "MX25L1605" (2048 kB, SPI) mapped at physical address 0xffe0. Found Macronix flash chip "MX25L1605A/MX25L1606E/MX25L1608E" (2048 kB, SPI) mapped at physical address 0xffe0. Found Macronix flash chip "MX25L1605D/MX25L1608D/MX25L1673E" (2048 kB, SPI) mapped at physical address 0xffe0. Multiple flash chip definitions match the detected chip(s): "MX25L1605", "MX25L1605A/MX25L1606E/MX25L1608E", "MX25L1605D/MX25L1608D/MX25L1673E" Please specify which chip definition to use with the -c option. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Is HP ProLiant DL360e Gen8 supported in Coreboot?
Hi, On Mon, Nov 9, 2020 at 6:42 PM wrote: > > Hello! I'm trying to find if my hardware supports Coreboot. I found 1 table > which is retired, second that is probably not retired and then current > documentation that doesn't seem to say as much. So, sorry if I missed it. > Will Coreboot work with HP ProLiant DL360e Gen8? Flashrom worked ok but not > great. Northbridge is Intel Sandy Bridge-E 07, Southbridge Intel X79 05. Short answer: Nope. Long answer: Porting this board would be extremely time-consuming (several years for an experienced developer working exclusively on it), because there's no support at all for the chipset. While there's support for mundane Sandy (and Ivy) Bridge consumer (desktop, mobile, uniprocessor server) hardware, the SA and PCH (System Agent and Platform Controller Hub, i.e. integrated northbridge and southbridge respectively) on server platforms are radically different beasts. Memory initialization is by far the most complex thing that would need to be implemented, and the registers aren't publicly documented and differ across generations, as well as between consumer and server platforms. > References: > https://www.coreboot.org/Supported_Chipsets_and_Devices > https://coreboot.org/status/board-status.html > https://support.hpe.com/hpesc/public/docDisplay?docId=c03361169&docLocale=en_US > https://browser.geekbench.com/geekbench3/1879558 > https://doc.coreboot.org/mainboard/index.html > https://doc.coreboot.org/northbridge/intel/sandybridge/index.html > > Flashrom log: > > flashrom v1.2 on Linux 5.4.0-42-generic (x86_64) > flashrom is free software, get the source code at https://flashrom.org > > Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). > Found chipset "Intel C60x/X79". > Enabling flash write... FREG0: Flash Descriptor region > (0x-0x) is read-only. > FREG2: Management Engine region (0x0001-0x001f) is locked. > Not all flash regions are freely accessible by flashrom. This is most likely > due to an active ME. Please see https://flashrom.org/ME for details. > At least some flash regions are read protected. You have to use a flash > layout and include only accessible regions. For write operations, you'll > additionally need the --noverify-all switch. See manpage for more details. > OK. > Found Macronix flash chip "MX25L1605" (2048 kB, SPI) mapped at physical > address 0xffe0. > Found Macronix flash chip "MX25L1605A/MX25L1606E/MX25L1608E" (2048 kB, SPI) > mapped at physical address 0xffe0. > Found Macronix flash chip "MX25L1605D/MX25L1608D/MX25L1673E" (2048 kB, SPI) > mapped at physical address 0xffe0. > Multiple flash chip definitions match the detected chip(s): "MX25L1605", > "MX25L1605A/MX25L1606E/MX25L1608E", "MX25L1605D/MX25L1608D/MX25L1673E" > Please specify which chip definition to use with the -c option. This is expected for this kind of platform, since the IFD (Intel Flash Descriptor) specifies the regions of the flash chip and their access permissions. > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] System gcc requirements
I recently looked in to why I couldn't build coreboot on one of my systems any longer and I think I found the cause. It looks like vboot uses features not available in gcc 6 on Debian Stretch. I actually did manage to get it to build and work by commenting out the offending gcc warning flags and a fallthrough switch attribute, but that's kind of pointless. Is there an expected minimal system gcc version and if so, is it documented? I couldn't find it noted anywhere. Branden ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: System gcc requirements
Branden Waldner wrote: > Is there an expected minimal system gcc version and if so, is it > documented? I couldn't find it noted anywhere. There's the crossgcc tool and make target to create a known-working toolchain for building coreboot. //Peter ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: System gcc requirements
On Mon, Nov 9, 2020 at 5:38 PM Peter Stuge wrote: > Branden Waldner wrote: > > Is there an expected minimal system gcc version and if so, is it > > documented? I couldn't find it noted anywhere. > > There's the crossgcc tool and make target to create a known-working > toolchain for building coreboot. > > > See: https://doc.coreboot.org/tutorial/part1.html Step 3 - Build the coreboot toolchain Please note that this can take a significant amount of time. Use CPUS= to specify number of make jobs to run in parallel. This will list toolchain options and supported architectures: $ make help_toolchain Here are some examples: $ make crossgcc-i386 CPUS=$(nproc) # build i386 toolchain $ make crossgcc-aarch64 CPUS=$(nproc)# build Aarch64 toolchain $ make crossgcc-riscv CPUS=$(nproc) # build RISC-V toolchain Note that the i386 toolchain is currently used for all x86 platforms, including x86_64. Also note that you can possibly use your system toolchain, but the results are not reproducible, and may have issues, so this is not recommended. See step 5 to use your system toolchain. > //Peter > ___ > 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: System gcc requirements
On 10.11.20 00:38, Peter Stuge wrote: > Branden Waldner wrote: >> Is there an expected minimal system gcc version and if so, is it >> documented? I couldn't find it noted anywhere. I don't think it's documented. As you already noticed, we depend on a 3rdparty library (vboot), so we actually don't know the minimum. > > There's the crossgcc tool and make target to create a known-working > toolchain for building coreboot. Only for the cross-compilation part, though. For the build utils, the system's toolchain is used. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: System gcc requirements
Nico Huber wrote: > I don't think it's documented. As you already noticed, we depend on > a 3rdparty library (vboot), so we actually don't know the minimum. Whenever I want a build without vboot I get really annoyed about this hardcoded dependency, even when vboot is disabled in Kconfig. Would a patch to make the dependency conditional on Kconfig get accepted? //Peter ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Flashing coreboot and Intel Flash Descriptor Erase Issue
Hi Balaji, On Tue, Nov 3, 2020 at 10:03 PM Balaji Sivakumar wrote: > > Hi David, > > Have verified and confirmed that coreboot process as well, it is > disabling the BIOS write protect and Enable Prefetching and Caching as part > of fast_spi_init(). > Were you able to figure this one out? The snippet you showed is from fast_spi_init() which should get called once early on. It is possible that something later on calls fast_spi_enable_wp(), perhaps smihandler_soc_check_illegal_access(). ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: System gcc requirements
On Mon, Nov 9, 2020 at 4:51 PM Peter Stuge wrote: > Nico Huber wrote: > > I don't think it's documented. As you already noticed, we depend on > > a 3rdparty library (vboot), so we actually don't know the minimum. > > Whenever I want a build without vboot I get really annoyed about this > hardcoded dependency, even when vboot is disabled in Kconfig. > > Would a patch to make the dependency conditional on Kconfig get accepted? I should hope so, though I recommend starting a new thread to see if experts on vboot can chime in and explain why this is or isn't a good idea. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
