An Intel Keem Bay Driver Is Posted To Avoid The SoC Suffering Inadvertent Reboots

[phoronix]

Phoronix: An Intel Keem Bay Driver Is Posted To Avoid The SoC Suffering Inadvertent Reboots

As I wrote about just over a month ago, Intel open-source developers have begun their bring-up of the Keem Bay SoC. Out today is a new Keem Bay driver to avoid a situation where inadvertent reboots could happen without this driver...

http://www.phoronix.com/scan.php?page=news_item&px=Intel-Keem-Bay-IMR-Reboot

[uid313]

What is inference computing use-cases at the edge?

[tildearrow]

Is it "Movidius" or "Movidus"?

[kylew77]

Why do all these blank trails processors have such problems on Linux? Bay trails had problems and now keem trails.

[starshipeleven]

Hey hey hey. You mention u-boot in the article but there is nothing stating that in the patch, (he talks only of SoC bootloader). Is this written somewhere else?

Why do all these blank trails processors have such problems on Linux? Bay trails had problems and now keem trails.

They don't. This is just a kernel feature that must be enabled to support new hardware that isn't even out yet. It's not a quirk or a workaround for trash hardware like Bay or Cherry Trail.
On this SoC some memory is reserved for other stuff, and Linux needs to know this and not touch it, that's it.

Micheael just gave it a more clickbaity title.

[kylew77]

Thanks starshipeleven. Bay trails is trash hardware that I bought hook line and sinker because it was cheap and got exactly what I paid for. Debuging that hardware was a nightmare.

[mlau]

Hey hey hey. You mention u-boot in the article but there is nothing stating that in the patch, (he talks only of SoC bootloader). Is this written somewhere else?

They don't. This is just a kernel feature that must be enabled to support new hardware that isn't even out yet. It's not a quirk or a workaround for trash hardware like Bay or Cherry Trail.

To me it sounds like they already shipped devkits to developers with a broken bootloader (that leaves this feature enabled), and since it's impossible to get that updated (in the sense that the broken one is completely eliminated in the field everywhere)
they instead opted to fix this with a minimal kernel "driver".

[starshipeleven]

To me it sounds like they already shipped devkits to developers with a broken bootloader (that leaves this feature enabled),

Even if that was true, this is a hardware feature that you might want to enable and use, and if you want to enable and use it, Linux must be able to deal with it.

Maybe I wasn't clear enough: this is not cheap crap hardware for Windows tablets, it's hardware for embedded AI usecases, and competing with NVIDIA's Jetsons and Xavier whatnot https://venturebeat.com/2019/11/12/i...n-at-the-edge/

It's going to be murderously expensive (if compared to the Cherry/Bay crap), and you are 99.9999% likely to be running Linux on it.

I really don't think it makes sense for them to say "you can't use this feature on the OS you are 99% likely to use on this platform because we didn't want to upset someone in Phoronix forums".

[woife]

Hey hey hey. You mention u-boot in the article but there is nothing stating that in the patch, (he talks only of SoC bootloader). Is this written somewhere else?

It is not mentioned in the cover letter, but it is in the patch, see https://lore.kernel.org/lkml/[email protected]/

The patch also contains the following print:

pr_info("Disabling Keem Bay U-boot IMR: %u\n", imr);

[woife]

Btw: can anyone point me to a description of what an "Isolated Memory Range" actually is?
I tried to look it up, but could not find anything useful. Is it an Intel-specific term for some of their SoC features?