1. Home
  2. Field-Programmable Gate Arrays
  3. Compiling Linux Kernel for ML405

Compiling Linux Kernel for ML405

Dear all,

I'm trying to build a straightforward Linux Kernel for the Xilinx ML405 board and I'm running into one small problem. The build gets most of the way through and fails at link stage, missing a crucial function. The function in question is part of the Xilinx OCP BSP in the file xpacket_fifo_v2_00_a.c Tracing make, as best I can, this file never gets built. The only code that uses the function is in a driver and hence only "meets up" with the functions at final link time, which is where the problem arises.

Now, I'm certainly not a make guru, so I don't really understand how make calculates the dependencies during make dep (all these .depend files) and I'm not sure how make then uses these to build the required output files. How do I coax make into building the missing file(s)? Does anyone have any experience building kernels for the ML405?

I'm building a PPC development 2.4 downloaded using bitkeeper. I'm (mostly) following the instructions here:

formatting link
which are for the ML403, but close enough.

Any help - however small - would be great.

TIA,

-- Peter

Reply to
Peter Mendham
Loading thread data ...

Reply to
funkrhythm

Thanks for your reply, I tried what you said, I changed the lines: #include "xpacket_fifo_v1_00_b.h" EXPORT_SYMBOL(XPacketFifoV100b_Initialize); EXPORT_SYMBOL(XPacketFifoV100b_Read); EXPORT_SYMBOL(XPacketFifoV100b_SelfTest); EXPORT_SYMBOL(XPacketFifoV100b_Write); To read: #include "xpacket_fifo_v2_00_a.h" EXPORT_SYMBOL(XPacketFifoV200a_Initialize); EXPORT_SYMBOL(XPacketFifoV200a_Read); EXPORT_SYMBOL(XPacketFifoV200a_SelfTest); EXPORT_SYMBOL(XPacketFifoV200a_Write); I then did a make distclean, re-configured, did make dep then make bzImage. I got exactly the same errors: undefined references to the XPacketFifoV200a_* functions. I understand your fix, I just don't understand why it hasn't worked. Maybe I've done something wrong? If I look in arc/ppc/platforms/xilinx_ocp after the attempted build, there is a xpacket_fifo_v1_00_b.o but not a xpacket_fifo_v2_00_a.o, there is also a .xpacket_fifo_v1_00_b.o.flags but no equivalent v2 file. Any ideas?

Thanks,

-- Peter

Reply to
Peter Mendham

not sure why, but it sounds like the Makefile in the arch/ppc/platforms/xilinx_ocp directory didn't get regenerated after you modified xilinx_syms.c

you could try making the modification to a virgin copy of the source tree before running make menuconfig, make dep, etc... the Makefile should look something like this:

---------------------

# Makefile for the Xilinx On Chip Peripheral support code #

list-multi := xilinx_ocp.o

# Linux file to EXPORT_SYMBOL all of the Xilinx entries. export-objs += xilinx_syms.o xilinx_ocp-objs += xilinx_syms.o

# The Xilinx OS independent code. xilinx_ocp-objs += xbasic_types.o xdma_channel.o xdma_channel_sg.o \ xdmav3.o xdmav3_intr.o xdmav3_selftest.o xdmav3_sg.o \ xipif_v1_23_b.o xpacket_fifo_v2_00_a.o \ xpacket_fifo_l_v2_00_a.o xversion.o

obj-$(CONFIG_XILINX_OCP) := xilinx_ocp.o

xilinx_ocp.o: $(xilinx_ocp-objs) $(LD) -r -o $@ $(xilinx_ocp-objs)

include $(TOPDIR)/Rules.make

Peter Mendham wrote:

Reply to
funkrhythm

Hi,

Sorry for the delay in replying, I'm juggling a couple of projects and had to leave this for a few days. Thank you for your excellent advice, I now have a booting kernel -- thanks!

Hmmm, I don't understand either but the Makefile was clearly at fault. The Makefile seems to be part of the source tree. A modified makefile should maybe be part of the BSP(?) but it isn't.

I actually did a make distclean then modified the makefile by hand. make dep did not seem to touch the makefile, I gues it uses it(?) I only had one slight issue with the Makefile, I don't have any of the xdmav* targets, should I?

I confess that I had one more issue when building, it appears that the functions XIic_Recv and XIic_Send (from drivers/i2c/xilinx_iic/xiic_l.c) now have one more parameter. I had to modify the calls in arch/ppc/boot/simple/embed_config.c to include this extra parameter which I specified as XIIC_STOP (instructs the I2C driver to release the bus after the transaction). Not sure if this is right (I know nothing about I2C) but it seems to work... ;)

Thanks again, and I hope this post is of some use to others out there attempting the same thing,

-- Peter

Reply to
Peter Mendham

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.