Перейти к содержанию
    

Проблема с Linux на AT91RM9200

Есть устройство на базе модуля 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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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/

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

После множества экспериментов подобрал более-менее рабочую конфигурацию:

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)

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если сказать ядру mem=32M и не останавливать демонов, то в процессе загрузки файла оперативы остаётся 4-6М, но ничего не падает. Видимо, проблема в старших 32 мегабайтах. Теперь осталось выяснить причину...

Может дело быть в загрузчике, собранном с #define PHYS_SDRAM_SIZE 0x2000000 /* 32 megs */ ? Или ядро заново инициализирует всё железо?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

в 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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Т.е. всё же загрузчик должен конфигурять память? Я со встраиваемыми системами работаю совсем недавно и очень многого еще не знаю.

Вот есть такая строка в файле "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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...