Hello,
I've got a problem while maintaining transition of my working project from TI Linux SDK version 6 to version 7 (i. e. kernel and bootloader). There is a Cypress FRAM chip (FM25, compatible with AT25 EEPROM) attached to SPI1 hardware interface, which fails to work with the following device tree node:
spi1: spi@481a0000 {
pinctrl-names = "default";
pinctrl-0 = <&spi1_pins>;
status = "okay";
fram@0 {
reg = <0x0>;
compatible = "atmel,at25", "cypress,fm25l16b";
spi-max-frequency = <20000000>;
pagesize = <256>;
size = <2048>;
address-width = <16>;
};
};
The corresponding piece of initialization code from my machine board file that worked for me in SDK 6 is:
static struct spi_eeprom fram = {
.byte_len = SZ_16K / 8,
.name = "fm25l16b",
.page_size = 256,
.flags = EE_ADDR2,
};
static struct spi_board_info am335x_spi1_slave_info[] = {
{
.modalias = "at25",
.platform_data = &fram,
.max_speed_hz = 20 * 1000 * 1000,
.bus_num = 2,
.chip_select = 0,
.mode = SPI_MODE_0,
},
};
static void spi1_init(void)
{
setup_pin_mux(spi1_pin_mux);
spi_register_board_info(am335x_spi1_slave_info, ARRAY_SIZE(am335x_spi1_slave_info));
return;
}
On SDK 6 based system, there was a "block" file available at path /sys/bus/spi/devices/spi2.0/eeprom, which could be used to access FRAM from userspace. On SDK 7 system with my device tree, there is a path /sys/bus/spi/devices/spi1.0, but there is no "eeprom" or similar "block" file.
Moreover, when I attempt to bind spi1.0 device to at25 driver by running the following command:
echo -n 'spi1.0' >/sys/bus/spi/drivers/at25/bind
I'm getting "write error: No such device" message. By the way, running
cat /sys/bus/spi/devices/spi1.0/modalias
gives me "spi:at25" instead of just "at25", which was returned by the corresponding "spi2.0" device in SDK 6.
I believe my problem is somehow related to the fact that MODULE_ALIAS("spi:at25") macro used in at25 module source code indirectly invokes __MODULE_INFO(...), which in turn expands to an useless unique struct definition, if the kernel module is configured as builtin (i. e. MODULE not defined, see include/linux/moduleparam.h).
A logical solution for this problem would be configuring this module as loadable, so that the information passed to MODULE_ALIAS(...) would actually be obtainable for the kernel. However, this isn't much of an option for my particular project due to a complex feature set (e. g. limited availability of root filesystem), so a monolithic kernel with all the necessary drivers built in would be much more preferable.
This way I'd like to ask whether someone might know an alternative solution which doesn't involve loadable modules or any major kernel patching, in some form or other.
Sincerely in advance,
Ilyas
