madscientist42

  • Posts

    2
  • Joined

  • Last visited

Reputation Activity

  1. Like
    madscientist42 got a reaction from aaditya in Kernel 5.x.x and rk3399   
    Multi-arch doesn't compensate for board differences...it's for things like 32 and 64-bitness being on the host system at the same time.

    As for becoming inoperable on some other SoC...  A kernel built for SoC <X> may not have drivers, configuration, etc. built for SoC <Y>....to the point of being inoperable.  You shouldn't be trying to boot random kernels on random chips.  The only reason why X86 doesn't "work" that way is because there's a LOT of plug and play.  A tuned kernel for a given system setup there, though, CAN be inoperable on another board/system as well.  The fact that it's "tuned" is your first hint there.  A detuned setup like what Rasbian ships right now boots on every Pi because they chose to build for Original/PiZeros and limited everything to as much overlapped as possible.  In other words, they picked 32-bits ARMv6 architecture which is doable on all the chips with a moderate to major performance hit as you go up through the generations of boards.  They will all boot Raspbian, period.

    The same can't be said of the Yocto derived distribution I am making after hours or for the one I'm making for Motorola Solutions, Inc. during the day.  WHEN I build for a Pi, and I do for varying reasons, I'm specific.  The build for a Pi2 won't boot for a PiZero, because it's tuned for a Pi2, which is to say it's a Quad Cortex-A7 system with a slightly different peripheral layout on the SoC than the Zero has.  The same can be said about a Pi3 or a Pi4 in either 32 or 64-bit mode, with the 64-bit modes increasing performance by up to 40% over the 32-bit ones.  Because I am pulling out more performance out of the build and SoC, the thing won't boot properly or at all on the other Pis.  The SAME can be said for any of the other SoC's you care to mention in the ARM or even X86 spaces.  The more optimized the kernel is for the specific hardware, the less likely it will boot elsewhere within the CPU architecture that the SoC belongs in.

    I don't see the patches themselves doing that sort of thing.  But they won't work the same on a non-big/LITTLE core system either.  This is one of those things that lets the OS do the right things when you have hotter or weaker clusters in a given Coreplex.