LINUX.ORG.RU

buildroot и procfs

 , , ,


0

1

Здравствуйте! Работаю с SoC Zynq. До этого использовал систему сборки Petalinux. В своем драйвере использую procfs для отображения различного рода информации и с помощью саt в /proc/mydev информация правильно отображалась. Сейчас перешел на buildroot и когда выполняю cat /proc/mydev вывод зацикливается, т.е. cat не завершается, а постоянно выводит одно и тоже сообщение. Помогите разобраться в чем может быть причина.

В petalinux использовался для компиляции вендорный кросс-компилятор от Xilinx arm-xilinx-linux-gnu-eabi-gcc, сейчас buildroot использует свой arm-buildroot-linux-uclibcgnueabihf-gcc, стоит ли смотреть в сторону того что не правильно может быть компилирую?

Сама компиляция

define MYDEV_MODULE_BUILD_CMDS
	$(MAKE) $(LINUX_MAKE_FLAGS) CC=$(TARGET_CC) HOSTCC=$(HOSTCC) LD=$(TARGET_LD) -C $(@D) KERNELDIR=$(LINUX_DIR) modules
endef

Метод proc_read

static ssize_t chrdrv_read_proc(struct file *filp, char *buffer, size_t length, loff_t *offset) {
    int ret = 0;
    static int finished = 0;

    if (finished) {
        finished = 0;
        return 0;
    } 
    
    finished = 1;
    ret = sprintf(buffer, "%d\n, param);

    return ret;
}

Попробовал использовать при сборке тулчейн от Xilinx, та же проблема.

Ответ на: комментарий от zudwa

Можете подсказать на счет заголовков. Сейчас версия ядра 4.4.0, собирал с заголовками 3.19, так как когда выставлял 4.4 получал следующую ошибку: Incorrect selection of kernel headers: expected 4.4.x, got 3.19.x. Допустимо ли так делать и как заставить собирать с заголовками 4.4.

AlekseyPash ()
Ответ на: комментарий от AlekseyPash

Для начала непонятно, как вы собираете свой модуль.

Сборка модуля в buildroot http://nightly.buildroot.org/#_infrastructure_for_packages_building_kernel_mo...

Если не в buildroot, то, видимо, нужно собирать тулчейном с заголовками из output KDIR=«1/2/3/buildroot/output/build/linux-xyz»

make -C ${KDIR} M=`pwd` CROSS_COMPILE=«1/2/3/buildroot/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabihf-»

zudwa ()
Ответ на: комментарий от zudwa

Собираю следующим образом

Файл .mk

MYDEV_MODULE_VERSION = 1.0
MYDEV_MODULE_SITE = /opt/build/components/modules/mydev
MYDEV_MODULE_SITE_METHOD = local
MYDEV_MODULE_DEPENDENCIES = linux

define MYDEV_MODULE_BUILD_CMDS
	$(MAKE) $(LINUX_MAKE_FLAGS) CC=$(TARGET_CC) -C $(@D) KERNELDIR=$(LINUX_DIR) modules
endef

define MYDEV_MODULE_INSTALL_TARGET_CMDS
	$(MAKE) $(LINUX_MAKE_FLAGS) CC=$(TARGET_CC) -C $(@D) KERNELDIR=$(LINUX_DIR) modules_install
endef

$(eval $(kernel-module))
$(eval $(generic-package))

Makefile в папке с исходниками /opt/build/components/modules/mydev

obj-m := mydev.o
PWD := $(shell pwd)

all: modules

modules:
	$(MAKE) -C $(KERNELDIR) M=$(PWD) modules

modules_install:
	$(MAKE) -C $(KERNELDIR) M=$(PWD) INSTALL_MOD_PATH=$(TARGET_DIR) modules_install

Во время компиляции пишется слудующее

/usr/bin/make -j9 HOSTCC=«/usr/bin/gcc» HOSTCFLAGS=«» ARCH=arm INSTALL_MOD_PATH=/opt/build/buildroot/output/target CROSS_COMPILE=«/opt/build/buildroot/output/host/usr/bin/arm-xilinx-linux-gnueabi-» DEPMOD=/opt/build/buildroot/output/host/sbin/depmod LOADADDR=«0x8000» INSTALL_MOD_STRIP=1 CC=/opt/build/buildroot/output/host/usr/bin/arm-xilinx-linux-gnueabi-gcc -C /opt/build/buildroot/output/build/orbita-module-1.0 KERNELDIR=/opt/build/buildroot/output/build/linux-xilinx-v2016.2 modules make[1]: вход в каталог «/opt/build/buildroot/output/build/mydev-1.0» /usr/bin/make -C /opt/build/buildroot/output/build/linux-xilinx-v2016.2 M=/opt/build/buildroot/output/build/mydev-1.0 modules

Установка

/usr/bin/make -j9 HOSTCC=«/usr/bin/gcc» HOSTCFLAGS=«» ARCH=arm INSTALL_MOD_PATH=/opt/build/buildroot/output/target CROSS_COMPILE=«/opt/build/buildroot/output/host/usr/bin/arm-xilinx-linux-gnueabi-» DEPMOD=/opt/build/buildroot/output/host/sbin/depmod LOADADDR=«0x8000» INSTALL_MOD_STRIP=1 CC=/opt/build/buildroot/output/host/usr/bin/arm-xilinx-linux-gnueabi-gcc -C /opt/build/buildroot/output/build/mydev-1.0 KERNELDIR=/opt/build/buildroot/output/build/linux-xilinx-v2016.2 modules_install make[1]: вход в каталог «/opt/build/buildroot/output/build/mydev-1.0» /usr/bin/make -C /opt/build/buildroot/output/build/linux-xilinx-v2016.2 M=/opt/build/buildroot/output/build/mydev-1.0 INSTALL_MOD_PATH=/opt/build/buildroot/output/target modules_install

AlekseyPash ()
Ответ на: комментарий от AlekseyPash

Сейчас версия ядра 4.4.0, собирал с заголовками 3.19, так как когда выставлял 4.4 получал следующую ошибку: Incorrect selection of kernel headers: expected 4.4.x, got 3.19.x.

Есть ли возможность почистить временную папку, где осуществляется сборка? Хотя бы ядра? Обычно такие системы сборки иногда могут дурить и чистка это лечит.

Допустимо ли так делать и как заставить собирать с заголовками 4.4.

Могу ошибаться, по вроде как не допустимо.

I-Love-Microsoft ★★★★★ ()
Ответ на: комментарий от AlekseyPash

Не, make clean я не считаю за достаточно надежную чистку в этом случае, только полное удаление каталога сборки или через систему контроля версий.

I-Love-Microsoft ★★★★★ ()
Ответ на: комментарий от AlekseyPash

стало более понятно, как модуль собирается.

Заголовки ядра в настройках тулчейна должны соответствовать версии ядра.

Попробуйте очистить цель ядра командой make linux-dirclean или удалите директории linux* из output/build/. Еще желательно удалить архивы с ядром из buildroot/dl

zudwa ()
Ответ на: комментарий от zudwa

В общем заново извлек buildroot, все равно ругается на Incorrect selection of kernel headers: expected 4.4.x, got 3.19.x и не дает мне собрать тулчейоном от xilinx их ядро 4.4.0 с такими же заголовками. Вернулся к встроенному тулчейну, у него заголовки правильные выставлены. С ним все в порядке, вот как компилирует:

/usr/bin/make -j9 HOSTCC=«/usr/bin/gcc» HOSTCFLAGS=«» ARCH=arm INSTALL_MOD_PATH=/opt/build/buildroot/output/target CROSS_COMPILE=«/opt/build/buildroot/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabihf-» DEPMOD=/opt/build/buildroot/output/host/sbin/depmod LOADADDR=«0x8000» INSTALL_MOD_STRIP=1 CC=/opt/build/buildroot/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabihf-gcc -C /opt/build/buildroot/output/build/orbita-module-1.0 KERNELDIR=/opt/build/buildroot/output/build/linux-xilinx-v2016.2 modules make[1]: вход в каталог «/opt/build/buildroot/output/build/mydev-1.0» /usr/bin/make -C /opt/build/buildroot/output/build/linux-xilinx-v2016.2 M=/opt/build/buildroot/output/build/mydev-1.0 modules

Проблема с cat /proc/mydev осталась. На самом деле мне использование proc в драйвере не критично, просто интересно понять почему так происходит и важно знать что все правильно собираю под эту платформу и все будет работать. Во время отладки наблюдал, что метод chrdrv_read_proc() работал как нужно, т.е. попадал в условие

if (finished) {
    finished = 0;
    return 0;
}
т.е. по идее возвращает 0, но cat не завершается(((

AlekseyPash ()
Ответ на: комментарий от AlekseyPash

вообще нужно код cat еще смотреть, почему 0 прочитанных байт не соответствует eof

или написать собственную утилиту чтения proc

zudwa ()
Ответ на: комментарий от zudwa

Реализовал proc следующим образом:

static int hello_proc_show(struct seq_file *m, void *v) {
    char buffer[80];
    sprintf(buffer, "%d\n", param);
    seq_printf(m, buffer);
    return 0;
}

static int hello_proc_open(struct inode *inode, struct  file *file) {
    return single_open(file, hello_proc_show, NULL);
}

static const struct file_operations proc_fops = {
    .owner = THIS_MODULE,
    .open = hello_proc_open,
    .read = seq_read,
    .llseek = seq_lseek,
    .release = single_release,
};

так все работает корректно.

AlekseyPash ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.