Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 8 Oct 2009 16:18:55 +0200
From:      Guillaume Ballet <gballet@gmail.com>
To:        freebsd-arm@freebsd.org
Subject:   Adding members to struct cpu_functions
Message-ID:  <fd183dc60910080718v73c66089w3341d8bfe0f14006@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
Hello list,

I am continuing my effort to port FreeBSD to the BeagleBoard. I
reached the point where the system prompts for the root filesystem. I
am therefore cleaning up my code and will then post it to this list
for comments. I still have a few hacky fixups to remove before it
becomes readable :)

I know that Mark Tinguely, whose help has been precious in this
endeavor, has some patches ready for ARMv6 cache management, so I did
not focus on this.

At the moment, I am using backward-compatibility for the TLB format. I
want to start using the ARMv6 TLB format. My current problem is that
most of the arch-dependent code uses macros that are defined to match
the pre-ARMv6 TLB format. There are several ways of fixing this,
including defining these macros depending on some symbol such as
_ARM_ARCH_* or CPU_ARM*. I am however no friend of heavy preprocessor
flagging. What if instead, cpu_functions was extended to include
fields like the prototype for TLB entries of each size? For example,
take this patch to the following excerpt from pmap_map_chunk in
sys/arm/arm/pmap.c:

  /* See if we can use a L2 large page mapping. */
  if (L2_L_MAPPABLE_P(va, pa, resid)) {
  #ifdef VERBOSE_INIT_ARM
          printf("L");
  #endif
          for (i = 0; i < 16; i++) {
                  pte[l2pte_index(va) + i] =
-                     L2_L_PROTO | pa |
+                    cpufuncs.cf_l2_l_proto | pa |
-                     L2_L_PROT(PTE_KERNEL, prot) | f2l;
+                    cpufuncs.l2_l_prot(PTE_KERNEL, prot) | f2l;
                      PTE_SYNC(&pte[l2pte_index(va) + i]);
          }
          va += L2_L_SIZE;
          pa += L2_L_SIZE;
          resid -= L2_L_SIZE;
          continue;
  }

Would that be acceptable?

Now, assuming people agree with this change, that would only be a
first step because all values for cpufuncs are defined in the same
file (cpufunc.c), which is guarded with as many CPU_ARMx defines as
there are cpu flavors. Is there a specific reason for all these
structures to be defined in a same file, instead of defining it in a
platform- or cpu-specific file and using the files.* to select the
appropriate cpufunc flavor in the build system?

Guillaume



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fd183dc60910080718v73c66089w3341d8bfe0f14006>