[coreboot] how to delete symbol link created at compile time

[She, Kerry]

> -----Original Message-----
> From: Marc Jones [mailto:marcj303 at gmail.com]
> Sent: Tuesday, October 18, 2011 10:39 AM
> To: Stefan Reinauer
> Cc: She, Kerry; coreboot
> Subject: Re: [coreboot] how to delete symbol link created at compile time
> 
> On Mon, Oct 17, 2011 at 4:44 PM, Stefan Reinauer
> <stefan.reinauer at coreboot.org> wrote:
> > * Marc Jones <marcj303 at gmail.com> [111016 10:10]:
> >> >> > I have created 2 devicetree file :
> >> >> >
> >> >> > devicetree_f15.cb for platform with family 15 CPU
> >> >> >
> >> >> > devicetree_f10.cb  for platform with family 10 CPU
> >> >> >
> >> >> >
> >> >> >
> >> >> > I changed the makefile to create a symbol link "devicetree.cb"
> link to
> >> >> > devicetree_f10.cb or devicetree_f15.cb at compile time.
> >> >> >
> >> >> > The problem is that I can't delete the symbol link when make
> >> >> > clean/distclean.
> >> >
> >> > Please fix the problem by using one device tree for both platforms.
> >
> >> Stefan,
> >>
> >> Can you explain your thoughts on how that would work? Can we put a #if
> >> in the devicetree.cb? It uses the c precompiler? It requires different
> >> CPU files/device locations.  We can try it next week.
> >
> > Usually the way this is handled in coreboot is that there is one socket
> > that binds together all CPU types. Then in the device tree only the
> > socket type is specified, and code for both CPUs is pulled in.
> > Maybe we need something like a socket for northbridge code, since the
> > northbridge now lives in the CPU?
> >
> > It seems like a bad idea to have to recompile your BIOS because you
> > change the CPU. We did a lot of nastyness with K8 and Fam10, but we
> > should find a better way to do this for future chipsets/CPUs.
> 
> 
> Yes, we are discussing how the AGESA code would work. The socket
> decision is rather complicated as we need a way to handle multiple
> calls with the same names (function point tables etc). I think that
> there may be a solution within AGESA, but the device tree may still be
> a problem as the CPUs have different HT link numbering. This makes it
> hard to have the same device tree layout for the same socket.

Because of the function name conflict, put cpu code of 2 families together would not compile.
We need to dig into AGESA more to figure out a solution.
As for the devicetree problem, following text is the devicetree difference in detail:

--- devicetree_fam10.cb	2011-08-15 15:00:14.426692437 +0800
+++ devicetree_fam15.cb	2011-08-15 15:00:14.426692437 +0800
@@ -16,19 +16,17 @@
 # along with this program; if not, write to the Free Software
 # Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 #
-chip northbridge/amd/agesa/family10/root_complex
+chip northbridge/amd/agesa/family15/root_complex
 	device lapic_cluster 0 on
-		chip cpu/amd/agesa/family10
-			device lapic 0x10 on end
+		chip cpu/amd/agesa/family15
+			device lapic 0x20 on end
 		end
 	end
 	device pci_domain 0 on
 		subsystemid 0x15d9 0xab11 inherit #SuperMicro
-		chip northbridge/amd/agesa/family10 # CPU side of HT root complex
-			device pci 18.0 on end # link 0
-			device pci 18.0 on end # link 1
-			device pci 18.0 on end # link 2
-			device pci 18.0 on     # link 3, SB on socket0 link 2, on internal Node0 Link 3
+		chip northbridge/amd/agesa/family15 # CPU side of HT root complex
+			device pci 18.0 on end # Link 0
+			device pci 18.0 on     # Link 1, IO-HUB on socket0 link 2(internal Node0 Link 1)
 				chip northbridge/amd/cimx/rd890 # Southbridge PCI side of HT Root complex
 					device pci 0.0 on  end # HT Root Complex 0x9600