sakaki- / gentoo-on-rpi-64bit

Bootable 64-bit Gentoo image for the Raspberry Pi4B, 3B & 3B+, with Linux 5.4, OpenRC, Xfce4, VC4/V3D, camera and h/w codec support, weekly-autobuild binhost
GNU General Public License v3.0
921 stars 126 forks source link

ARM errata workarounds via the alternatives framework #104

Closed Avamander closed 1 year ago

Avamander commented 5 years ago

After following the "Build your own kernel" guide and entering menuconfig, I noticed that a lot of workarounds under ARM errata workarounds via the alternatives framework are enabled, even though the chipset is only Cortex-A53, is this intentional? If not, are the workarounds applied on the binary kernel? If yes, maybe they could be disabled?

(Also, is there something I have to do to let Gentoo know there's my own kernel configuration and that it should use that? It often complains about being unable to detect some kernel configuration option's status. I'm rebuilding in general just to enable a few things systemd needs as I want to try it out on Gentoo)

jfikar commented 5 years ago

For the second question I think Gentoo looks into /usr/src/linux. This should be a symlink to your kernel directory.

Avamander commented 5 years ago

The kernel I compiled where I disabled all the workarounds except the Cortex-A53 ones works nicely, will continue using it to see how stable it is, but I do suspect they're mistakenly enabled by default bcm config.

sakaki- commented 5 years ago

That's correct about /usr/src/linux.

The binary kernel's configuration is based on bcmrpi3_defconfig on the RPi3 B/B+ and bcm2711_defconfig for the RPi4 B (autobuilds here and here). Those configs come from upstream.

As such, why not post an issue about this to raspberrypi/linux to see their response on this point.?

Best, sakaki

necrose99 commented 4 years ago

I have rockpro64 , and rpi3 , looking to get rpi4 also and pinebook pro... anyrate , rp64 i got and 4 month latter after i got it pi4 droped..

however for common want of kernel, i make all modules , make all yes. , slam aufs5 built iin via standalone and zfs > ,

I prune sys-fs from config. , sys-fs-tools ok , but next general setup dep...sys-fs-v2 i sed out or make menu config. gentoo-sources pentoo-sources , with panfrost/mali dashed in zfs /aufs5 ie make mennu after can pick opts on , while having 99% of what i'd do w/o 3-4 hours y n module uggh. having to comb for a few patches , as bluetooth drivers are simular but not on same ic2 etc bus .

(config.bad /config.good cat my.config make oldconfig , or another way of taking shards merging. ie conf.1 2. 3. etc some distros merger many to one .config. ) -- while very program-tic i feal a need of aspirin.. already.

mono kernel, not the greatest fan but one kernel too( boot arm64 server/pi sbc's etc..) Rule them all. other than uboot per device. , efi , grub i have precompiled zfs uboot efi yep.

VC4+Panfrost+MaLI= same fram buffer x-11 , fbtubrb , just mesa needs to pplay nicer. if i had wild hairs nuevo for an older geforce but i'd rather use m.2 and pool packages distfiles etc on rockpro64

I have grub built ,

next relaese of RPI4/3

/boot/efi , leaders overlay etc... rpi4-boot.me , rock64.bootme etc.. ./efi/gentoo/grub-aarch64.efi if i need to swap to other system cool. renam foo.bak , rename. to which board going to run. rock64./pro can burn uboot to onboard rom after getting Linux up. mirnor irritation of using manjaro image , then vacating it. (keeping loader/s/uboot parts) , <<< gentoo stage4 tarball , fix boot. etc. chroot add/remove pkgs , recompile wala.

/boot/ , kernel/s like Debian

getting rpi4/3 rock64/pro /pinebook device trrees in raw and atf is a minor pain...

more recent uboot suposedly can work on gpt cards , a nicety if rpi did for sure.

sakaki- commented 3 years ago

30 Oct 2020: sadly, due legal obligations arising from a recent change in my 'real world' job, I must announce I am standing down as maintainer of this project with immediate effect. For the meantime, I will leave the repo up (for historical interest, and since the images may be of use still in certain applications); however, there will be no further updates to the underlying binhost etc., nor will I be accepting / actioning further pull requests or bug reports from this point. Email requests for support will also have to be politely declined, so, please treat this as an effective EOL notice.

For further details, please see my post here.

Many thanks for your interest in this project!

With sincere apologies, sakaki ><