[coreboot] Re: KGPE-D16 maintainership
On Wed, 2 Oct 2019 00:58:43 +0200 Kinky Nekoboi wrote: > I finally have found the problem: > > This BUG appears when you only have memory in the Orange Slots > > yikes this boathert me for such a long time > > any idea how i could debug this further ? > > Am 18.09.19 um 14:22 schrieb Kinky Nekoboi: > > > > Highly appreciating that afford. > > > > Would like to mention Problems with Current Linux kernel with this > > Board. > > > > ( The SLUB Allocator is causing panics at boot for my builds) > > > > Pls see: > > > > https://www.mail-archive.com/coreboot@coreboot.org/msg53915.html Not sure if that helps at all, but I'm getting reports that CONFIG_SLAB=y CONFIG_SLAB_MERGE_DEFAULT=y CONFIG_SLAB_FREELIST_RANDOM=y instead of CONFIG_SLUB=y CONFIG_SLUB_CPU_PARTIAL=y "fixes" the issues. > >> Hi all, > >> we see a lot of attention around KGPE-D16 maintainership problems. > >> After discussion with Thierry Laurion (Insurgo) at OSFC2019 3mdeb > >> decided to help in maintaining that platform by organizing crowd > >> founding campaign or getting founds in other ways (direct > >> sponsors). > >> > >> Since we are based in Poland there is chance that even with small > >> contribution from community we would be able to cover the costs. > >> > >> Ideal plan would be to have structure similar to what we maintain > >> for PC Engines: > >> https://pcengines.github.io/ > >> Where we providing signed and reproducible binaries every month and > >> keep as close to mainline as possible. Of course if development > >> will be active, then there always would be delta of patches held > >> in review. > >> > >> Unfortunately we don't have hardware. During OSFC 2019 Stefan left > >> one board, but it was too late (and probably too expensive) for us > >> to organize any shipment to Poland. We looking to have 2 > >> mainboards one for development and one in our automated regression > >> testing environment. Of course we will start even with just one. > >> > >> If anyone is willing to help in founding, sponsoring hardware or by > >> code development and testing we would be very grateful. > >> > >> Please copy other people and share this post wherever is necessary > >> to keep this platform alive. Positive feedback will help things > >> rolling. > >> > >> Best Regards, > > > ___ > 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 -- Best regards/Mit freundlichen Grüßen/Cordialement/Met vriendelijke groet The Vikings Team Thomas Umbach Web: https://www.vikings.net/ Store: https://store.vikings.net/ Phone: +49 69 247 54 91 0 Fax: +49 69 247 50 339 Follow us on Mastodon: https://social.vikings.net/@vikings Follow us on Twitter: https://twitter.com/vikingslibre Vikings GmbH Sauerackerweg 14, 60529 Frankfurt/Main, Germany Register Court: AG Frankfurt am Main Register No.: HR B 84497, CEO: Thomas Umbach Tax Office: Frankfurt am Main, VATIN: DE254094338 GPG key fingerprint: FD5E 2543 EE62 7395 00A6 9FBB F228 7A48 7CA2 3FA5 pgpOZBF6cQGAr.pgp Description: OpenPGP digital signature ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: [PATCH] x86_64 support needs testing
On 2019-10-01 07:32 PM, Aaron Durbin via coreboot wrote: On Tue, Oct 1, 2019 at 10:29 AM Raul Rangel wrote: Yeah, we can place the stack at the bottom of a page so if it overflows we get a page fault. I'm assuming that will work in SMM? Paging works in SMM, yes. However, paging works on 32-bit as well where one could achieve the same thing. Minimum 4KiB stack granularity is necessary as well as ensuring physical and virtual address spaces are split up to allow guard pages. Currently everything is assumed 1:1. Currently neither 4KiB page, non identity mapping or a page fault handler is present. It would also require runtime modification of page tables, as the position of TSEG/A-Seg and the stack isn't known at build time, which only works if those reside in RAM. The current approach places page tables in RO CBFS to make sure it can't be modified from ring 0, which is sufficient for basic x86_64 support. Of course those can be added once the basic support has landed and is stable. On Tue, Oct 1, 2019 at 10:27 AM Aaron Durbin wrote: On Tue, Oct 1, 2019 at 9:42 AM Raul Rangel wrote: That's exciting. That means we can finally catch stack overflows in SMM. Because of paging? On Sun, Sep 29, 2019 at 5:42 AM Patrick Rudolph wrote: Dear coreboot community, Please test and review the patch series [1]. It adds support for x86 long mode on qemu and allows to build test most of coreboot's common code using the x86_64 toolchain. It serves as reference implementation to migrate real hardware to long mode. Here some technical details, that can also be found in the Documentation/ folder: A new tool called pgtblgen create static page tables for a known physical memory address. The page tables are placed in CBFS at the given address. Due to the fixed and known address, they can easily be loaded in assembly code. It only works on platforms that memory map the SPI flash, which are almost all modern x86 platforms. The advantage of page tables in ROM are: * No runtime (assembly) code to generate page tables * No need to find a (4K aligned) place in heap to store them * Improved security for SMM, as page tables are always immutable The page tables are loaded in bootblock and SMM and persist until control is handed over to the payload. For the Proof-of-Concept only 4GiB are identity mapped, thus no stage can't access memory over 4GiB. That's not a problem for now as no coreboot code make use of memory above 4GiB yet. I haven't done further tests on long mode. It will be interesting to see if there are improvements on boot speed, code size or faster firmware decompression speeds. Regards, Patrick 1: https://review.coreboot.org/q/topic:%22x86_64_support2%22+(status:open%20OR%20status:merged) ___ 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 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
