On Fri, 25 Apr 2025 at 22:24:43 +0200, Mark Kettenis wrote:
> > Date: Fri, 25 Apr 2025 19:28:05 +0000
> > From: Miod Vallat <[email protected]>
> >
> > > My RK3128 came up with no ci_flush_bp assigned, because cpu0 never
> > > attached, because the reg values in the DTB were 0x000-0x003 rather
> > > than 0xf00-0xf03. This caused a "Fatal kernel mode prefetch abort"
> > > because it was trying to execute a null function pointer.
> > >
> > > It took me a while to figure out all of this so maybe we can panic
> > > instead of trying to execute a null function pointer to make it
> > > easier for the next person?
> >
> > Why not simply skip that call if ci_flush_bp is NULL?
>
> If ci_flush_bp is NULL, we didn't go through cpu_attach() for the
> primary CPU. If that happens I think there are more things that'll go
> wrong.
diff --git sys/arch/armv7/armv7/autoconf.c sys/arch/armv7/armv7/autoconf.c
index ba12c2f58e1..2332c3a199e 100644
--- sys/arch/armv7/armv7/autoconf.c
+++ sys/arch/armv7/armv7/autoconf.c
@@ -72,6 +72,9 @@ device_register(struct device *dev, void *aux)
void
cpu_configure(void)
{
+ struct device *dv;
+ int cpufound = 0;
+
splhigh();
softintr_init();
@@ -85,6 +88,16 @@ cpu_configure(void)
config_rootfound("mainbus", NULL);
+ TAILQ_FOREACH(dv, &alldevs, dv_list) {
+ if (strcmp(dv->dv_cfdata->cf_driver->cd_name, "cpu") == 0) {
+ cpufound = 1;
+ break;
+ }
+ }
+
+ if (!cpufound)
+ panic("no cpu0 device attached");
+
/*
* We can not know which is our root disk, defer
* until we can checksum blocks to figure it out.
