Arm с внешней шиной данных?

Сегодня занимался малиной (настройка по теме):
http://forum.amperka.ru/threads/Вопрос-по-выбору-корпуса-для-малины-4-есть-ли-мнение-опыт.22043/#post-290060
Ну и подумал, а что если:
- Положить исходники linux-2.6.27(те, что для платы AT91SAM9260-EK) на малину в /usr/src/linux-2.6.27;
- отпедалировать Makefile:

Код (Text):

#
obj-m += mod0.o
obj-m += mod1.o

all:
        make ARCH=arm CROSS_COMPILE=arm-none-eabi- -C /usr/src/linux-2.6.27 M=$(PWD) modules
clean:
        make ARCH=arm CROSS_COMPILE=arm-none-eabi- -C /usr/src/linux-2.6.27 M=$(PWD) clean

это предыдущий пример, а на малину установлен по apt-get компилятор arm-none-eabi-gcc(и пр.);
- собрать на самой малине;
- по FTP переслать на плату AT91SAM8260-EK;
- и испытать:
... загрука и проверка:

Код (Text):

bash-3.2# insmod mod0.ko
bash-3.2# insmod mod1.ko
bash-3.2#
bash-3.2#
bash-3.2# lsmod
mod1 3252 0 - Live 0xbf002000
mod0 2244 1 mod1, Live 0xbf000000
bash-3.2#

... испытание работы:

Код (Text):

bash-3.2# echo "123456789abcdefgh123321" > /dev/test_mod1
bash-3.2# cat /dev/test_mod1                          
123321hgfedcba987654321
bash-3.2#

... выхлоп по dmesg (конец):

Код (Text):

from /dev/test_mod1: len=24
From mod1: SI:1 (HEX=31)
From mod1: SI:2 (HEX=32)
From mod1: SI:3 (HEX=33)
From mod1: SI:4 (HEX=34)
From mod1: SI:5 (HEX=35)
From mod1: SI:6 (HEX=36)
From mod1: SI:7 (HEX=37)
From mod1: SI:8 (HEX=38)
From mod1: SI:9 (HEX=39)
From mod1: SI:a (HEX=61)
From mod1: SI:b (HEX=62)
From mod1: SI:c (HEX=63)
From mod1: SI:d (HEX=64)
From mod1: SI:e (HEX=65)
From mod1: SI:f (HEX=66)
From mod1: SI:g (HEX=67)
From mod1: SI:h (HEX=68)
From mod1: SI:1 (HEX=31)
From mod1: SI:2 (HEX=32)
From mod1: SI:3 (HEX=33)
From mod1: SI:3 (HEX=33)
From mod1: SI:2 (HEX=32)
From mod1: SI:1 (HEX=31)
From mod1: SI:
(HEX=0A)
mod0: outstr sim(num=0):1
mod0: outstr sim(num=1):2
mod0: outstr sim(num=2):3
mod0: outstr sim(num=3):3
mod0: outstr sim(num=4):2
mod0: outstr sim(num=5):1
mod0: outstr sim(num=6):h
mod0: outstr sim(num=7):g
mod0: outstr sim(num=8):f
mod0: outstr sim(num=9):e
mod0: outstr sim(num=10):d
mod0: outstr sim(num=11):c
mod0: outstr sim(num=12):b
mod0: outstr sim(num=13):a
mod0: outstr sim(num=14):9
mod0: outstr sim(num=15):8
mod0: outstr sim(num=16):7
mod0: outstr sim(num=17):6
mod0: outstr sim(num=18):5
mod0: outstr sim(num=19):4
mod0: outstr sim(num=20):3
mod0: outstr sim(num=21):2
mod0: outstr sim(num=22):1
from mod0:123321hgfedcba987654321
len=24
bash-3.2#
 

Был использован прошлый пример (он конечно кривой) предназначенный только для испытания(в обучениия)

Выходит на малине реально что-то делать не для самой малины.

PS: я не знаком с тонкостями, но при сборке на малине было такое:

Код (Text):

/home/igor/ramdisk/testmod3/mod1.c:19:16: error: expected declaration specifiers or '...' before string constant
MODULE_SOFTDEP("pre: mod0");

Закомментировал строку:

Код (Text):

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Igor D: 19.08.2021");
MODULE_DESCRIPTION("mod1 testing.");
MODULE_VERSION("1.01");
//MODULE_SOFTDEP("pre: mod0");

И всё собралось! А результат испытаний уже показал.
Кстати всё проводилось(редактирование, сборка) в RAM диске малины.

 

tmpfs или ramfs? У меня ramfs даже из fstab девались после перезагрузки куда-то или нет. Не помню точно. Поэтому сейчас используют tmpfs. Но она если что может попасть в swap.

 

Ответ относится к малине, а не платы:
... это fsab:

Код (Text):

proc            /proc           proc    defaults          0       0
PARTUUID=fc155e9a-01  /boot           vfat    defaults          0       2
PARTUUID=fc155e9a-02  /               ext4    defaults,noatime  0       1
tmpfs /var/bench tmpfs nodev,nosuid,size=4G 0 0
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

... выхлоп по df:

Код (Text):

igor@Irpi4:/etc $ df
Файловая система 1K-блоков Использовано Доступно Использовано% Cмонтировано в
/dev/root         60455668      7181136 50765752           13% /
devtmpfs           3879284            0  3879284            0% /dev
tmpfs              4044148            0  4044148            0% /dev/shm
tmpfs              4044148         8976  4035172            1% /run
tmpfs                 5120            4     5116            1% /run/lock
tmpfs              4044148            0  4044148            0% /sys/fs/cgroup
tmpfs              4194304            0  4194304            0% /var/bench
/dev/mmcblk0p1      258095        49172   208924           20% /boot
tmpfs               808828            0   808828            0% /run/user/1000
tmpfs               808828            0   808828            0% /run/user/1001
igor@Irpi4:/etc $

...ОЗУ по free:

Код (Text):

gor@Irpi4:/etc $ free
              total        used        free      shared  buff/cache   available
Mem:        8088300       88556     7801428        9304      198316     7762224
Swap:             0           0           0
igor@Irpi4:/etc $
 

Всё это прямо сейчас.

 

Сейчас курю утилиту make.
Интересует вопрос: как подставлять пути для компилятора gcc. Интересуют основные общепринятые правила, а конкретно пример.

 

Путь к компилятору?

Код (Bash):

CC = /usr/bin/gcc #путь не рабочий

По примерам я с этого (комментарии интересней самой статьи) начал... вчера.

 

Нет, а не много другое. Например имеется:

Код (C++):

#include <sys/test.h>
....

А этот test.h на самом деле в директории linux/test.h к примеру, причем одноименный test.h находится и в asm и в arch и ещё ряде других директорий. И этим test.h пользуется толпа файлов на Си, которые "обращаются" к этому <sys/test.h> из разных директорий... и все они(все вместе) находятся в директории проекта.
А такой пример, как:

Код (C++):

CC := /usr/bin/arm-linux-gcc
AR := /usr/bin/arm-linux-ar
....

который проще записать так:

Код (C++):

CP := /usr/bin/arm-linux
...
CC := $(CP)-gcc
LD := $(CP)-ld
AR := $(AR)-ar
....

Понятен давно.
Вот как подсовывать путь к файлу в Maktfile, а не менять каждый файл исходников?
Ну там и ещё всякие тонкости.

PS: вот эти инструкции:

Код (C++):

FI := -I/usr/include
FL := -L/usr/lib
 

ясны давно, про ключи компилятора можно спросить у него самого... ну или читать маны.

 

Сейчас пользую CodeLite (подключил ему компилятор arm-none-eabi), тоторый компилит для платы. Не очень пока корректно - надо его настроить... Буду подглядывать как там сама среда разработки создаёт Makefile. Ну и попробую конечно что-то.

PS: У меня с make большооооооооооо....ооой пробел.

 

Вот применил CodeLite (всё делалось на малине, но для платы AT91SAM9260-ek)...
настроил сборку модуля, тестового модуля... точнее модулей - пример выше. Проект типа "Custom Makefile"
Вот методика:
https://fooobar.com/questions/17572703/makefile-to-codelite
Но есть и на английском, которой и воспользовался, потому как попалась раньше.
Модули собрались на малине и работают на плате:

Код (Text):

bash-3.2# insmod mod0.ko
bash-3.2# insmod mod1.ko
bash-3.2# ls /dev
audio               mmcblk0p2           ptyp3               ram2                tty12               tty31               tty50               ttyS3               usbdev1.1_ep00
console             mmcblk0p3           ptyp4               ram3                tty13               tty32               tty51               ttyS4               usbdev1.1_ep81
controlC0           mmcblk0p4           ptyp5               ram4                tty14               tty33               tty52               ttyS5               usbdev1.2_ep00
cpu_dma_latency     mtd0                ptyp6               ram5                tty15               tty34               tty53               ttyS6               usbdev1.2_ep02
dsp                 mtd0ro              ptyp7               ram6                tty16               tty35               tty54               ttyp0               usbdev1.2_ep03
full                mtd1                ptyp8               ram7                tty17               tty36               tty55               ttyp1               usbdev1.2_ep04
kmem                mtd1ro              ptyp9               ram8                tty18               tty37               tty56               ttyp2               usbdev1.2_ep81
kmsg                mtd2                ptypa               ram9                tty19               tty38               tty57               ttyp3               usbdev1.2_ep82
loop0               mtd2ro              ptypb               random              tty2                tty39               tty58               ttyp4               usbdev1.2_ep83
loop1               mtdblock0           ptypc               root                tty20               tty4                tty59               ttyp5               usbdev1.2_ep84
loop2               mtdblock1           ptypd               rtc0                tty21               tty40               tty6                ttyp6               vcs
loop3               mtdblock2           ptype               seq                 tty22               tty41               tty60               ttyp7               vcsa
loop4               network_latency     ptypf               sequencer           tty23               tty42               tty61               ttyp8               zero
loop5               network_throughput  ram0                sequencer2          tty24               tty43               tty62               ttyp9
loop6               null                ram1                test_mod1           tty25               tty44               tty63               ttypa
loop7               pcmC0D0p            ram10               timer               tty26               tty45               tty7                ttypb
mem                 ptmx                ram11               tty                 tty27               tty46               tty8                ttypc
mice                pts                 ram12               tty0                tty28               tty47               tty9                ttypd
mixer               ptyp0               ram13               tty1                tty29               tty48               ttyS0               ttype
mmcblk0             ptyp1               ram14               tty10               tty3                tty49               ttyS1               ttypf
mmcblk0p1           ptyp2               ram15               tty11               tty30               tty5                ttyS2               urandom
bash-3.2# echo "0123456789abcdefgh" > /dev/test_mod1
bash-3.2# cat /dev/test_mod1
hgfedcba9876543210
hgfedcba9876543210
bash-3.2# lsmod
mod1 3252 0 - Live 0xbf002000
mod0 2244 1 mod1, Live 0xbf000000
bash-3.2#

Почему в CodeLite? Да потому, что навигация в проекте легче и проще!
Только вот вопрос: простые исполняемые файлы не могу собрать рабочие пока.
На ПК собираются, на самой плате собираются... а вот на малине, ну никак!
И GCC курил малиновый, а он тот же самый, что и arm-linux-gnueabif-gcc (но есть ещё и arm-none-eabi, которым в режиме кросс компиляции собрал модули). Там куча ключей... и архитектуру ARM можно выбрать, и много чего. Может include и lib для компиляции надо для самой платы? С модулями ядра всё ясно - там есть исходники ядра и прочее. Но они совсем не пригодны для компиляции исполняемого кода.

PS: надо для платы собрать BlueZ с либами, да и про iwconfig подумать.

 

И вот ещё:

Код (Text):

make ARCH=arm -C /usr/src/linux-2.6.27 M=/var/ramdisk/testmod3 modules
sh: set: -e: invalid option
sh: set: -e: invalid option
sh: set: -e: invalid option
sh: set: -e: invalid option
sh: set: -e: invalid option
sh: set: -e: invalid option
sh: set: -e: invalid option
sh: set: -e: invalid option
sh: set: -e: invalid option
sh: set: -e: invalid option
sh: set: -e: invalid option
sh: set: -e: invalid option
sh: set: -e: invalid option
sh: set: -e: invalid option
sh: set: -e: invalid option
sh: set: -e: invalid option
sh: set: -e: invalid option
make[1]: Entering directory `/mnt/part4/src/linux-2.6.27'
sh: set: -e: invalid option

  ERROR: Kernel configuration is invalid.
         include/linux/autoconf.h or include/config/auto.conf are missing.
         Run 'make oldconfig && make prepare' on kernel src to fix it.

sh: set: -e: invalid option
sh: set: -e: invalid option

  WARNING: Symbol version dump /mnt/part4/src/linux-2.6.27/Module.symvers
           is missing; modules will have no dependencies and modversions.

sh: set: -e: invalid option
sh: set: -e: invalid option
  CC [M]  /var/ramdisk/testmod3/mod0.o
cc1: error: include/linux/autoconf.h: No such file or directory
....
....
...
 

Это попытка собрать вышеуказанный пример прямо на смой плате. Тут утилита "set" не довольна.
Это чем-то побеждается, или принимать как есть без вариантов?

 

Вот подсказал бы кто... посоветовал... про кросс компиляцию.
Испытывал и arm-linux-gnueabi(hf) и arm-none-eabi на разных платформах:
-- виртуальная машина Debian
-- реальная машина Debian
-- малина 4 Raspbian
Везде код длинный(~30...40 кБ) и не рабочий (испытывается на плате) и это просто "Hello World"
Но есть одно но - один компилятор armv5l-gcc, который так же поставил на виртуальный Debian работает на плате и размер кода после компиляции этого примера ~4...5 кБ, который работает на плате (только в конце выполнения выплёвывает Segmentation fault).
Так же работает на плате и откомпилированный на ней тот же пример, который имеет размер ~4...5 кБ. и завершается нормально.
Ковырял по разному Makefile.

Код (Text):

###########################
# Simple Generic Makefile #
###########################

CrC    := arm-none-eabi
#CrC    := arm-linux-gnueabihf

#INC    := -I/usr/local/cross-compiler-armv5l/gcc/include -I/usr/local/cross-compiler-armv5l/include
#LIB    := -L/usr/local/cross-compiler-armv5l/gcc/lib -L/usr/local/cross-compiler-armv5l/lib

#--entry main
#CONFIG_NEWLIB_LIBC_NANO=y

CFLAGS    :=
#CFLAGS    += -f
CFLAGS    += -Wa,-k
CFLAGS    += -c
CFLAGS    += -Wall
CFLAGS    += -O2
CFLAGS    += -v
CFLAGS    += -Wa,--fix-v4bx
#CFLAGS    += -muclibc
#CFLAGS    += -lgcc
CFLAGS    += --entry main
CFLAGS    += --specs=nosys.specs
#CFLAGS    += -Wl,--gc-section
CFLAGS += -mcpu=arm926ej-s
CFLAGS += -march=armv5tej
#CFLAGS += -marm

LDFLAGS    :=
#LDFLAGS    := -lm
LDFLAGS += -lc
#LDFLAGS    := -s
#LDFLAGS := =ldl
#LDFLAGS += -lgcc
#LDFLAGS += -libc
#LDFLAGS += -lrdimon
LDFLAGS += --verbose
#LDFLAGS += -march=armv5
#LDFLAGS += -mcpu=arm926ej-s
#LDFLAGS += -mtune=arm926ej-s
#LDFLAGS += --specs=nosys.specs
LDFLAGS += --entry main
#LDFLAGS += -mabi=0
#LDFLAGS += -mabi=apcs-gnu
#LDFLAGS += -mfloat-abi=soft
#LDFLAGS += -Wl,--wrap=malloc
#LDFLAGS    += -muclibc
#LDFLAGS += --fix-v4bx
#LDFLAGS    := --fix-v4bx-interworking
#LDFLAGS    += -nostdlib
LDLAGS += -march=armv5tej

#ifeq ( $(nuncrc), 1)
#@echo "compiler = "$CrC
CC    := $(CrC)-gcc #/usr/bin/arm-none-eabi-gcc
LD    := $(CrC)-ld #/usr/bin/arm-none-eabi-ld
AS    := $(CrC)-as #/usr/bin/arm-none-eabi-as
#endif

SOURCES         := $(shell ls *.c)
OBJECTS         := $(SOURCES:.c=.o)
EXECUTABLE      := test


all: $(EXECUTABLE)

$(OBJECTS): $(SOURCES)
    $(CC) $(INC) $(LIB) $(CFLAGS) $< -o $@

$(EXECUTABLE): $(OBJECTS)
    $(LD) $(INC) $(LIB) $(LDFLAGS) $< -o $@

#install:
#    install -m 0755 $(EXECUTABLE) $(HOME)/local/bin

clean:
    @echo "--- CLEAN ---"
    rm -rf *o $(EXECUTABLE)

Видите сколько комментариев - они то есть , то нет... провожу подбор ключей. Но ведь должно же как-то работать.
Менял тут:

Код (Text):

$(EXECUTABLE): $(OBJECTS)
    $(LD) $(INC) $(LIB) $(LDFLAGS) $< -o $@

LD на CC туда и обратно в процессе эксперимента.

Тем не менее Makefile для armv5l-gcc, который на виртуальном Debian:

Код (Text):

###########################
# Simple Generic Makefile #
###########################

#CC=terminal-gcc

CC    := /usr/local/cross-compiler-armv5l/bin/armv5l-gcc
LD    := /usr/local/cross-compiler-armv5l/bin/armv5l-ld
AS    := /usr/local/cross-compiler-armv5l/bin/armv5l-as

INC    := -I/usr/local/cross-compiler-armv5l/include:/usr/local/cross-compiler-armv5l/gcc/include
LIB    := -L/usr/local/cross-compiler-armv5l/lib:/usr/local/cross-compiler-armv5l/gcc/lib

#PREFIXPATH=/usr/local/arm-linux/bin
#CC=$(PREFIXPATH)/arm-linux-gcc

#STRIP=$(PREFIXPATH)/arm-linux-strip
#NAME=proxy


CFLAGS    := -c -Wall -O2 -v
LDFLAGS    := --entry main --verbose -lc

#SOURCES=*.c
SOURCES         := $(shell ls *.c)

OBJECTS         := $(SOURCES:.c=.o)
EXECUTABLE      := test

#all: $(SOURCES) $(EXECUTABLE)
#$(EXECUTABLE):
#    $(LD) $(OBJECTS) $(LIB) $(LDFLAGS) $(OBJECTS) -o $@

#all: $(OBJECTS)
#    $(CC) $(LDFLAGS) $(LIB) $(OBJECTS) -o $@
all: $(EXECUTABLE)

$(OBJECTS): $(SOURCES)
    $(CC) $(INC) $(LIB) $(CFLAGS) $< -o $@
$(EXECUTABLE): $(OBJECTS)
    $(CC) $(INC) $(LIB) $(LDFLAGS) $< -o $@

#install:
#    install -m 0755 $(EXECUTABLE) $(HOME)/local/bin

clean:
    rm -rf *o $(EXECUTABLE)
 

И тот Makefile, который работает на самой плате:

Код (Text):

###########################
# Simple Generic Makefile #
###########################

CC      := /usr/bin/gcc
LD      := /usr/bin/ld
AS      := /usr/bin/as

INC     := -I/usr/include -I/usr/gcc/include
LIB     := -L/usr/lib -L/usr/gcc/lib

CFLAGS  := -c -Wall -O2 -v
LDFLAGS := --entry main --verbose

SOURCES         := $(shell ls *.c)
OBJECTS         := $(SOURCES:.c=.o)
EXECUTABLE      := test

all: $(EXECUTABLE)

$(OBJECTS): $(SOURCES)
        $(CC) $(INC) $(LIB) $(CFLAGS) $< -o $@

$(EXECUTABLE): $(OBJECTS)
        $(CC) $(INC) $(LIB) $(LDFLAGS) $< -o $@

#install:
#       install -m 0755 $(EXECUTABLE) $(HOME)/local/bin

clean:
        rm -rf *o $(EXECUTABLE)
 

Они практически идентичны

Отчёт компиляции не выкладываю - уж больно иного.
Только отрывки:

Код (Text):

COLLECT_GCC_OPTIONS='-c' '-Wall' '-O2' '-v' '-e' 'main' '-specs=nosys.specs' '-mcpu=arm926ej-s' '-march=armv5tej' '-o' 'main.o'
/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/as -v -march=armv5tej -mcpu=arm926ej-s -meabi=5 -k --fix-v4bx -o main.o /tmp/ccojRkXW.s
GNU assembler version 2.31.1 (arm-none-eabi) using BFD version (2.31.1-11+rpi1+11) 2.31.1
COMPILER_PATH=/usr/lib/gcc/arm-none-eabi/7.3.1/:/usr/lib/gcc/arm-none-eabi/7.3.1/:/usr/lib/gcc/arm-none-eabi/:/usr/lib/gcc/arm-none-eabi/7.3.1/:/usr/lib/gcc/arm-none-eabi/:/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/
LIBRARY_PATH=/usr/lib/gcc/arm-none-eabi/7.3.1/:/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/lib/
COLLECT_GCC_OPTIONS='-c' '-Wall' '-O2' '-v' '-e' 'main' '-specs=nosys.specs' '-mcpu=arm926ej-s' '-march=armv5tej' '-o' 'main.o'
arm-none-eabi-ld     -lc --verbose --entry main -muclibc main.o -o test
arm-none-eabi-ld: unrecognised emulation mode: uclibc
Supported emulations: armelf
make: *** [Makefile:74: test] Ошибка 1
 

Стоит поменять что-то раскомментировать/закомментировать и всякие ошибки пропадают/исчезают.
А тот рабочий кросс компилятор наверное "игрушечный" а этими всеми модули собираются без проблем и все работают.

 

Вот последнее:

Код (Text):

igor@Irpi4:~/ramdisk/bt-tools-codelite/test_from_at91sam9260 $ nm test
00021014 D __bss_end__
00021014 D _bss_end__
00021014 D __bss_start
00021014 D __bss_start__
00020f58 d _DYNAMIC
00021014 D _edata
00021014 D __end__
00021014 D _end
00021000 d _GLOBAL_OFFSET_TABLE_
00010230 T main
         U printf@@GLIBC_2.4
         U puts@@GLIBC_2.4
 

а надо бы так:

Код (Text):

igor@Irpi4:~/ramdisk/bt-tools-codelite/test_from_at91sam9260 $
igor@Irpi4:~/ramdisk/bt-tools-codelite/fromAT $ nm test
         U abort
00010580 A __bss_end__
00010580 A _bss_end__
0001057c A __bss_start
0001057c A __bss_start__
0000846c t call___do_global_ctors_aux
00008380 t call___do_global_dtors_aux
000083bc t call_frame_dummy
0001057c b completed.4932
000104a4 d __CTOR_END__
000104a0 d __CTOR_LIST__
00010568 D __data_start
00010574 W data_start
00008438 t __do_global_ctors_aux
00008324 t __do_global_dtors_aux
0001056c D __dso_handle
000104ac d __DTOR_END__
000104a8 d __DTOR_LIST__
000104b4 d _DYNAMIC
0001057c A _edata
00010580 A __end__
00010580 A _end
00008474 T _fini
00010568 d force_to_data
00010578 d force_to_data
00008388 t frame_dummy
0001049c d __FRAME_END__
0001054c d _GLOBAL_OFFSET_TABLE_
000082c8 T _init
000104b0 d __JCR_END__
000104b0 d __JCR_LIST__
         w _Jv_RegisterClasses
00008400 T main
00010570 d p.4930
         U printf
         U puts
000083c4 T _start
         U __uClibc_main
 

одним словом надо указать uClibc

Что-то ключа не найду никак.

 

А вот у них на сайте, что-то есть.

 

Что-то ни сил ни фантазий более нет.
Поисковики ничего не дают.
Испытывал разные кросс компиляторы на разных устройствах (платформах: x86, ARM).
Только на AQEMU не испытывал.
Причём везде (все устройства) сами для себя собирают нормально.

Мне надо для платы AT91SAM9260 собрать собрать BlueZ, но перед этим надо собрать glib.
Как оказалось собственно модули ядра на всех платформах собрались именно для платы без проблем.
Но вот ряд приложений не собираются вовсе... да тот же BlueZ.
Ни одна ссылка, спасибо конечно, пользы никакой не принесла. Вполне возможно, что смотрю в книгу,
а вижу фигу. Ума не приложу как быть. Уже не единицы суток "курю", а пожалуй больше десятка.

Если не сложно ткните носом! Куда копать? Только если надо тонны перерыть, ради грамма - на такое сил уже нет.

 

Добрый день @Igor68
Для кросссборки программы с uClibc вам понадобятся binutils, gcc (и все, что они тянут в зависимостях) собранные с uClibc. Самый простой способ - воспользоваться готовым сборочным окружением Buildroot или для вашего AT91SAM9260 Linux4SAM.
Напишите, что выводит

Код (Bash):

cat /proc/mtd

и по возможности прикрепите u-boot, firmware и kernel

Код (C++):

cat /dev/mtdXX > u-boot.bin
cat /dev/mtdXX > firmware.bin
cat /dev/mtdXX > kernel .bin

, где /dev/mtdXX разделы соответствующие u-boot, firmware и kernel

 

Доброго времени суток!
Спасибо, что обратили внимание!
Вопрос: я правильно понимаю, что тут речь идёт про сборку ядра (вообще-то исходники ядра уже есть и получается собирать модули ядра, как те которые есть, так и самодельные). У меня не выходит просто компилировать код кросс компиляцией... даже плата для себя может собирать код.
Может я не верно понимаю (сейчас идёт сборка по теме Buildroot). На малине в Raspbian (по инерции, и вот ошибки):

Код (Text):

Сообщения ассемблера:
tmp-divrem_1.s:130: Ошибка: выбранный процессор не поддерживает «mls r1,r4,r8,r11» в режиме ARM
tmp-divrem_1.s:146: Ошибка: выбранный процессор не поддерживает «mls r1,r4,r8,r11» в режиме ARM
tmp-divrem_1.s:159: Ошибка: выбранный процессор не поддерживает «mls r1,r4,r8,r11» в режиме ARM
tmp-divrem_1.s:176: Ошибка: выбранный процессор не поддерживает «mls r1,r4,r3,r8» в режиме ARM
tmp-divrem_1.s:210: Ошибка: выбранный процессор не поддерживает «mls r11,r4,r12,r3» в режиме ARM
make[3]: *** [Makefile:768: divrem_1.lo] Ошибка 1

И на x86, пока готовлюсь...

PS: почему ставку некоторую делаю на малину (на ней что-то делаю для чего-то)?
Да поотму, что она маленькая и спокойно помещается в барсетке (легко траспортируется на работу и обратно ежедневно), имеет достаточное ОЗУ и всё делается в РАМ диске (4 Гб РАМ диска + 4 Гб просто рабочее ОЗУ).
К сожалению MEEGO T02 (x86) никаких надежд не оправдал - игрушка, да и только.

 

Глупо наверное конечно, но делаю параллельно как на raspberry 4 8Gb_RAM и NUC7PJYH 8Gb_RAM... сборка идет.
Правда малина сейчас и интернет по WIFI раздаёт, даже для того же NUC... что-то не заметил, что она медленнее NUC-а... все на ней делается в RAM диске.

 

Сборка на малине умерла:

Код (Text):

/usr/bin/gcc -c -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_divrem_1 -I/home/igor/ramdisk/git/buildroot-at91/output/host/include -O2 -I/home/igor/ramdisk/git/buildroot-at91/output/host/include -Wa,--noexecstack tmp-divrem_1.s -fPIC -DPIC -o .libs/divrem_1.o
tmp-divrem_1.s: Сообщения ассемблера:
tmp-divrem_1.s:130: Ошибка: выбранный процессор не поддерживает «mls r1,r4,r8,r11» в режиме ARM
tmp-divrem_1.s:146: Ошибка: выбранный процессор не поддерживает «mls r1,r4,r8,r11» в режиме ARM
tmp-divrem_1.s:159: Ошибка: выбранный процессор не поддерживает «mls r1,r4,r8,r11» в режиме ARM
tmp-divrem_1.s:176: Ошибка: выбранный процессор не поддерживает «mls r1,r4,r3,r8» в режиме ARM
tmp-divrem_1.s:210: Ошибка: выбранный процессор не поддерживает «mls r11,r4,r12,r3» в режиме ARM
make[3]: *** [Makefile:768: divrem_1.lo] Ошибка 1
make[3]: *** Ожидание завершения заданий…
libtool: compile:  /usr/bin/gcc -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mul -I/home/igor/ramdisk/git/buildroot-at91/output/host/include -O2 -I/home/igor/ramdisk/git/buildroot-at91/output/host/include -c mul.c  -fPIC -DPIC -o .libs/mul.o
libtool: compile:  /usr/bin/gcc -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mod_1_3 -I/home/igor/ramdisk/git/buildroot-at91/output/host/include -O2 -I/home/igor/ramdisk/git/buildroot-at91/output/host/include -c mod_1_3.c  -fPIC -DPIC -o .libs/mod_1_3.o
make[3]: выход из каталога «/home/igor/ramdisk/git/buildroot-at91/output/build/host-gmp-6.2.1/mpn»
make[2]: *** [Makefile:997: all-recursive] Ошибка 1
make[2]: выход из каталога «/home/igor/ramdisk/git/buildroot-at91/output/build/host-gmp-6.2.1»
make[1]: *** [Makefile:787: all] Ошибка 2
make[1]: выход из каталога «/home/igor/ramdisk/git/buildroot-at91/output/build/host-gmp-6.2.1»
make: *** [package/pkg-generic.mk:250: /home/igor/ramdisk/git/buildroot-at91/output/build/host-gmp-6.2.1/.stamp_built] Ошибка 2
 

на NUC-е сборка продолжается.

 

Вот ковырялся с платой, т.е. с загрузчиком U_Boot... ковырялся с его менюшкой. По причине того, что в Linux-2.6.27 трудности с установкой драйверов и софта для wifi и bluetooth (что вообще-то и надо)
Теперь в консоли выдает:

Код (Text):

>ROMBOOT

Понимаю, что снёс всё под чистую.
Вопрос: "Это штатный загрузчик SAM-BA или что-то иное?"
Информация: Плата по USB в WinXP(виртуальном) как atm6124.Sys. ATMEL AT91xxxxx Test Board.
Шуганулся - стон! Думал усё... статикой повредил!
Но SAM-BA v2.9 на виртуальной винде с платой работает записал первый попавшийся файл и прочитал - вроде всё нормально.
Только как сказали на Erase зависает. Теперь курю адресное пространство и порядок загрузки. По ссылкам вроде всё есть... но пока не ясно. Попробую ещё JLink применить.
Вот и не ясно с адресами до применения MMU загрузчиком и после. Путаница.
Наверное надо сначала AT91Bootstrap и U-Boot загрузить, но опять не понятно с адресами........

 

Доброго времени суток!
Пробую собрать из исходников Bootstrap-v1.14(то, что по ссылке в этой ветке)
Вариант загрузки NANDFLASH даёт ошибку в конце:

Код (Text):

arm-none-eabi-gcc -nostartfiles -nostdlib -Wl,-Map=nandflash_at91sam9260ek.map,--cref -T ../../../elf32-littlearm.lds -Ttext 0x200000 -n -o nandflash_at91sam9260ek.elf crt0_gnu.o at91sam9260ek.o main.o gpio.o pmc.o debug.o sdramc.o nandflash.o _udivsi3.o _umodsi3.o div0.o udiv.o string.o
/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: section .text.startup LMA [00200e48,00200e6f] overlaps section .data LMA [00200e48,00200f0b]
collect2: error: ld returned 1 exit status
make: *** [Makefile:73: nandflash_at91sam9260ek] Ошибка 1

Вариант загрузки DATAFLASH собирается без проблем.
Испытал для разных платформ (были в исходниках) и везде dataflash нормально,
а nandflash с подобной ошибкой. Как я понял его не устраивает это:

Код (Text):

section .text.startup LMA [00200e48,00200e6f] overlaps section .data LMA [00200e48,00200f0b]

Правильно ли я понимаю, что где-то в исходниках где-то не совпадают адреса для разных файлов в одной сборке?

PS: Там нет make menuconfig, да вообще в директории board для кажой платформы свой Makefile, который надо запускать.
А на моей плате флешка не SPI(dataflash), а nandflash. Причина сборки загрузка иного U-Boot, чем был.

PS: Спросите: А зачем? Ведь можно взять готовое!
Отвечаю: Идея в том что бы исходная плата не могла по умолчанию применять (инициализировать) интерфейсы такие как USB,SPI,I2C,Ethernet и прочие по мере возможности. Оставить только самые необходимые, с которых можно производить загрузку. А при загрузке ядра загружались только нужные путём загрузки модулей ядра (загружаемые модули), которые могут содержаться в системе. Нужны только необходимые средства для загрузки системы из впаянных в плату устройств (NAND к примеру) и средств конфигурации (консоли отладки) и всё. По мере необходимости конфигурировать для разных нужд, но иметь на борту возможность сконфигурировать для разных применений. Одна плата с Linux и толпой IO, которая может быть впаяна в плату устройства, на котором и USB, и SPI, и SD и прочее(которых может и не быть)... т.е. одна деталь широкого применения.

 

Доброго времени суток!
И опять про компиляцию Bootstap(начальный загрузчик - можно взять готовый, но всё же!):
Напомню плата at91sam9260-ek с загрузкой из NAND. Ну конкретно не получается код менее 4096 байт. В коде (nandflash.c) найдено:

Код (C++):

...
/* 16 bits */
        WRITE_NAND_ADDRESS16(0x00);
        WRITE_NAND_ADDRESS16((uSectorAddr >>  0) & 0xFF);
        WRITE_NAND_ADDRESS16((uSectorAddr >>  8) & 0xFF);
        WRITE_NAND_ADDRESS16((uSectorAddr >> 16) & 0xFF);
...
 

и таких мест много, а собственно WRITE_NAND_ADDRESS16 определено так:

Код (C++):

/* 16 bits devices */
#define WRITE_NAND_COMMAND16(d) do{ *(volatile unsigned short *)((unsigned long)AT91C_SMARTMEDIA_BASE | AT91_SMART_MEDIA_CLE) = (unsigned short)(d); } while(0)
#define WRITE_NAND_ADDRESS16(d) do{ *(volatile unsigned short *)((unsigned long)AT91C_SMARTMEDIA_BASE | AT91_SMART_MEDIA_ALE) = (unsigned short)(d); } while(0)
 

Отсюда и вопрос: если в теле программы встречаются вставки, то не выгоднее ли сделать так что бы происходил вызов одной функции вместо того что бы вставлять тело этой функции в месте вставок? А может это для увеличения быстродействия кода и уменьшения применения стека? Следует учесть что вызов функций применяется везде, что есть нормально.
PS: переделка Botstrap в моём случае это не просто изучение кода, но и подготовка что бы сделать свой U-Boot.