Проблема с Linux на AT91RM9200, Unable to handle kernel paging request at virtual address Опции

[dmitry-rf]

Есть устройство на базе модуля UTC920LXv1 (http://telemetry.ru/docs/UTC920LXv1.pdf).
Основные компоненты:
Процессор AT91RM9200CJ-002
Флэш AT49BV641670TU (8Мб)
ОЗУ MT48LC16M16A2 (2х32Мб)
Система - свой Линукс на ядре 2.6.17, собран тулчейном от heavy.
После загрузки остаётся около 40 Мб свободной оперативы:

Код

# cat /proc/meminfo
MemTotal:        62136 kB
MemFree:         44296 kB
Buffers:          9752 kB
Cached:           3328 kB
SwapCached:          0 kB
Active:           4768 kB
Inactive:         9952 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:        62136 kB
LowFree:         44296 kB
SwapTotal:           0 kB
SwapFree:            0 kB
Dirty:               8 kB
Writeback:           0 kB
Mapped:           3260 kB
Slab:             1784 kB
CommitLimit:     31068 kB
Committed_AS:    10852 kB
PageTables:        256 kB
VmallocTotal:   956416 kB
VmallocUsed:      9688 kB
VmallocChunk:   946172 kB

Примерно половина оперативы выделена под рам-диск:

Код

# mount
rootfs on / type rootfs (rw)
/dev/root on / type ext2 (rw)
proc on /proc type proc (rw)
sys on /sys type sysfs (rw)
/dev/ram1 on /var/tmp type ext2 (rw)
/dev/loop0 on /mnt/settings type ext2 (rw)
# df -h /var/tmp/
Filesystem                Size      Used Available Use% Mounted on
/dev/ram1                30.3M    464.0k     28.2M   2% /var/tmp

После загрузки файла размером 4-8Мб в рам-диск система рушится:

Код

Unable to handle kernel paging request at virtual address ecefbeb4
pgd = c3a3c000
[ecefbeb4] *pgd=00000000
Internal error: Oops: 5 [#2]
Modules linked in:
CPU: 0
PC is at fget_light+0x58/0xcc
LR is at 0xecefbeb4
pc : [<c0072a90>]    lr : [<ecefbeb4>]    Not tainted
sp : c082bb74  ip : 00000000  fp : c082bb84
r10: 00000000  r9 : 00000004  r8 : c0e74660
r7 : 00000000  r6 : 00000002  r5 : 00000002  r4 : 00000004
r3 : 572c85fa  r2 : 00000000  r1 : c082bbcc  r0 : 00000002
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: C000317F  Table: 23A3C000  DAC: 00000015
Process inetd (pid: 783, stack limit = 0xc082a198)
Stack: (0xc082bb74 to 0xc082c000)
...

или

Код

Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c3518000
[00000000] *pgd=23491031, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1]
Modules linked in:
CPU: 0
PC is at dev_queue_xmit+0x68/0x224
LR is at ip_output+0x178/0x2dc
pc : [<c017998c>]    lr : [<c019866c>]    Not tainted
sp : c3493bf8  ip : c3493c14  fp : c3493c10
r10: 00000000  r9 : 00000000  r8 : c356eb10
r7 : c082a260  r6 : fffffff4  r5 : c356eae0  r4 : c0c4b000
r3 : 00000100  r2 : c3492000  r1 : 00000000  r0 : c356eae0
Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: C000317F  Table: 23518000  DAC: 00000015
Process httpd (pid: 886, stack limit = 0xc3492198)
...

Не понимаю, почему так происходит...

Вот кое-что интересное вылезло:

Код

u-boot> mtest
Testing 20000000 ... 23ede000:
Iteration:      1
FAILURE (read/write) @ 0x21edddac: expected 0x007b776c, actual 0xff848894)

Адрес 1edddac - это где-то 32 Мб.
Попробовал передать ядру mem=32M вместо mem=64M. Файл успешно загрузился, но распаковать его не удалось - посыпались сообщения:

Код

Out of Memory: Kill process 916 (dnsmasq) score 397 and children.
Out of memory: Killed process 916 (dnsmasq).
oom-killer: gfp_mask=0x200d2, order=0
[<c0028bfc>] (dump_stack+0x0/0x14) from [<c0059b68>] (out_of_memory+0x158/0x184)
[<c0059a10>] (out_of_memory+0x0/0x184) from [<c005acf8>] (__alloc_pages+0x290/0x2b4)
[<c005aa68>] (__alloc_pages+0x0/0x2b4) from [<c007eae8>] (pipe_writev+0x36c/0x440)
[<c007e77c>] (pipe_writev+0x0/0x440) from [<c007ebe0>] (pipe_write+0x24/0x2c)
[<c007ebbc>] (pipe_write+0x0/0x2c) from [<c0071914>] (vfs_write+0xb0/0x178)
[<c0071864>] (vfs_write+0x0/0x178) from [<c0071aa4>] (sys_write+0x4c/0x7c)
r8 = 00000000  r7 = 00000000  r6 = C0D2BF78  r5 = C14E3260
r4 = C14E3280
[<c0071a58>] (sys_write+0x0/0x7c) from [<c0023d40>] (ret_fast_syscall+0x0/0x2c)
r8 = C0023EE4  r7 = 00000004  r6 = 40213830  r5 = 40018000
r4 = 00001000
Mem-info:
DMA per-cpu:
cpu 0 hot: high 6, batch 1 used:5
cpu 0 cold: high 2, batch 1 used:0
DMA32 per-cpu: empty
Normal per-cpu: empty
HighMem per-cpu: empty
Free pages:        1036kB (0kB HighMem)
Active:3430 inactive:2758 dirty:0 writeback:0 unstable:0 free:259 slab:507 mapped:784 pagetables:93
DMA free:1036kB min:724kB low:904kB high:1084kB active:13720kB inactive:11032kB present:32768kB pages_scanned:0 all_unreclao
lowmem_reserve[]: 0 0 0 0
DMA32 free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
DMA: 103*4kB 24*8kB 5*16kB 1*32kB 1*64kB 0*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1036kB
DMA32: empty
Normal: empty
HighMem: empty
Free swap:            0kB
8192 pages of RAM
381 free pages
788 reserved pages
507 slab pages
285 pages shared
0 pages swap cached

Система пока держится

[dch]

u-boot> mtest
Testing 20000000 ... 23ede000:
Iteration: 1
FAILURE (read/write) @ 0x21edddac: expected 0x007b776c, actual 0xff848894)
[/code]
Адрес 1edddac - это где-то 32 Мб.
Попробовал передать ядру mem=32M вместо mem=64M. Файл успешно загрузился, но распаковать его не удалось - посыпались сообщения:

это нормально он у Вас наверное собран из предположения что в системе 32Mb памяти, u-boot может класть стек под себя, те наверное он скомпилирован с размещением по адресу 1F00000. Попробуйте другой тест памяти, например memtester

http://pyropus.ca/software/memtester/

если не поможет, то ищите проблему дальше, попробуйте другую версию ядра.

[dmitry-rf]

Спасибо. Дело, похоже, не в памяти, а в её количестве. Не могу понять, почему при 40 Мб свободной оперативы загрузка небольшого файла вызывает падение ядра...

[Lelick]

boot.bin файл откуда взят, какие в него настройки памяти вписаны?

[dmitry-rf]

boot.bin - это загрузчик? Загрузчик там предустановленный U-Boot 1.1.1 (Aug 3 2007 - 13:20:05).

Код

u-boot> printenv
bootdelay=3
baudrate=115200
ethaddr=12:34:56:78:9A:BC
bootfile="u-boot.bin.gz"
filesize=ce80
fileaddr=21000000
netmask=255.0.0.0
bootargs=root=/dev/ram rw initrd=20a00000,500000 ramdisk_size=32000 console=ttyS0,115200 mem=64M
serial_number=100001964
ipaddr=192.168.1.1
serverip=192.168.1.10
bootcmd=bootm 10020000 10300000
stdin=serial
stdout=serial
stderr=serial

Environment size: 364/8188 bytes

[dmitry-rf]

После множества экспериментов подобрал более-менее рабочую конфигурацию:
ramdisk_size=8192
перед обработкой файла останавливаются все демоны
загружаемый файл не более 4Мб
Если в процессе загрузки-распаковки свободно более 37Мб оперативы, то всё нормально.

Попытка загрузить 6Мб:

Код

Mem: 25344K used, 36940K free, 0K shrd, 13252K buff, 8160K cached
CPU:  66% usr  23% sys   0% nice   0% idle   0% io   1% irq   7% softirq
Load average: 0.15 0.03 0.01
  PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND
1022  1002 root     R     2104   3%  73% sed 1,4d;$d;$d;$d;$d;$d;$d; -
1001   752 root     S     2096   3%  15% httpd -u root:root -h /home/httpd -r
1023  1002 root     S     2096   3%  11% tar xf - -C /tmp
1021   792 root     R     2100   3%   2% top -d 1
  719     1 root     S     3108   5%   0% /bin/ext/gme920/wdogd
    1     0 root     S     2348   4%   0% /sbin/init
  792     1 root     S     2100   3%   0% /bin/sh
1002  1001 root     S     2100   3%   0% /bin/sh /home/httpd/cgi-bin/update_ex
  793     1 root     S     2096   3%   0% /sbin/syslogd -n
  752     1 root     S     2096   3%   0% httpd -u root:root -h /home/httpd -r
  794     1 root     S     1516   2%   0% /bin/inetd
   68     6 root     SW       0   0%   0% [pdflush]
    5     1 root     SW<      0   0%   0% [khelper]
    2     1 root     SWN      0   0%   0% [ksoftirqd/0]
    3     1 root     SW       0   0%   0% [watchdog/0]
    4     1 root     SW<      0   0%   0% [events/0]
    6     1 root     SW<      0   0%   0% [kthread]
   17     6 root     SW<      0   0%   0% [kblockd/0]
   21     6 root     SW<      0   0%   0% [khubd]
Unable to handle kernel paging request at virtual address c562362a
pgd = c3104000
[c562362a] *pgd=00000000
Internal error: Oops: 3 [#1]
Modules linked in:
CPU: 0
PC is at __inode_dir_notify+0x28/0xa0
LR is at dnotify_parent+0x70/0x80
pc : [<c00a0a40>]    lr : [<c00a0b28>]    Not tainted
sp : c30fff18  ip : c30fff3c  fp : c30fff38
r10: c30fff78  r9 : c30fe000  r8 : 00000000
r7 : c0c149f0  r6 : 00000001  r5 : c0c14af4  r4 : c5623626
r3 : 00000006  r2 : 20000013  r1 : 00000001  r0 : c0c149f0
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: C000317F  Table: 23104000  DAC: 00000015
Process sed (pid: 1022, stack limit = 0xc30fe198)
Stack: (0xc30fff18 to 0xc3100000)

Никак не понимаю, почему такого количества ОЗУ не достаточно...

[dmitry-rf]

Если сказать ядру mem=32M и не останавливать демонов, то в процессе загрузки файла оперативы остаётся 4-6М, но ничего не падает. Видимо, проблема в старших 32 мегабайтах. Теперь осталось выяснить причину...
Может дело быть в загрузчике, собранном с #define PHYS_SDRAM_SIZE 0x2000000 /* 32 megs */ ? Или ядро заново инициализирует всё железо?

[dch]

в boot.bin настраивается конфигурация SDRAM

когда то у книг были поля ...

[dmitry-rf]

в boot.bin настраивается конфигурация SDRAM

когда то у книг были поля ...

Т.е. всё же загрузчик должен конфигурять память? Я со встраиваемыми системами работаю совсем недавно и очень многого еще не знаю.
Вот есть такая строка в файле "u-boot-1.1.6/include/configs/at91rm9200dk.h":

Код

#define PHYS_SDRAM_SIZE 0x2000000  /* 32 megs */

А вот в файле "http://www.ucrouter.ru/download/boot.patch.tgz" говорится:

Код

If SDRAM size is 32Mb uncomment line:
  #CFLAGS += -DDRAM_SIZE_32MB

Объясните пожалуйста, где и каким образом указать размер имеющейся ОЗУ?

[dch]

Т.е. всё же загрузчик должен конфигурять память? Я со встраиваемыми системами работаю совсем недавно и очень многого еще не знаю.
Вот есть такая строка в файле "u-boot-1.1.6/include/configs/at91rm9200dk.h":

u-boot он не настраивает память, но знать ему сколько ее есть необходимо. Например когда грузится файл tftp - чтобы не выйти за пределы SDRAM. Поэтом такая константа введена. Но точто настраивается в boot.bin никак не передается u-boot. Это независимые настройки.

А вот в файле "http://www.ucrouter.ru/download/boot.patch.tgz" говорится:

Код

If SDRAM size is 32Mb uncomment line:
  #CFLAGS += -DDRAM_SIZE_32MB

Объясните пожалуйста, где и каким образом указать размер имеющейся ОЗУ?

я не поставляю оценочных комлектов на базе AT91RM9200 в комплекте с 64MB SDRAM,
и соответсвенно в коде нет поддержки 64MB, нужно прописать определенные значения,
строчка которую Вы приводите взята из патча который накладывается на исходные
тексты boot.bin и вносит изменения в makefile. Если Вы ее раскоментируете то компилятор
определяет константу DRAM_SIZE_32MB, а в исходных текстах есть код который
включается конструкцией типа

#ifdef DRAM_SIZE_32MB
настройка регистров
#endif

[dmitry-rf]

Объясните пожалуйста, что есть boot.bin?

Далее, до сих пор не понятно, кто именно отвечает за размер ОЗУ - загрузчик или ядро? Другими словами, ядро падает при обращении к памяти выше 32Мб потому что оно неправильно собрано, или потому что загрузчик передал ему неверную информацию о распределении памяти?

[dmitry-rf]

Здесь говорят:

Код

The bootloader is expected to find and initialise all RAM that the kernel will use

Значит, надо настраивать загрузчик. Но он при старте пишет:

Код

U-Boot 1.1.1 (Aug  3 2007 - 13:20:05)

U-Boot code: 21F00000 -> 21F1A294  BSS: -> 21F1EAB4
RAM Configuration:
Bank #0: 20000000 64 MB
Atmel: AT49BV6416 (64Mbit)
Flash:  8 MB
In:    serial
Out:   serial
Err:   serial
eth: setting MAC address to 12:34:56:78:9a:bc
PHY not connected!!
Link: 100baseTX Full Duplex
Hit any key to stop autoboot:  0

Значит ли это, что он сконфигурировал все 64 Мб? Наверно, нет, т.к. при проверке памяти возникает ошибка, которую dch объяснил выше.

Я поправил файл include/configs/at91rm9200dk.h, собрал. Как правильно прошить? Через u-boot или romboot? И какой файл: u-boot, u-boot.bin?

Сообщение отредактировал dmitry-rf - Jun 2 2008, 15:21

[dch]

Здесь говорят:

Код

The bootloader is expected to find and initialise all RAM that the kernel will use

там по разному может быть сделано, надо глянуть и статью и код, оригинальный u-boot 1.1.1 ожидает что память проиницализирована, а размер памяти может брать из регистров а может брать и из константы. у меня boot.bin лежит в первых 64K, у Вас он наверное называется u-boot.bin - он инициирует SDRAM и разворачивает u-boot.bin.gz {последний зипованный} , который лежит
в следующих 64K. Если у Вас u-boot.bin разворачивает зипованный файт, то нужно зипнуть u-boot собранный, прошить можно средствами u-boot-а. Я бы посмотрел точно ли размер памяти настраивается в u-boot.bin.

[dmitry-rf]

Похоже, действительно кто-то кого-то распаковывает:

Код

Restarting system.
.
        CPU inited at: 60MHz


boot 1.0.1 (Jul 15 2006 - 17:06:51)

Uncompressing image...

Uncompressing...done.


U-Boot 1.1.1 (Aug  3 2007 - 13:20:05)

U-Boot code: 21F00000 -> 21F1A294  BSS: -> 21F1EAB4
RAM Configuration:
Bank #0: 20000000 64 MB
Atmel: AT49BV6416 (64Mbit)
Flash:  8 MB
In:    serial
Out:   serial
Err:   serial
eth: setting MAC address to 12:34:56:78:9a:bc
PHY not connected!!
Link: 100baseTX Full Duplex
Hit any key to stop autoboot:  0
u-boot>

Вот теперь я понял, какой boot.bin имелся в виду!
Значит, мне нужно заменить u-boot. Но чем и как? У меня после сборки есть следующие файлы:

Код

-rwxr-xr-x 1 dimka dimka 316225 Июн  2 19:06 u-boot
-rwxr-xr-x 1 dimka dimka  95632 Июн  2 19:06 u-boot.bin
-rw-r--r-- 1 dimka dimka  81561 Июн  2 19:06 u-boot.map
-rwxr-xr-x 1 dimka dimka 286994 Июн  2 19:06 u-boot.srec

Кого-то из них надо записать во флэш вместо текущего загрузчика, но я не знаю адрес, по которому он располагается...

[AVR]

Кого-то из них надо записать во флэш вместо текущего загрузчика, но я не знаю адрес, по которому он располагается...

Не скажу какой файл точно, но вроде тот что под 100 килов...
U-Boot code: 21F00000 -> 21F1A294 - это 107156 байт, тогда ближе всего этот файл 95632 Июн 2 19:06 u-boot.bin

Адрес?.. Наверное это адрес самого первого байта флэша (по крайней мере у меня так на плате) U-Boot code: 21F00000 <-- может это и есть тот самый адрес флэша куда лить надо?..

но прежде чем заливать новый убут, убедитесь что сможете оживить плату старым убутом после возможно неудачных манипуляций, т.е. есть джамперы на плате которые могут перевести проц в загрузку по последовательному порту и т.д. ...

[dmitry-rf]

Нее.. 2100 0000 - это оперативка. Флэш мапится на 1000 0000.

Код

u-boot> md 10010000
10010000: 08088b1f 46b2f350 5f750300 746f6f62    ....P..F..u_boot
...

Похоже dch прав и u-boot начинается со вторых 64К.
Вот нашёл по поводу обновления u-boot:

Код

Updating U-Boot:
=> tftp 00100000 /home/karim/example-sys/images/u-boot.bin...
=> protect off 40000000 4003FFFF
=> erase 40000000 4003FFFF
=> cp.b 00100000 40000000 $(filesize)
=> setenv filesize
=> saveenv
=> reset

Как я понимаю, надо только адреса оперативки и флэша заменить на свои?

Хотя нет, тогда потрётся boot

Сообщение отредактировал dmitry-rf - Jun 3 2008, 10:03

[dmitry-rf]

А если залить uboot или u-boot.bin с помощью tftpboot в ОЗУ и запустить - ничего не происходит.

Код

u-boot> tftpboot 21000000 u-boot
eth: setting MAC address to 12:34:56:78:9a:bc
PHY not connected!!
Link: 100baseTX Full Duplex
TFTP from server 192.168.1.10; our IP address is 192.168.1.1
Filename 'u-boot'.
Load address: 0x21000000
Loading: invalid RARP header
##############################################################
done
Bytes transferred = 316225 (4d341 hex)
u-boot> go 21000000
## Starting application at 0x21000000 ...

[dmitry-rf]

Ковырял romboot для evm9200, выяснил, что он понимает только SPI флэш, а у меня - параллельный.
Начал ковырять boot (брал здесь).
Пытаюсь собрать:

Код

$ make
/opt/arm/bin/arm-linux-gcc -Os -fno-builtin -fomit-frame-pointer  -fno-strict-aliasing  -fno-common -mshort-load-bytes -msoft-float -D__arm__ -D__FLASHED__ -I. -c entry.S
cc1: error: invalid option `short-load-bytes'
make: *** [entry.o] Ошибка 1

Если удалить из Makefile упоминание -mshort-load-bytes, то получаем:

Код

$ make
/opt/arm/bin/arm-linux-gcc -Os -fno-builtin -fomit-frame-pointer  -fno-strict-aliasing  -fno-common  -msoft-float -D__arm__ -D__FLASHED__ -I. -c entry.S
/opt/arm/bin/arm-linux-gcc -Os -fno-builtin -fomit-frame-pointer  -fno-strict-aliasing  -fno-common  -msoft-float -D__arm__ -D__FLASHED__ -I. -c div0.c
/opt/arm/bin/arm-linux-gcc -Os -fno-builtin -fomit-frame-pointer  -fno-strict-aliasing  -fno-common  -msoft-float -D__arm__ -D__FLASHED__ -I. -c _udivsi3.S
/opt/arm/bin/arm-linux-gcc -Os -fno-builtin -fomit-frame-pointer  -fno-strict-aliasing  -fno-common  -msoft-float -D__arm__ -D__FLASHED__ -I. -c initboot.c
/opt/arm/bin/arm-linux-gcc -Os -fno-builtin -fomit-frame-pointer  -fno-strict-aliasing  -fno-common  -msoft-float -D__arm__ -D__FLASHED__ -I. -c crt0.S
/opt/arm/bin/arm-linux-gcc -Os -fno-builtin -fomit-frame-pointer  -fno-strict-aliasing  -fno-common  -msoft-float -D__arm__ -D__FLASHED__ -I. -c misc.c
/opt/arm/bin/arm-linux-gcc -Os -fno-builtin -fomit-frame-pointer  -fno-strict-aliasing  -fno-common  -msoft-float -D__arm__ -D__FLASHED__ -I. -c main.c
/opt/arm/bin/arm-linux-gcc -nostdlib -Tld.script -o boot entry.o div0.o _udivsi3.o initboot.o crt0.o misc.o main.o
/opt/arm/bin/../lib/gcc/arm-linux/3.4.6/../../../../arm-linux/bin/ld: error: no memory region specified for loadable section `.rodata.str1.4'
collect2: ld returned 1 exit status
make: *** [boot] Ошибка 1

Помогите разобраться с сборкой-прошивкой boot и u-boot, пожалуйста.

[dmitry-rf]

Выяснил, что параметр -mshort-load-bytes уже не актуален и его можно выкинуть. Вопрос со сборкой остался. Попробовал пересобрать loader.bin - не вышло:

Код

$ make
/opt/arm/bin/arm-linux-gcc -nostdlib -Tld.script -o loader entry.o div0.o _udivsi3.o _umodsi3.o init.o crt0.o main.o asm_isr.o jump.o lib_AT91RM9200.o
/opt/arm/bin/../lib/gcc/arm-linux/3.4.6/../../../../arm-linux/bin/ld: ERROR: crt0.o uses hardware FP, whereas loader uses software FP
/opt/arm/bin/../lib/gcc/arm-linux/3.4.6/../../../../arm-linux/bin/ld: failed to merge target specific data of file crt0.o
/opt/arm/bin/../lib/gcc/arm-linux/3.4.6/../../../../arm-linux/bin/ld: ERROR: main.o uses hardware FP, whereas loader uses software FP
/opt/arm/bin/../lib/gcc/arm-linux/3.4.6/../../../../arm-linux/bin/ld: failed to merge target specific data of file main.o
/opt/arm/bin/../lib/gcc/arm-linux/3.4.6/../../../../arm-linux/bin/ld: ERROR: asm_isr.o uses hardware FP, whereas loader uses software FP
/opt/arm/bin/../lib/gcc/arm-linux/3.4.6/../../../../arm-linux/bin/ld: failed to merge target specific data of file asm_isr.o
/opt/arm/bin/../lib/gcc/arm-linux/3.4.6/../../../../arm-linux/bin/ld: ERROR: jump.o uses hardware FP, whereas loader uses software FP
/opt/arm/bin/../lib/gcc/arm-linux/3.4.6/../../../../arm-linux/bin/ld: failed to merge target specific data of file jump.o
/opt/arm/bin/../lib/gcc/arm-linux/3.4.6/../../../../arm-linux/bin/ld: ERROR: lib_AT91RM9200.o uses hardware FP, whereas loader uses software FP
/opt/arm/bin/../lib/gcc/arm-linux/3.4.6/../../../../arm-linux/bin/ld: failed to merge target specific data of file lib_AT91RM9200.o
/opt/arm/bin/../lib/gcc/arm-linux/3.4.6/../../../../arm-linux/bin/ld: error: no memory region specified for loadable section `.rodata.str1.4'
collect2: ld returned 1 exit status
make: *** [loader] Ошибка 1

[RW9UAO]

х.з. u-boot у меня ни разу не собрался. а то что собралось - не работало толком. собирал по мануалу от heavi. в итоге от у-бута я отказался и гружу ядро и ФС по уарту.
атмеловский ромбут хорошо собирается. есть и с поддержкой SD карт, возможно тебе будет проще дописать в него свой кусок. ссылку на исходники ромбута версии 1.05 я выкладывал.

[dmitry-rf]

Спасибо, но дописать мне точно не будет проще, ибо в программировании я слабоват. А чем вы грузите ядро и ФС по уарту? Я нашёл loader.bin. Он может загрузить и запустить u-boot, но у меня ничего не вышло. Вроде, переконфигурял его под моё железо, но он не собирается
Атмеловский ромбут, как я понял, не поддерживает параллельную флэш, а в имеющемся железе использована именно она. Более того, в железке уже сейчас есть почти рабочий u-boot, который, если я правильно понял, не полностью инициализирует оперативку и нормально использовать можно только 32 Мб из 64.

[RW9UAO]

х.з. как оно с линуксом будет работать без у-бута. я по х-модему заливаю с помощью ромбута скомпонованный образ ядра и файловой системы QNX, пишу его в последовательную флэш. потом отдаю управление IPL, а он стартрапу.
короче, если сроки жмут - забей на верхние 32 мега =)

[dmitry-rf]

Ну с последовательной немного проще - атмелосвкий ромбут как раз на неё и рассчитан. А вот для параллельной мне что-то не найти нужной программки.

[dmitry-rf]

На счёт сборки loader.bin. Указанная выше ошибка

Код

ld: ERROR: crt0.o uses hardware FP, whereas loader uses software FP

Лечится добавлением -msoft-float в CFLAGS и последующими командами make clean && make

Ошибка

Код

ld: error: no memory region specified for loadable section `.rodata.str1.4'

Устраняется правкой ld.script
Было:

Код

*(.rodata)

Стало:

Код

*(.rodata)
*(.rodata.str1.4)

loader.bin собрался, но после загрузки через debug uart выкидывает в терминал мусор и молчит

Сообщение отредактировал dmitry-rf - Jun 9 2008, 09:40

[dmitry-rf]

Так не правильно. Вот правильный скрипт:

Код

MEMORY {
        ram    : ORIGIN = 0x200000, LENGTH = 0x3000
}

SECTIONS {
    .text : {
        _stext = .;
        *(.text)
        . = ALIGN(4);
        _etext = .;
    } > ram
    .data : {
        _sdata = .;
        *(.data)
                *(.rodata)
        *(.rodata.str1.4)
        *(.glue_7*)
        . = ALIGN(4);
        _edata = .;
    } > ram
    .bss : {
        _sbss = .;
        *(.bss)
        . = ALIGN(4);
        _ebss = .;
    } > ram
}

Теперь лоадер шлёт один нечитаемый символ в секудну. Видимо, это С. Надо где-то подправить частоту...

[dch]

А если залить uboot или u-boot.bin с помощью tftpboot в ОЗУ и запустить - ничего не происходит.

обычно запускают приложением командочкой bootm <адрес откуда брать приложение> , но для этого приложение должно быть обработано програмкой mkimage, которая дописывает заголовок, в котором указаны куда нужно откопировать приложение и куда передать управление. Наверное нужно посмотреть куда копирует u-boot.bin приложение и загрузить u-boot не в 21000000 а в другое место.

Updating U-Boot:
=> tftp 00100000 /home/karim/example-sys/images/u-boot.bin...
=> protect off 40000000 4003FFFF
=> erase 40000000 4003FFFF
=> cp.b 00100000 40000000 $(filesize)
=> setenv filesize
=> saveenv
=> reset

если у Вас параллельная флэш которая которая доступна по адресу 10000000, то прошивка u-boot.bin

tftp 21000000 u-boot.bin
protect off 10000000 1000FFFF
erase 10000000 1000FFFF
cp.b 21000000 10000000 FFFF

прошивка u-boot.bin

gzip u-boot.bin

на входе получится какойто файл, например, u-boot.bin.gz

tftp 21000000 u-boot.bin.gz
protect off 10010000 1001FFFF
erase 10010000 1001FFFF
cp.b 21000000 10010000 FFFF

Ковырял romboot для evm9200, выяснил, что он понимает только SPI флэш, а у меня - параллельный.

нет он понимает и параллельную, но не тот тип что у Вас. флэш у Вас AT49BV641670TU (8Мб) - у меня ее наверное не будет понимать u-boot, исходный текст надо посмотреть, что там есть. На моих платочках стоит 29LV160 обычно поддержка для нее есть

boot.bin u-boot у меня нормально компилируется
http://ucrouter.ru/download/arm-elf-tools-20030314.sh

опции для gcc в Makefile можно посмотреть

В качестве компортового загрузчика можно использовать:
http://ucrouter.ru/download/AT91RM9200-29lv160d.bin
http://ucrouter.ru/download/AT91RM9200-29lv160d-1.tgz

u-boot у меня ни разу не собрался

там по инструкции сначала свой кроскомпилятор собирается, но лучше использовать для u-boot кроскомпилятор от uclinux.org

Теперь лоадер шлёт один нечитаемый символ в секудну. Видимо, это С. Надо где-то подправить частоту...

нет не нужно, наверное, он грузится по x-модему во внутреннюю SRAM и сам настраивает все. Те у Вас должен быть джампер на платочки который позволяет ножку BMS либо на землю либо на питание посадить. В одном положении это обычная загрузка в другом работает внутренний загрузчик из ПЗУ. Но вообщето по руководству от производителя должно все собираться если это конечно не готовое изделие :-).

[dmitry-rf]

Дмитрий, спасибо за развёрнутый ответ. Выбор способа загрузки и процесс прошивки boot/u-boot во флэш понятны. Не понятно, как собрать рабочий загрузчик. В качестве отправной точки есть содержимое вот этого архива. В нём есть loader.bin и u-boot.bin. Они нормально заливаются через отладочный ком и запускаются. Если с помощью лоадера залить мой u-boot, то появляется надпись U-Boot downloaded successfully и ничего не происходит. Возможно, отличаются точки входа для версий от атмела и моей, но я не нашёл кода, который бы определял это. U-boot 1.1.1, собирал тулчейном от heavy.

Поставил ваш тулчейн. В скрипте есть ошибка: не хватает -n после tail в 39-й строке. Т. е. она должна выглядеть так: tail -n +${SKIP} ${SCRIPT} | gunzip | tar xvf -

u-boot не собирается:

Код

In file included from cfi_flash.c:48:
/home/dimka/arm/src/u-boot-1.1.1/include/asm/processor.h:52: parse error before `1'
/home/dimka/arm/src/u-boot-1.1.1/include/asm/processor.h:52: warning: no semicolon at end of struct or union
/home/dimka/arm/src/u-boot-1.1.1/include/asm/processor.h:54: parse error before `}'
/home/dimka/arm/src/u-boot-1.1.1/include/asm/processor.h:58: field `insn' has incomplete type
make[1]: *** [cfi_flash.o] Ошибка 1
make[1]: Leaving directory `/home/dimka/arm/src/u-boot-1.1.1/drivers'
make: *** [drivers/libdrivers.a] Ошибка 2

кусок include/asm/processor.h

Код

#include <asm/proc/processor.h>                    //48
#include <asm/types.h>

union debug_insn {
        u32     arm;                             //52
        u16     thumb;
};                                                  //54

struct debug_entry {
        u32                     address;
        union debug_insn        insn;                //58
};

struct debug_info {
        int                     nsaved;
        struct debug_entry      bp[2];
};

Моя основная цель сейчас - научиться собирать u-boot так, чтоб он хотя бы запускался. Потом буду разбираться с поддержкой железа.

Сообщение отредактировал dmitry-rf - Jun 16 2008, 14:23

[RW9UAO]

закоменти эти куски про дебаг и все скомпилируется.

[dmitry-rf]

закоменти эти куски про дебаг и все скомпилируется.

Спасибо, собрался. Но после заливки лоадером опять тишина

[dch]

Поставил ваш тулчейн. В скрипте есть ошибка: не хватает -n после tail в 39-й строке. Т. е. она должна выглядеть так: tail -n +${SKIP} ${SCRIPT} | gunzip | tar xvf -

Надо посмотреть вроде таких проблемм ранее не возникало да и ошибок не выдавалось, а Вы командочку
make RM9200_config либо чтото подобное даете перед компиляцией? Нужно чтобы u-boot настроился на платформу. boot.bin всегда должен чегото выдавать, минимально строчка типа uncompress u-boot там должна быть.

[dmitry-rf]

Надо посмотреть вроде таких проблемм ранее не возникало да и ошибок не выдавалось, а Вы командочку
make RM9200_config либо чтото подобное даете перед компиляцией? Нужно чтобы u-boot настроился на платформу. boot.bin всегда должен чегото выдавать, минимально строчка типа uncompress u-boot там должна быть.

Да, конфигурацию под платформу делал. На днях попробую пройти весь процесс еще раз с нуля и описать, что получилось.

[dch]

Да, конфигурацию под платформу делал. На днях попробую пройти весь процесс еще раз с нуля и описать, что получилось.

в принципе сейчас я буду проверять все под новый дистрибутив uClinux-dist-20070130 - но я думаю что там должно работать без изменений

В принципе вот еще есть инструкция - проблемм тоже особенных не возникало :-)
http://heavy-online.ru/arm-linux/

[dmitry-rf]

Эту инструкцию я знаю, в своё время сильно помогла

[dch]

u-boot по ней не смогли откомпилировать?

В принципе у меня на страничке загрузки два комплекта лежало кросс средств:
http://ucrouter.ru/download/arm-elf-binutils-2.11-3.i386.rpm
http://ucrouter.ru/download/arm-elf-gcc-2.95.3-2.i386.rpm

И взятый с сайта uclinux.org:
http://ucrouter.ru/download/arm-elf-tools-20030314.sh

Патчи и инструкции для u-boot-1.1.1:
http://ucrouter.ru/download/u-boot-EVM9200-patch.tgz

Первыми набором кросс средств точно собиралось, вторым помоему тоже. Но я традиционно собирал u-boot первым. Если не собирается - значит на соурсефорге поменялся u-boot-1.1.1 - чудес то особенных не бывает. Никаких ошибок компиляции быть не должно.

[dmitry-rf]

Heavy собирал u-boot для последовательной dataflash. У меня на плате стоит параллельная AT49BV641670TI. Там нужны доп. патчи. Время от времени общаюсь с разработчиком этой железки. Помощь от него есть, но результата у меня пока нет.
На данный момент временно отложил проблему в сторону, вернусь в середине-конце месяца.

[dmitry-rf]

Прошу прощения за поднятие старой темы, но, возможно, кому-то моя информация окажется полезной. Проблема с ОЗУ была вызвана неправильный её настройкой первичным загрузчиком boot.bin - он указывал 32 Мб. Пересобрать его из исходников так и не удалось. Зато методом тыка был найден нужный адрес и исправлена константа. Занимался этим другой человек, так что деталей процесса я не знаю, но в результате все 64 Мб стали доступны.

[neptun8]

Умоляю помогите! Ситуация один в один в один только у меня немного другой прибор вот:



Вставил debuger порт туда, соеденился через hyperterminal
пишет все точно так же - очень прошу скажите что и как надо изменить чтобы эта шайтан машина заработала
сайт разработчиков заблокирован за неуплату - что делать ума не приложу ( сам не программист и знакомых программистов нету)

[dmitry-rf]

В архиве загрузчики (x-modem и boot) с поддержкой 64 Мб ОЗУ.

Прикрепленные файлы

 Desktop.7z ( 7.24 килобайт ) Кол-во скачиваний: 19

 

[savant]

Умоляю помогите! Ситуация один в один в один только у меня немного другой прибор вот:

С загрузчиком суть такова - в нём неправильно инициализируется sdram контроллер, точнее инициализация банок памяти происходит не в соответствии с реально установленными, а в соответствие с теми что стоят на devkit на атмеловских отладочных бордах, а там стоит 32 мегабайта памяти.

Сообщение отредактировал IgorKossak - Dec 14 2012, 20:40

Причина редактирования: избыточное цитирование