Proposed Zynq Platform Build Script Improvements for Kernel Modules

Description

Right now, a default uramdisk.image.gz is copied, patched, and exported during the zed platform's processing for building an SD card image. The filesystem contained within this gzipped ramdisk contains prebuilt kernel modules. To further ensure continuity between the kernel modules in the ramdisk and the kernel built by the SD card image build scripts, it would be better to add a line in the build scripts for building the kernel modules (something like make modules ARCH=arm OCPI_CROSS...), delete the existing kernel modules on the ramdisk, and copy the newly built kernel modules onto the ramdisk.

This will also help "genericize" the build process for future platforms building for zynq which may be built from a different linux-xlnx git tag.

Environment

None

Activity

Show:
James Kulp
April 12, 2017, 11:26 AM

Currently we rely on the consistency between the Xilinx binary release and the same-tagged point in the Xilinx github repo. Did you have evidence that these were out of sync, or a different use case?

Davis Hoover
April 17, 2017, 2:38 PM

I can't remember if there was a particular problem which warranted this suggestion. However, it makes for a more stable and robust build process when one ensures that all libraries/binaries/modules in a filesystem are compiled against the kernel headers for the intended kernel version. If I remember correctly, the ram disk zip file I was referring to was the one committed in platforms/zed/, which I have no way of knowing where that came from (or what kernel version it corresponds to).

James Kulp
April 17, 2017, 2:59 PM

I think it is a bit scary either way....
So you are proposing that we copy the modules from our kernel build (which we must do), on top of the ones in the Xilinx binary release, just like we do with the kernel itself, to ensure that they are in sync.
This would ensure two things: the build tools are in sync, and the kernel configuration options we use to build the kernel were used to create the dynamic modules. I don't have our own build handy, but:
these are the modules I found in the xilinx binary release:
./uramdisk/root/lib/modules/3.12.0-xilinx/kernel/crypto/ansi_cprng.ko
./uramdisk/root/lib/modules/3.12.0-xilinx/kernel/crypto/krng.ko
./uramdisk/root/lib/modules/3.12.0-xilinx/kernel/crypto/rng.ko
./uramdisk/root/lib/modules/3.12.0-xilinx/kernel/drivers/remoteproc/mb_remoteproc.ko
./uramdisk/root/lib/modules/3.12.0-xilinx/kernel/drivers/remoteproc/remoteproc.ko
./uramdisk/root/lib/modules/3.12.0-xilinx/kernel/drivers/remoteproc/zynq_remoteproc.ko
./uramdisk/root/lib/modules/3.12.0-xilinx/kernel/drivers/rpmsg/virtio_rpmsg_bus.ko
./uramdisk/root/lib/modules/3.12.0-xilinx/kernel/drivers/usb/gadget/g_zero.ko
./uramdisk/root/lib/modules/3.12.0-xilinx/kernel/drivers/usb/gadget/libcomposite.ko
./uramdisk/root/lib/modules/3.12.0-xilinx/kernel/drivers/usb/gadget/usb_f_ss_lb.ko
./uramdisk/root/lib/modules/3.12.0-xilinx/kernel/drivers/virtio/virtio.ko
./uramdisk/root/lib/modules/3.12.0-xilinx/kernel/drivers/virtio/virtio_ring.ko
./uramdisk/root/lib/modules/3.12.0-xilinx/kernel/fs/configfs/configfs.ko
./uramdisk/root/lib/modules/3.12.0-xilinx/kernel/net/8021q/8021q.ko
./uramdisk/root/lib/modules/3.12.0-xilinx/kernel/net/ipv4/ip_tunnel.ko
./uramdisk/root/lib/modules/3.12.0-xilinx/kernel/net/ipv4/ipip.ko
./uramdisk/root/lib/modules/3.12.0-xilinx/kernel/net/ipv4/tunnel4.ko
./uramdisk/root/lib/modules/3.12.0-xilinx/kernel/net/ipv6/ipv6.ko
./uramdisk/root/lib/modules/3.12.0-xilinx/kernel/net/ipv6/sit.ko
./uramdisk/root/lib/modules/3.12.0-xilinx/kernel/net/ipv6/xfrm6_mode_beet.ko
./uramdisk/root/lib/modules/3.12.0-xilinx/kernel/net/ipv6/xfrm6_mode_transport.ko
./uramdisk/root/lib/modules/3.12.0-xilinx/kernel/net/ipv6/xfrm6_mode_tunnel.ko
./uramdisk/root/lib/modules/3.12.0-xilinx/kernel/net/rpmsg/rpmsg_proto.ko

James Kulp
April 17, 2017, 7:17 PM

I actually figured out how to build all the modules in the linux tree and compare them to what is in the associated Xilinx binary distribution with the same release tag. They are all different.....
It would be nice to get some idea as to why they are all different. That will take more digging.

Assignee

Unassigned

Reporter

Davis Hoover

Labels

None

Components

Priority

Minor
Configure