ppc kernel environment question

yellowdog-general@lists.terrasoftsolutions.com yellowdog-general@lists.terrasoftsolutions.com
Thu Dec 4 16:16:02 2003


Resolved and thanks!  It is modversions.h file misplacement.

> -----Original Message-----
> From: yiding_wang@agilent.com [mailto:yiding_wang@agilent.com]
> Sent: Wednesday, December 03, 2003 6:07 PM
> To: yellowdog-general@lists.terrasoftsolutions.com
> Subject: ppc kernel environment question
>=20
>=20
> I am having bunch of "unresolved symbol" problem during the=20
> driver module loading and have not figured out what is the=20
> cause yet. =20
>=20
> The driver is compiled fine under ppc with YDL kernel=20
> 2.4.23-0.5.0b.  The driver is built with Rules.make under=20
> kernel source, and it is the same Rules.make the boot kernel=20
> is using.=20
>=20
> I did same procedure as I normally do under x86.  First boot=20
> system with new kernel.  Then compiled driver with same boot=20
> kernel environment, meaning referencing all header files and=20
> other kernel sources under same kernel source directory. =20
> Under x86 environment, after driver is compiled, I will be=20
> able to load driver module without any problem.  However,=20
> under ppc, it gave me many kernel related function symbols=20
> unresolved like following:
>=20
> unresolved symbol ioremap
> unresolved symbol strchr
> unresolved symbol __up
> unresolved symbol free_irq
> unresolved symbol pci_read_config_dword
> ... ...
> and it goes on.
>=20
> I checked kernel as well as System.map file, all mentioned=20
> system calls are there.  I also checked Rules.make and=20
> Makefile under /linux kernel source tree and compared with my=20
> x86 2.4.20-8 files but did not see any issue there. =20
> Initially I thought it is a driver build environment mismatch=20
> with boot kernel.  Apparently this is not the case since the=20
> system is boot from new built kernel with the same source I=20
> am using for building the driver.
>=20
> It is still looks to me a problem of driver loading in the=20
> kernel where those system calls are missing but I don't know=20
> why, specially I am using same procedure as I do under x86.
>=20
> Many thanks for any suggestion!
>=20
> Eddie
> _______________________________________________
> yellowdog-general mailing list
> yellowdog-general@lists.terrasoftsolutions.com
> http://lists.terrasoftsolutions.com/mailman/listinfo/yellowdog-general
>=20