summaryrefslogtreecommitdiff
path: root/src/mainboard/asus/f2a85-m
AgeCommit message (Collapse)Author
2014-04-13hudson boards: Don't require ide.asl file on boards without IDEAlexandru Gagniuc
Not all boards which use the AMD Hudson southbridge have IDE. However, the southbridge's asl included an 'ide.asl' file which had to be present in $(mainboard_dir)/acpi. Address this issue by removing the inclusion of 'ide.asl' from the southbridge 'fch.asl' and remove 'ide.asl' from Hudson boards, none of which have IDE. If future hudosn board will come with IDE, the device can be declared in the PCIO scope of dsdt.asl, right below the inclusion of 'fch.asl'. Change-Id: Ie2efb7ebf8f5b527e26d7aaaeafbd3053a9a6b28 Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/5459 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-04-09asus/f2a85-m: conditionally show POST codesIdwer Vollering
Change-Id: I61e55601676c0825815d6520a874ccade8942379 Signed-off-by: Idwer Vollering <vidwer@gmail.com> Reviewed-on: http://review.coreboot.org/5362 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-04-06asus/f2a85-m: Sanitize #includesIdwer Vollering
Based on the same reasoning as this commit: 1d87dac hp/pavilion_m6_1035dx: Sanitize #includes Change-Id: I383f79b5392ee1ca244e403f755213fa7b32c0af Signed-off-by: Idwer Vollering <vidwer@gmail.com> Reviewed-on: http://review.coreboot.org/5420 Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-01-19board-status: Add board_info.txt extracted from wiki.Vladimir Serbinenko
board_info.txt is a file to be used by board-status to add some useful info to the generated table like flash chip type. This series is autogenerated from wiki page Supported_Motherboards. Change-Id: Ie2bda900713ef4883134477163320936c84c34f5 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/4701 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-01-15Re-declare CACHE_ROM_SIZE as aligned ROM_SIZE for MTRRKyösti Mälkki
This change allows Kconfig options ROM_SIZE and CBFS_SIZE to be set with values that are not power of 2. The region programmed as WB cacheable will include all of ROM_SIZE. Side-effects to consider: Memory region below flash may be tagged WRPROT cacheable. As an example, with ROM_SIZE of 12 MB, CACHE_ROM_SIZE would be 16 MB. Since this can overlap CAR, we add an explicit test and fail on compile should this happen. To work around this problem, one needs to use CACHE_ROM_SIZE_OVERRIDE in the mainboard Kconfig and define a smaller region for WB cache. With this change flash regions outside CBFS are also tagged WRPROT cacheable. This covers IFD and ME and sections ChromeOS may use. Change-Id: I5e577900ff7e91606bef6d80033caaed721ce4bf Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/4625 Tested-by: build bot (Jenkins) Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2013-12-26AMD AGESA: Drop MEM_TRAIN_SEQKyösti Mälkki
This config was for AMD K8 only. Change-Id: Ic1ce60041fef6ddee2dae0e3559fb78f088740af Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/4556 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-11-22AMD f15tn, f16kb: Remove CDIT table and DMI tableWANG Siyuan
On AMD Trinity and Kabini boards errors similar to the following are shown. ASSERTION FAILED: file 'src/mainboard/asrock/imb-a180/agesawrapper.c',line 431 DmiTable:100123f7, AcpiPstatein: 10010129,AcpiSrat:0,AcpiSlit:0, Mce:10010de9,Cmc:10010eab,Alib:1002111c, AcpiIvrs:0 in agesawrapper_amdinitlate agesawrapper_amdinitlate failed: 5 The reason is that on f16kb boards, the CDIT and DMI table are not created. On f15tn boards, only the DMI table is not created. Until the root cause is found, disable the table generation to remove the errors. Thanks to Wei Hu for debugging and reporting this issue on the list [1]. [1] http://www.coreboot.org/pipermail/coreboot/2013-November/076607.html CDIT table is not created Change-Id: I837e3c322bb5331a9b950a72397796a60642c3f3 Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com> Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com> Reviewed-on: http://review.coreboot.org/4092 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
2013-11-19Asus F2A85-M: Fix S3 memory power cut-offRudolf Marek
The power to memory is lost during the the suspend, activate the 3VSBSW# which switches the power during S3 suspend sequence. As a result resuming from suspend to RAM works now, but now the GPP ports of the Hudson southbridge are gone after resume from S3. The devices 15.0 and 15.1 are disabled (decode as ffff) and therefore anything behind them too [1]. [1] http://www.coreboot.org/pipermail/coreboot/2013-November/076620.html fam15tn hudson PCIe GPP ports off after resume Change-Id: Id953313ee4400a03a2ad8ca09e39a5e0d5f92524 Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Reviewed-on: http://review.coreboot.org/4041 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2013-11-12AMD Hudson: Move function s3_resume_init_data to southbridgeZheng Bao
Besides the AGESA static settings, the settings in mainboard/buildOpt.c also change the final configuration. We need to make sure the settings in FchParam in resume stage are the same as they were in cold boot stage, otherwise the board can not wake up more than once. Tested on AMD/Olive Hill, AMD/Parmer and ASRock/imb-a180. (USB keyboard doesn't work when board wakes up. It is not introduced by this patch. It needs more debugging.) Change-Id: I5a5e5502080e358ffc3577dc6a40bb762844d998 Signed-off-by: Zheng Bao <zheng.bao@amd.com> Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: http://review.coreboot.org/3932 Tested-by: build bot (Jenkins) Reviewed-by: Rudolf Marek <r.marek@assembler.cz>
2013-10-07AMD hudson yangtze: Fix corruption of a global ramstage variableKyösti Mälkki
A late for loop may reference over the current array allocation and corrupt an unrelated global variable. As a quick fix bumb the size of the array allocation uniformly to 6. We missed these boards for commit 9c7d73ca because the arrays had been renamed. Change-Id: Iff2f2a0090d9302576bc72195d2a3f6fa37ce29a Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3954 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
2013-09-19ASUS F2A85-M: Correct and clean up PCIe configRudolf Marek
Assign the lanes correctly to the physical slots on the motherboard in `PlatformGnbPcie.c`. • UMI is connected to SB via 4x PCIe bridge 8. • The blue x16 slot is not shared with DDI and is routed through PCIe bridge 2. • The black x8 slot is in fact a x4 slot and uses all 4 GPPs from the CPU. • Assume that DDI is on out-of-PCIe-band lanes. Change-Id: I44c4c83e6a8e31d6150a602a0993972ac63105bd Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3194 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com> Reviewed-by: David Hubbard <david.c.hubbard+coreboot@gmail.com>
2013-08-15Include boot_cpu.c for romstage buildsKyösti Mälkki
ROMCC boards were left unmodified. Change-Id: I3d842196b3f5b6999b6891b914036e9ffcc3cef0 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3853 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-08-15ASUS F2A85-M: Provide HD Audio verb table for Realtek ALC887-VDRudolf Marek
Use the same HD Audio [1] verb table for the Realtek ALC887-VD audio chip as the one set up by the proprietary vendor BIOS. Linux’ ALSA exposes this pin configuration under the virtual filesystem sysfs. /sys/class/sound/hwC1D0/init_pin_configs The script `alsa-info.sh` [2][3] is able to decode the table. Only one channel audio playback (rear connectors) is tested [4], which worked already before. [1] http://en.wikipedia.org/wiki/Intel_High_Definition_Audio [2] http://mailman.alsa-project.org/pipermail/alsa-devel/2013-March/060717.html [3] http://alsa-project.org/main/index.php/Help_To_Debug [4] http://review.coreboot.org/#/c/3170/2//COMMIT_MSG Change-Id: I17fa2d4ab1e1a6bfd84de94e9e4a91bd67b6a0c0 Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3170 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-08-15AMD Fam15tn boards: BiosCallOuts.c: Remove board name from `CodecTableList`Paul Menzel
The board name in that variable name is not necessary, as it is not board dependent, that means using the file as a template for making a new coreboot port for another motherboard the variable does not need to be changed, and just increases the code differences between AMD Parmer, AMD Thather and ASUS F2A85-M. So use a generic name. The same was done for AMD Persimmon (and inherited by the LiPPERT FrontRunner/Toucan-AF) in the following commit. commit 5e70766f14253f53190ddd49a544460c6bc1e528 Author: Jens Rottmann <JRottmann@LiPPERTembedded.de> Date: Tue Feb 26 15:56:11 2013 +0100 AMD Fam14 boards: reduce unnecessary differences, 2nd attempt Reviewed-on: http://review.coreboot.org/2529 The board name is *not* removed from the `CODEC_ENTRY` variable name as the verb table not only depends on the codec but also on the board [1]. Having the board name in the variable name is a good indicator that the pin configuration needs to be adapted when taking this file as a template for a new port. If it was board independent, a default chip configuration could be used and shared between all boards, which is unfortunately not the case. [1] Unfortunately I was not able to find Jens’ comment in my mail archive and in the Gerrit Web interface. Not sure where it is, but I am sure he made that comment. Change-Id: I440a306cf4ff0a5b1b61d1983d70c66d129904d0 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3199 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-08-08ASUS F2A85-M: Split DSDT into common sections (as per Parmer)Kimarie Hoot
Rearranged the F2A85-M DSDT file to match the functionality found on Parmer. As with the Parmer implementation, the F2A85-M dsdt.asl file in the mainboard directory contains only #include references to the appropriate files. As with Parmer, some include files have no content but are left as a template for other platforms and as placeholders for completing the ACPI implementation for F2A85-M. Change-Id: Ic72cb6004538ca9d9f79826b9b3c8d6aeb25017c Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com> Reviewed-on: http://review.coreboot.org/3805 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin@se-eng.com>
2013-07-10Rename hardwaremain() to main()Stefan Reinauer
... and drop the wrapper on ARMv7 Change-Id: If3ffe953cee9e61d4dcbb38f4e5e2ca74b628ccc Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3639 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-24AMD: Drop empty root_complexKyösti Mälkki
There are no files to build left under AMD nortbridge/x/root_complex directories. For some cases, even the Kconfig file was no longer sourced. Remove all such references and empty files. For devicetree.cb treat component paths with "/root_complex" in them valid even when the directory does not exists. This is because AMD boards us this dummy chip component as the root node in their devicetree.cb. The generated devicetree file static.c remains unchanged. Change-Id: I9278ebb50a83cebbf149b06afb5669899a8e4d0b Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3434 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-06-24Asus F2A85-M: Add IRQs for IOMMURudolf Marek
The IOMMU needs IRQs assigned. So add those. Change-Id: Ic9f02e28aac593cddf7d222a8abb780a10572d32 Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Reviewed-on: http://review.coreboot.org/3318 Tested-by: build bot (Jenkins) Reviewed-by: David Hubbard <david.c.hubbard+coreboot@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-23AMD boards: routing.asl: Uniformly start `Package()` with capital letterPaul Menzel
In commit Rudolf Marek discovered, that it is not uniformly written. As »ASL names are not case-sensitive and will be converted to upper case.« [2] this change does not have any functional change. The following command was used to create this patch. $ git grep -l 'package()' src/mainboard | xargs sed -i 's,package(),Package(),' [1] http://review.coreboot.org/#/c/3318/ [2] http://www.acpi.info/spec40a.htm (18.2.1 ASL Names) Change-Id: I1784dbc50936a1ef9d4376209a3c324ef1fb85cf Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3516 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-06-17AMD southbridges: Move HAVE_HARD_RESETKyösti Mälkki
All 3 boards with AGESA_HUDSON had HAVE_HARD_RESET with the reset.c file already placed under southbridge/. All 15 boards with CIMX_SBx00 had HAVE_HARD_RESET with functionally identical reset.c file under mainboard/. Move those files under respective southbridge/. Change-Id: Icfda51527ee62e578067a7fc9dcf60bc9860b269 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3486 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-06-17Add support for XHCI (USB 3.0)Dave Frodin
CONFIG_HUDSON_XHCI_ENABLE will control the XHCI flags in the amd/parmer and asus/f2a85-m mainboards. The XHCI ports on amd/thatcher are not wired to USB jacks so always disable the flags. This was tested on amd/parmer using a USB 3.0 thumbdrive. Change-Id: I596b040fec30882d8d4dee34ab9f866dc1f8896b Signed-off-by: Dave Frodin <dave.frodin@se-eng.com> Reviewed-on: http://review.coreboot.org/3465 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-05Revert "Asus F2A85-M: Activate IOMMU support"Paul Menzel
This reverts commit eed28f97b375a9469a2872996c19eb102647052e. For whatever reason, the dependencies were lost in Gerrit and the commit [1] was submitted without its dependencies. As a result buidling the ASUS F2A85-M fails now [2] and therefore commits based on this commit fail to pass the buid tests by Jenkins. […] Created CBFS image (capacity = 8387656 bytes) LINK cbfs/fallback/romstage_null.debug CC cbfs/fallback/coreboot_ram.debug coreboot-builds/asus_f2a85-m/generated/coreboot_ram.o:(.data+0x16b9c): undefined reference to `GnbIommuScratchMemoryRangeInterface' collect2: error: ld returned 1 exit status make: *** [coreboot-builds/asus_f2a85-m/cbfs/fallback/coreboot_ram.debug] Error 1 make: *** Waiting for unfinished jobs.... coreboot-builds/asus_f2a85-m/mainboard/asus/f2a85-m/buildOpts.romstage.o:(.data+0x3d8): undefined reference to `GnbIommuScratchMemoryRangeInterface' collect2: error: ld returned 1 exit status make: *** [coreboot-builds/asus_f2a85-m/cbfs/fallback/romstage_null.debug] Error 1 […] Therefore revert the commit to get the tree working again and submit this patch with its dependencies again. [1] http://review.coreboot.org/#/c/3317/ [2] http://qa.coreboot.org/job/coreboot-gerrit/6618/testReport/junit/(root)/board/i386_asus_f2a85_m/ Change-Id: I911755884da09eb0a0651b8db07ee2a32e6eaaaa Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3373 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-06-04Asus F2A85-M: Activate IOMMU supportRudolf Marek
Activate the IOMMU support for the Asus F2A85-M. Add the device to `devicetree.cb`. $ pci -s 0.2 […] 00:00.2 IOMMU: Advanced Micro Devices [AMD] Family 15h (Models 10h-1fh) I/O Memory Management Unit $ dmesg […] [ 0.000000] ACPI: IVRS 00000000bf144e10 00070 (v02 AMD AMDIOMMU 00000001 AMD 00000000) [ 0.000000] ACPI: SSDT 00000000bf144e80 0051F (v02 AMD ALIB 00000001 MSFT 04000000) [ 0.000000] ACPI: SSDT 00000000bf1453a0 006B2 (v01 AMD POWERNOW 00000001 AMD 00000001) [ 0.000000] ACPI: SSDT 00000000bf145a52 00045 (v02 CORE COREBOOT 0000002A CORE 0000002A) […] [ 0.465114] [Firmware Bug]: ACPI: no secondary bus range in _CRS […] [ 0.567330] pci 0000:00:00.0: >[1022:1410] type 00 class 0x060000 [ 0.567364] pci 0000:00:00.2: >[1022:1419] type 00 class 0x080600 [ 0.567427] pci 0000:00:01.0: >[1002:9993] type 00 class 0x03000 […] [ 0.597731] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 0.597899] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PIBR._PRT] [ 0.597933] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.SBR0._PRT] [ 0.597972] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.SBR1._PRT] [ 0.598073] pci0000:00: >Requesting ACPI _OSC control (0x1d) [ 0.603808] pci0000:00: >ACPI _OSC request failed (AE_NOT_FOUND), returned control mask: 0x1d [ 0.612397] ACPI _OSC control for PCIe not granted, disabling ASPM [ 0.620508] Freeing initrd memory: 14876k freed […] [ 0.882674] pci 0000:00:01.0: >Boot video device [ 0.882876] PCI: CLS 64 bytes, default 64 [ 0.897088] AMD-Vi: Enabling IOMMU at 0000:00:00.2 cap 0x40 extended features: PreF PPR GT IA [ 0.905816] pci 0000:00:00.2: >irq 40 for MSI/MSI-X [ 0.917457] AMD-Vi: Lazy IO/TLB flushing enabled [ 0.922076] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) [ 0.928500] software IO TLB [mem 0xbb13d000-0xbf13cfff] (64MB) mapped at [ffff8800bb13d000-ffff8800bf13cfff] [ 0.938535] LVT offset 0 assigned for vector 0x400 [ 0.943338] perf: AMD IBS detected (0x000000ff) [ 0.948037] audit: initializing netlink socket (disabled) [ 0.953432] type=2000 audit(1369659616.800:1): initialized [ 0.977011] HugeTLB registered 2 MB page size, pre-allocated 0 pages […] [ 7.881938] radeon 0000:00:01.0: >VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used) [ 7.881941] radeon 0000:00:01.0: >GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF […] [ 7.885516] radeon 0000:00:01.0: >irq 48 for MSI/MSI-X [ 7.885525] radeon 0000:00:01.0: >radeon: using MSI. […] [ 8.276775] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae000 flags=0x0010] [ 8.287363] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acc00 flags=0x0010] [ 8.297945] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae200 flags=0x0010] [ 8.308527] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae080 flags=0x0010] [ 8.319109] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae240 flags=0x0010] [ 8.329694] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001accc0 flags=0x0010] [ 8.340276] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ace80 flags=0x0010] [ 8.350858] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acd80 flags=0x0010] [ 8.361441] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae280 flags=0x0010] [ 8.372022] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae180 flags=0x0010] [ 8.382605] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ace00 flags=0x0010] [ 8.393188] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acdc0 flags=0x0010] [ 8.403770] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ace40 flags=0x0010] [ 8.414353] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae1c0 flags=0x0010] [ 8.424936] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acc40 flags=0x0010] [ 8.435518] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acc80 flags=0x0010] [ 8.446100] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae2c0 flags=0x0010] [ 8.456684] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae300 flags=0x0010] [ 8.467265] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae340 flags=0x0010] [ 8.477849] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae380 flags=0x0010] [ 8.488431] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae3c0 flags=0x0010] [ 8.499013] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae0c0 flags=0x0010] [ 8.509596] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acec0 flags=0x0010] [ 8.520179] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acd00 flags=0x0010] [ 8.530761] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad000 flags=0x0010] [ 8.541343] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae400 flags=0x0010] [ 8.551925] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae440 flags=0x0010] [ 8.562509] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acf00 flags=0x0010] [ 8.573090] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae480 flags=0x0010] [ 8.583675] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae100 flags=0x0010] [ 8.594257] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae4c0 flags=0x0010] […] [ 8.604840] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acf40 flags=0x0010] [ 8.615421] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acd40 flags=0x0010] [ 8.626004] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad140 flags=0x0010] [ 8.636587] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad040 flags=0x0010] [ 8.647169] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad080 flags=0x0010] [ 8.657751] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae500 flags=0x0010] [ 8.668335] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad100 flags=0x0010] [ 8.678917] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad0c0 flags=0x0010] [ 8.689499] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acf80 flags=0x0010] [ 8.700080] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001acfc0 flags=0x0010] [ 8.710664] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae140 flags=0x0010] [ 8.721246] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae040 flags=0x0010] [ 8.731828] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad180 flags=0x0010] [ 8.742412] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae540 flags=0x0010] [ 8.752995] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad280 flags=0x0010] [ 8.763577] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad340 flags=0x0010] [ 8.774160] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad200 flags=0x0010] [ 8.784741] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad300 flags=0x0010] [ 8.795324] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae5c0 flags=0x0010] [ 8.805906] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae640 flags=0x0010] [ 8.816490] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad2c0 flags=0x0010] [ 8.827072] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad1c0 flags=0x0010] [ 8.837655] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad240 flags=0x0010] [ 8.848238] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae580 flags=0x0010] [ 8.858819] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae600 flags=0x0010] [ 8.869402] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad3c0 flags=0x0010] [ 8.879985] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ad380 flags=0x0010] [ 8.890568] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae7c0 flags=0x0010] [ 8.901151] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae740 flags=0x0010] [ 8.911732] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae6c0 flags=0x0010] [ 8.922316] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae780 flags=0x0010] [ 8.932897] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae700 flags=0x0010] [ 8.943480] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:01.0 domain=0x0003 address=0x0000000f001ae680 flags=0x0010] [ 8.963011] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000). [ 8.963165] radeon 0000:00:01.0: >WB enabled […] It is not known, what the implications of the `IO_PAGE_FAULT` are. Change-Id: Ic5fde609322a5fdeb1a48052c403847197752a4b Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Reviewed-on: http://review.coreboot.org/3317 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-03Asus F2A85-M: Fix the _CRS PCI0 bus infoRudolf Marek
On Asus F2A85-M, the Linux kernel complains that the _CRS method does not specify the number of PCI busses. [FIRMWARE BUG]: ACPI: no secondary bus range in _CRS Just put there 256. This should be part of re-factoring of the whole ACPI stuff. The same change was already done for the AMD Brazos (SB800) boards, based on commit »Persimmon DSDT: Add secondary bus range to PCI0« (4733c647) [1]. [1] http://review.coreboot.org/2592 Change-Id: I06f90ec353df9198a20b2165741ea0fe94071266 Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Reviewed-on: http://review.coreboot.org/3320 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com> Reviewed-by: David Hubbard <david.c.hubbard+coreboot@gmail.com>
2013-05-31AMD Trinity boards: Add reserved memory area for SPI base address in ACPISteven Sherk
- SPI controller base address gets overwritten by SD controller under Linux. - Reason for overwrite is the SPI base address isn't in a standard BAR and doesn't get automatically reserved. Solution is to add it as a reserved memory area in ACPI. - This issue was found on the ASUS F2A85-M platform. Currently a workaround on this platform was made as part of: http://review.coreboot.org/#/c/3167/3 - Once approved a follow-on patch for other southbridges using a non-standard BAR for the spi controller. Change-Id: I1b67da3045729a6754e245141cd83c5b3cc9009e Signed-off-by: Steven Sherk <steven.sherk@se-eng.com> Reviewed-on: http://review.coreboot.org/3270 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-30AMD Trinity boards: Use `sizeof(var)` to get its sizeRudolf Marek
Change `sizeof(type) * n`, where n is the number of array elements, to `sizeof(variable)` to directly get the size of the variable (struct, array). Determining the size by counting array elements is error prone and unnecessary. Not sure why the copy is needed instead of direct reference. Maybe it has something to do with CAR? These changes are based on Rudolf’s original patch »ASUS F2A85-M: Correct and clean up PCIe config« [1], where it was just done for the ASUS board. [1] http://review.coreboot.org/#/c/3194/ Change-Id: I4aa4c6cde5a27b7f335a71afc21d1603f2ae814b Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3247 Tested-by: build bot (Jenkins) Reviewed-by: David Hubbard <david.c.hubbard+coreboot@gmail.com> Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
2013-05-20ASUS F2A85-M: romstage.c: Set RAM voltage for non 1.5 Volt casePaul Menzel
Currently the code in the if statement if (!byte) do_smbus_write_byte(0xb20, 0x15, 0x3, byte); only gets executed if `byte == 0x0`, that means only in the default case where RAM voltage is 1.5 Volts. But the RAM voltage should be changed when configured for the non-default case. So negate the predicate to alter the RAM voltage for the non-default cases. To prevent the build error OBJCOPY cbfs/fallback/coreboot_ram.elf coreboot-builds/asus_f2a85-m/generated/crt0.romstage.o: In function `cache_as_ram_main': /srv/jenkins/.jenkins/jobs/coreboot-gerrit/workspace/src/mainboard/asus/f2a85-m/romstage.c:106: undefined reference to `do_smbus_write_byte' collect2: error: ld returned 1 exit status make: *** [coreboot-builds/asus_f2a85-m/cbfs/fallback/romstage_null.debug] Error 1 add `southbridge/amd/agesa/hudson/smbus.c` providing the function `do_smbus_write_byte` to ROM stage in `Makefile.inc`. That can actually be used after the needed header files are included in a previous commit. Change-Id: I89542479c4cf6d412614bcf4586ea98e097328d6 Reported-by: David Hubbard <david.c.hubbard+coreboot@gmail.com> Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3200 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-05-14AMD Fam15tn boards: BiosCallOuts.c: Declare codec arrays as `static`Paul Menzel
These arrays are declared as `static` for AMD SB800 based boards, so do the same for this generation. Rudolf Marek just changed `const CODEC_TBL_LIST` to `static const` in [1]. Adapt all Fam15tn based boards (AMD Parmer, AMD Thatcher, ASUS F2A85-M) to keep the differences between them small. [1] http://review.coreboot.org/#/c/3170/3/src/mainboard/asus/f2a85-m/BiosCallOuts.c Change-Id: I353b38bd8bc77ba500a4b7fe9250e9aa3071c530 Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3198 Tested-by: build bot (Jenkins)
2013-05-14AMD Fam15tn boards: Document lane ID mapping from BKDGRudolf Marek
To make it easier to fill in the values, place the table from the BIOS and Kernel Developer’s Guide (BKDG) [1] as a comment. [1] http://www.coreboot.org/Datasheets#AMD_Fam15 Change-Id: I218f76e9fa2dc88d47af51ea6c062e315afb0000 Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3221 Tested-by: build bot (Jenkins)
2013-05-14AMD Brazos/Trinity boards: PlatformGnbPcie.c: Reserve correct amount of memoryPaul Menzel
In `PlatformGnbPcie.c` AGESA functions are used to reserve memory space to save the PCIe configuration to. This is the With the following definitions in `AGESA.h` $ more src/vendorcode/amd/agesa/f14/AGESA.h […] /// PCIe port descriptor typedef struct { IN UINT32 Flags; /**< Descriptor flags * @li @b Bit31 - last descriptor in complex */ IN PCIe_ENGINE_DATA EngineData; ///< Engine data IN PCIe_PORT_DATA Port; ///< PCIe port specific configuration info } PCIe_PORT_DESCRIPTOR; /// DDI descriptor typedef struct { IN UINT32 Flags; /**< Descriptor flags * @li @b Bit31 - last descriptor in complex */ IN PCIe_ENGINE_DATA EngineData; ///< Engine data IN PCIe_DDI_DATA Ddi; ///< DDI port specific configuration info } PCIe_DDI_DESCRIPTOR; /// PCIe Complex descriptor typedef struct { IN UINT32 Flags; /**< Descriptor flags * @li @b Bit31 - last descriptor in topology */ IN UINT32 SocketId; ///< Socket Id IN PCIe_PORT_DESCRIPTOR *PciePortList; ///< Pointer to array of PCIe port descriptors or NULL (Last element of array must be terminated with DESCRIPTOR_TERMINATE_LIST). IN PCIe_DDI_DESCRIPTOR *DdiLinkList; ///< Pointer to array DDI link descriptors (Last element of array must be terminated with DESCRIPTOR_TERMINATE_LIST). IN VOID *Reserved; ///< Reserved for future use } PCIe_COMPLEX_DESCRIPTOR; […] memory has to be reserved for the `PCIe_COMPLEX_DESCRIPTOR` and, as two struct members are pointers to arrays with elements of type `PCIe_PORT_DESCRIPTOR` and `PCIe_DDI_DESCRIPTOR`, space for these times the number of array elements have to be reserved: a + b * 5 + c * 2. sizeof(PCIe_COMPLEX_DESCRIPTOR) + sizeof(PCIe_PORT_DESCRIPTOR) * 5 + sizeof(PCIe_DDI_DESCRIPTOR) * 2; But for whatever reason parentheses were put in there making this calculation incorrect and reserving too much memory. (a + b * 5 + c) * 2 So, remove the parentheses to reserve the exact amount of memory needed. The ASRock E350M1 still boots with these changes. No changes were observed as expected. Rudolf Marek made this change as part of his patch »ASUS F2A85-M: Correct and clean up PCIe config« [1]. Factor this hunk out as it affects all AMD Brazos and Trinity based boards. [1] http://review.coreboot.org/#/c/3194/ Change-Id: I32e8c8a3dfc5e87eb119eb17719d612e57e0817a Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3239 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de> Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
2013-05-09AMD: Reduce stack size from 64 KB to the default of 4 KBPaul Menzel
Apply the following commit to all AMD boards. commit 935850e08293cec1cb27d12358b27285e780566a Author: Stefan Reinauer <reinauer@chromium.org> Date: Mon May 6 16:16:03 2013 -0700 asrock/e350m1: reduce default stack size The stack used on the ASRock E350M1 is significantly less than what we currently set (64k per core). In fact, we use about half of the default stack size (4k) on core 0 and even less on non BSP cores [1]: $ grep stack coreboot_without_patch_but_monotonic_timer.log CPU1: stack_base 002a0000, stack_end 002afff8 CPU1: stack: 002a0000 - 002b0000, lowest used address 002afda8, stack used: 600 bytes CPU0: stack: 002b0000 - 002c0000, lowest used address 002bf75c, stack used: 2212 bytes […] Reviewed-on: http://review.coreboot.org/3209 Please note that AGESA seems to define bigger stack sizes. But these seem to be too much too. $ git grep STACK_SIZE src/vendorcode/amd […] src/vendorcode/amd/agesa/f14/Proc/CPU/Family/0x14/cpuF14CacheDefaults.c:#define BSP_STACK_SIZE 16384 src/vendorcode/amd/agesa/f14/Proc/CPU/Family/0x14/cpuF14CacheDefaults.c:#define CORE0_STACK_SIZE 16384 src/vendorcode/amd/agesa/f14/Proc/CPU/Family/0x14/cpuF14CacheDefaults.c:#define CORE1_STACK_SIZE 4096 src/vendorcode/amd/agesa/f14/Proc/CPU/Family/0x14/cpuF14CacheDefaults.c: BSP_STACK_SIZE, src/vendorcode/amd/agesa/f14/Proc/CPU/Family/0x14/cpuF14CacheDefaults.c: CORE0_STACK_SIZE, src/vendorcode/amd/agesa/f14/Proc/CPU/Family/0x14/cpuF14CacheDefaults.c: CORE1_STACK_SIZE, […] The following command was used to create the patch. $ git grep -l STACK_SIZE src/mainboard/ | xargs sed -i '/STACK_SIZE/,+3d' Change-Id: I36b95b7a6f190b64d0639fc036ce2fb0253f3fa1 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3217 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-08copy_and_run: drop boot_complete parameterStefan Reinauer
Since this parameter is not used anymore, drop it from all calls to copy_and_run() Change-Id: Ifba25aff4b448c1511e26313fe35007335aa7f7a Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3213 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-04Asus F2A85-M Enable the SD controller for F2A85-MRudolf Marek
If the SD controller is "off" hudson.c won't disable that because, there is no code for this yet. The PCI device is still visible and PCI BAR will be allocated by Linux. Unfortunately it may happen that the particular address is used by non-standard BAR for SPI controller. Change-Id: Ied7c581727541e2c81b0b1c2b70fd32de0014730 Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Reviewed-on: http://review.coreboot.org/3167 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-03mainboard/{asus/f2a85-m,amd/thatcher}: move UDELAY_LAPICDavid Hubbard
Stefan Reinauer suggested 'select UDELAY_LAPIC' did not belong in f2a85-m/Kconfig. It got there via copy-paste from thatcher/Kconfig so this commit removes the 'select UDELAY_LAPIC' from both and puts it in cpu/amd/agesa/family15tn/Kconfig Since f2a85-m is the only Thatcher board coreboot supports right now, this should not break any other boards. Change-Id: I811b579c31f8d259a237d3a6724ad3b17f3a6c3e Signed-off-by: David Hubbard <david.c.hubbard+coreboot@gmail.com> Reviewed-on: http://review.coreboot.org/3178 Reviewed-by: Peter Stuge <peter@stuge.se> Tested-by: build bot (Jenkins)
2013-03-30AMD Hudson boards: Use `hudson.h` for `pm_ioread` and delete `pmio.h`Paul Menzel
Unfortunately, an unneeded mainboard specific `pmio.h` was created when merging the AMD Parmer and Thatcher ports. Rudolf used the header from a more generic location southbridge/amd/agesa/hudson/hudson.h doing the the ASUS F2A85-M port, but did not delete the `pmio.h` now unused `pmio.h` header file. So adapt AMD Parmer and Thatcher to use the Hudson one as done for the ASUS F2A85-M and delete the now unused mainboard specific header file `pmio.h` to avoid duplication. Change-Id: I961cd145ebc3b83e31c638ac453ac95ee19c18db Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2958 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-03-22Add support for ASUS F2A85-M boardRudolf Marek
The patch is based on Thatcher board. So far it boots Linux (3.2/3.7), internal network adapter works, AHCI works. External PCI/PCIe slots works too. Power management/ACPI seems to work. Internal VGA works with dumped ROM (VGA/DVI), but lacks GART. PCI pref devices are being relocated by Linux, reason unknown. This is a good start. USB and XHCI untested but visible. Change-Id: I1869aecb2634d548b00b3c9139517d6a0e0c9817 Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Reviewed-on: http://review.coreboot.org/2038 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-29 09:45:57 +0000