AM1705 первый запуск, UBL, UART Опции

[Славка]

Добрый день!
Пытаюсь запустить AM1705 уже который день. Плата и схема моего же производства.
Скачал OMAP-L137_FlashAndBootUtils_2_20. Откомпилировал благополучно.
Установил частоту 300Mhz, тайминги памяти, частоту uartа. (device.c, device_uart.c)
Установил strapы в BOOTMODE UART2.
При старте выдает BOOTME.
Пытаюсь стереть флешку командой:
sfh_OMAP-L137.exe -v -p COM1 -targetType AM1707 -erase -flashType SPI_MEM
Прошивка благополучно передается по UART и застревает на

Код

(AIS Parse): AIS complete. Jump to address 0x80000000.
(AIS Parse): Waiting for DONE...
(AIS Parse): Boot completed successfully.

Waiting for SFT on the OMAP-L137...

Осциллографом не видно SDRAM clk - делаю вывод что до инициализации памяти дело не доходит, застревает раньше.
Питание процессора подаю вручную тумблерами (сначала 1.2 потом 3.3).
Не подаю питание 1.2 и 1.8 на USB так как не буду его использовать. Думал из-за этого не работает. Пробовал в инициализации PSC не включать USB.

Код

void DEVICE_PSCInit()
{
...
//  for( i = 1; i <= 13; i++ )
  for( i = 2; i <= 13; i++ )
    PSC1->MDCTL[i] = (PSC1->MDCTL[i] & 0xFFFFFFE0) | PSC_ENABLE;
...
}

Не помогает.
Есть jtag SAU510-USB но его подключить так и не смог. CCS4.1.2 ругается и не конектится к процессору. (не завел на плате RTCK, может из за этого)
Посоветуйте хотя бы в каком направлении двигаться с этим черным ящиком, который только BOOTME выдавать может.

Сообщение отредактировал Славка - Oct 12 2011, 10:09

[aaarrr]

У EMIF'а настроек как таковых минимум - тайминги, разрядность шины, возможность прогнать 1/4bit ECC.

U-boot может правильно идентифицировать память, но это отнюдь не значит, что он будет корректно с ней работать. А память в вашем случае несколько экзотическая.

[am1808]

приветствую всех!

у кого нибудь была проблема с запуском ядра без использования ubl?

я гружу ядро через rs232 по протоколу kermit

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

о своей проблеме написал на http://e2e.ti.com/support/embedded/linux/f...579.aspx#560785

подскажите пожалуйста куда копать и в чем может быть проблема?

[sasamy]

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

1 Включите в ядре поддержку early printk и смотрите лог загрузки. (Kernel hacking --->[*] Kernel debugging) - если есть поддержка early printk для этого процессора проблему с ID вы сразу обнаружите если она есть.
2 Проверьте - включена ли поддержка консоли для последовательного порта
3 Проверьте - в какой порт по умолчанию в ядре сконфигуирован вывод консоли.
4 память можно протестировать в u-boot - там есть простейший mtest.

К сожалению точные указания не могу дать по ядру - у TI они кастомные для каждого процессора.



Сообщение отредактировал sasamy - Dec 23 2011, 22:46

[am1808]

1 Включите в ядре поддержку early printk и смотрите лог загрузки. (Kernel hacking --->[*] Kernel debugging) - если есть поддержка early printk для этого процессора проблему с ID вы сразу обнаружите если она есть.
2 Проверьте - включена ли поддержка консоли для последовательного порта
3 Проверьте - в какой порт по умолчанию в ядре сконфигуирован вывод консоли.
4 память можно протестировать в u-boot - там есть простейший mtest.

К сожалению точные указания не могу дать по ядру - у TI они кастомные для каждого процессора.

спасибо.
пункты 1,3,4 я проделывал, не помогло.
на счет поддержки консоли - попробую еще раз посмотреть, хотя по дефолту скорее всего с этим в порядке

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

[sasamy]

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

Вы лучше лог загрузки от начала и до остановки покажите и выложите свой конфиг ядра. Еще я не помню - это не у вас 16М вместо 64M EVM распаяно ? при распаковке ядро может банально само себя затереть если имидж неправильно в RAM разместить.

[am1808]

Вы лучше лог загрузки от начала и до остановки покажите и выложите свой конфиг ядра. Еще я не помню - это не у вас 16М вместо 64M EVM распаяно ? при распаковке ядро может банально само себя затереть если имидж неправильно в RAM разместить.

нет, у меня на борде 32 MB оперативки.
конфиг ядра отличается только от дефолтного включением early_printk() и отключением NET я ядре для быстроты сборки и загрузки по терминалу ядра в плату (хотя и пробовал с поддержкой сети, результат тот же)

вот лог

U-Boot > loadb
## Ready for binary (kermit) download to 0xC0700000 at 115200 bps...
## Total Size = 0x0016c1f4 = 1491444 Bytes
## Start Addr = 0xC0700000
U-Boot > bootm
## Booting kernel from Legacy Image at c0700000 ...
Image Name: Linux-2.6.33-rc4
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1491380 Bytes = 1.4 MB
Load Address: c0008000
Entry Point: c0008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.


еще хотел добавить, что я не использую ни initrd, ни rootfs.
тот же самый юбут и это же ядро через UartBootHost гружу на EVM1707, ядро запускается, лог загрузки ядра вываливается на терминал.

и для EVM1707 и для своей платы в параметре bootargs установлено mem=32M, хотя на EVM1707 фактически стоит 64 MB

Сообщение отредактировал am1808 - Dec 24 2011, 08:42

[sasamy]

нет, у меня на борде 32 MB оперативки.
конфиг ядра отличается только от дефолтного включением early_printk() и отключением NET я ядре для быстроты сборки и загрузки по терминалу ядра в плату (хотя и пробовал с поддержкой сети, результат тот же)

Дайте прямой линк чтобы я мог скачать ваше ядро (или ссылку на сайт TI откуда скачивали). И какой там defconfig ? при первичной конфигурации вы там делали make ARCH=arm какой-то.defconfig

Сообщение отредактировал sasamy - Dec 24 2011, 08:42

[am1808]

Дайте прямой линк чтобы я мог скачать ваше ядро (или ссылку на сайт TI откуда скачивали). И какой там defconfig ? при первичной конфигурации вы там делали make ARCH=arm какой-то.defconfig

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

да, конфигурирую ядро под определенную конфигурацию вот так:

make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- clean
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- da830_omapl137_defconfig
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- menuconfig
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- uImage

ядро: linux-03.20.00.12 из состава DaVinci-PSP-SDK-03.20.00.12, скаченного с офиц. сайта TI для AM1707

Сообщение отредактировал am1808 - Dec 24 2011, 09:29

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

 my_config_kernel.zip ( 9.03 килобайт ) Кол-во скачиваний: 12
 uImage.zip ( 1.42 мегабайт ) Кол-во скачиваний: 9

 

[sasamy]

ядро: linux-03.20.00.12 из состава DaVinci-PSP-SDK-03.20.00.12, скаченного с офиц. сайта TI для AM1707

Скачал, посмотрел - с uart вроде все в порядке, из подозрительного - у вас сконфигурировано под am1707, у вас как я понял am1705 (нет LCD) а поддержка включена для LCD вместо NAND

[am1808]

Скачал, посмотрел - с uart вроде все в порядке, из подозрительного - у вас сконфигурировано под am1707, у вас как я понял am1705 (нет LCD) а поддержка включена для LCD вместо NAND

спасибо,

да, я пробовал и с выбирать нанд вместо LCD, но это тоже не влияет

[sasamy]

да, я пробовал и с выбирать нанд вместо LCD, но это тоже не влияет

Не пробовали отключать кеши ? это так - как жест отчаяния

[am1808]

Не пробовали отключать кеши ? это так - как жест отчаяния

нет, не пробовал.
как то можно вывести буффер до start_kernel() и инициализации консоли?

[sasamy]

как то можно вывести буффер до start_kernel() и инициализации консоли?

Поддержка вывода отладочной информации до инициализации консоли для davinci есть
arch/arm/mach-davinci/include/mach/debug-macro.S

так что ничего не мешает ее использовать, странно что вообще все молчит после распаковщика..

[sasamy]

Я забыл сказать - вы добавили в параметры загрузки ядра в u-boot ?

bootargs console=ttyS2,115200n8 earlyprintk

[am1808]

Я забыл сказать - вы добавили в параметры загрузки ядра в u-boot ?

bootargs console=ttyS2,115200n8 earlyprintk

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

[sasamy]

даже не знал, и нигде не написано про это

Да это я прошляпил - забыл сказать. Кстати напрямую в порт выводить символы есть ф-ции printascii, printch, printhex. Нпример в early_write

Код

static void early_write(const char *s, unsigned n)
{
        while (n-- > 0) {
                if (*s == '\n')
                        printch('\r');
                printch(*s);
                s++;
        }
}

arch/arm/kernel/debug.S

UPD Еще - чтобы проверить работоспособность earlyprintk можно намеренно неправильный MACH_ID передать из u-boot - если до загрузки ядра дело доходит и earlyprintk работает - должны увидеть как начальный загрузчик ядра заругается на неправильный MACH_ID. Вернее это даже раньше регистрации отладочной консоли сработает - через ф-ции printch пр. из arch/arm/kernel/debug.S

Сообщение отредактировал sasamy - Dec 24 2011, 16:06

[am1808]

sasamy,
спасибо преогромное, как раз разбираю эти функции.
machid я намеренно передам другой из u-boot, в нем же выставлю правильные параметры для early_printk().
результат к сожалению смогу сказать только в понедельник.
скажите пожалуйста, до какого момента я могу использовать функции early_write(), printascii(), printch(), printhex()?

и еще такой момент,
я не использую ubl, при портировании u-boot были проблемы с выводом на консоль с его стороны, связанные с неправильной работой UART, помогла запись 0 в регистр MDR UART ( 16× over-sampling ). в драйверах ядра этот регистр никак не используется. Как то можно предположить, что проблемы с ядром связаны с регистром UART MDR?

[sasamy]

скажите пожалуйста, до какого момента я могу использовать функции early_write(), printascii(), printch(), printhex()?

Регистры периферии в kernel space всегда мапятся на определенные виртуальные адреса, в макросе проверяется, включен ли MMU

Код

                .macro addruart, rx
                mrc     p15, 0, \rx, c1, c0
                tst     \rx, #1                 @ MMU enabled?
                moveq   \rx, #0x01000000        @ physical base address
                movne   \rx, #0xfe000000        @ virtual base

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

запись 0 в регистр MDR UART ( 16Ч over-sampling ). в драйверах ядра этот регистр никак не используется. Как то можно предположить, что проблемы с ядром связаны с регистром UART MDR?

До инита UART-ов порт остается с настройками кототрые сделаны в u-boot так что до этого момента все равно должно что-то валиться в порт нормально, а там видно будет - проверьте сначала как работает early printk.

Сообщение отредактировал sasamy - Dec 24 2011, 16:56

[am1808]

спасибо огромное,
в понедельник проверю и отпишусь

[sasamy]

в понедельник проверю и отпишусь

Есть еще один момент, начальный загрузчик может уходить в бесконечный цикл если включен вывод начальной отладки, в этих местах

Код

                .macro  waituart,rd,rx
#ifdef FLOW_CONTROL
1001:           ldr     \rd, [\rx, #UART_MSR << UART_SHIFT]
                tst     \rd, #UART_MSR_CTS
                beq     1001b
#endif

Код

.macro  busyuart,rd,rx
1002:           ldr     \rd, [\rx, #UART_LSR << UART_SHIFT]
                and     \rd, \rd, #UART_LSR_TEMT | UART_LSR_THRE
                teq     \rd, #UART_LSR_TEMT | UART_LSR_THRE
                bne     1002b
                .endm

Так что имейте это ввиду. Например я бы вообще временно принудительно убрал управление потоком
#undef FLOW_CONTROL

Сообщение отредактировал sasamy - Dec 24 2011, 17:51

[am1808]

ага, понял, спасибо.


а где лучше и рекомендательнее убрать FLOW_CONTROL ?
и еще вот не совсем понятно, в файле arch/arm/boot/compressed/head.S
есть по всей видимости отладка, которая спрятана под #ifdef DEBUG

никак не могу понять, где он определен, то ли через gcc передается, то ли где то статически забит или нет.
мне нужно задефайнить DEBUG или же нет? и где это лучше сделать?

и еще вот такой вопрос, как то можно включить фичу при сборке ядра, чтобы посмотреть на исходный модуль(файл) после препроцессора, например, через опцию -E gcc?

[sasamy]

а где лучше и рекомендательнее убрать FLOW_CONTROL ?

Прямо перед проверкой

#undef FLOW_CONTROL
#ifdef FLOW_CONTROL

и еще вот такой вопрос, как то можно включить фичу при сборке ядра, чтобы посмотреть на исходный модуль(файл) после препроцессора, например, через опцию -E gcc?

Для файлов С совсем просто, например для arch/arm/kernel/dma.с
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- arch/arm/kernel/dma.i

Для ассемблера можно объектный файл дизассемблировать, например
arm-none-linux-gnueabi-objdump -d arch/arm/kernel/debug.o

[am1808]

Прямо перед проверкой

#undef FLOW_CONTROL
#ifdef FLOW_CONTROL

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

Для файлов С совсем просто, например для arch/arm/kernel/dma.с
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- arch/arm/kernel/dma.i

Для ассемблера можно объектный файл дизассемблировать, например
arm-none-linux-gnueabi-objdump -d arch/arm/kernel/debug.o

ага, ясно.
я так понимаю, в первом случае для целей с расширением i выполняется какая то шаблонная цель для препроцессинга?

еще раз спасибо большое!

[sasamy]

я так понимаю, в первом случае для целей с расширением i выполняется какая то шаблонная цель для препроцессинга?

да - это такая отладочная "фича" в ядре, то же самое можно сделать чтобы посмотреть что сгенерировал компилятор
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- arch/arm/kernel/compat.s

[am1808]

итак, earlyprintk выручило.

ядро запускалось, и зависало вот где:

Код

U-Boot >

U-Boot > printenv

bootdelay=5

baudrate=115200

bootfile="uImage"

ethaddr=00:16:76:4e:64:da

bootcmd=bootm 0xC0700000

bootargs=console=ttyS2,115200n8 earlyprintk mem=32M

stdin=serial

stdout=serial

stderr=serial

ver=U-Boot 2009.11 (Dec 09 2011 - 17:49:53)



Environment size: 234/16380 bytes

U-Boot > loadb

## Ready for binary (kermit) download to 0xC0700000 at 115200 bps...

## Total Size      = 0x001eb588 = 2012552 Bytes

## Start Addr      = 0xC0700000

U-Boot > bootm

## Booting kernel from Legacy Image at c0700000 ...

   Image Name:   Linux-2.6.33-rc4

   Image Type:   ARM Linux Kernel Image (uncompressed)

   Data Size:    2012488 Bytes =  1.9 MB

   Load Address: c0008000

   Entry Point:  c0008000

   Verifying Checksum ... OK

   Loading Kernel Image ... OK

OK



Starting kernel ...



Uncompressing Linux... done, booting the kernel.

Linux version 2.6.33-rc4 (xxx@ubuntu) (gcc version 4.3.3 (Sourcery G++ Lite 20

09q1-203) ) #2 PREEMPT Fri Dec 23 16:24:34 MSK 2011

CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177

CPU: VIVT data cache, VIVT instruction cache

Machine: DaVinci DA830/OMAP-L137/AM17xx EVM

Memory policy: ECC disabled, Data cache writethrough

DaVinci da830/omap-l137 rev2.0 variant 0x9

Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 8128

Kernel command line: console=ttyS2,115200n8 earlyprintk mem=32M

bootconsole [earlycon0] enabled

PID hash table entries: 128 (order: -3, 512 bytes)

Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)

Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)

Memory: 32MB = 32MB total

Memory: 28268KB available (3736K code, 297K data, 140K init, 0K highmem)

SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1

Hierarchical RCU implementation.

NR_IRQS:245

Console: colour dummy device 80x30

Calibrating delay loop...

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

Но вот что интересно,
скачал последнюю версию ядра с kernel.org
собрал его с теми же опциями и все удачно!
ну плюс тут я грузил ФС через NFS, но ФС не влияет ни на что(я о проблеме выше)

вот лог:

Код

U-Boot > loadb

## Ready for binary (kermit) download to 0xC0700000 at 115200 bps...

## Total Size      = 0x001b9f80 = 1810304 Bytes

## Start Addr      = 0xC0700000

U-Boot > bootm

## Booting kernel from Legacy Image at c0700000 ...

   Image Name:   Linux-3.1.6

   Image Type:   ARM Linux Kernel Image (uncompressed)

   Data Size:    1810240 Bytes =  1.7 MB

   Load Address: c0008000

   Entry Point:  c0008000

   Verifying Checksum ... OK

   Loading Kernel Image ... OK

OK

mem.start: c0000000

mem.size: 2000000 bytes 32 MB



Starting kernel ...



debug: jump to c0008000 address

debug: start boot params address: c0000100

debug: data

debug: machID 1781

Uncompressing Linux... done, booting the kernel.

Linux version 3.1.6 (xxx@ubuntu) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-

203) ) #5 PREEMPT Mon Dec 26 15:22:34 MSK 2011

CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177

CPU: VIVT data cache, VIVT instruction cache

Machine: DaVinci DA830/OMAP-L137/AM17x EVM

bootconsole [earlycon0] enabled

Memory policy: ECC disabled, Data cache writethrough

DaVinci da830/omap-l137 rev2.0 variant 0x9

Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 8128

Kernel command line: console=ttyS2,115200n8 mem=32M noinitrd rw earlyprintk ip=1

92.168.2.144:192.168.2.87:192.168.0.1:255.255.240.0:uspd:eth0:bootp root=/dev/nf

s nfsroot=192.168.2.87:/home/xxx/Desktop/sdk_1_10_00_01/filesys,nolock

PID hash table entries: 128 (order: -3, 512 bytes)

Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)

Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)

Memory: 32MB = 32MB total

Memory: 28808k/28808k available, 3960k reserved, 0K highmem

Virtual kernel memory layout:

    vector  : 0xffff0000 - 0xffff1000   (   4 kB)

    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)

    DMA     : 0xff000000 - 0xffe00000   (  14 MB)

    vmalloc : 0xc2800000 - 0xfea00000   ( 962 MB)

    lowmem  : 0xc0000000 - 0xc2000000   (  32 MB)

    modules : 0xbf000000 - 0xc0000000   (  16 MB)

      .text : 0xc0008000 - 0xc032389c   (3183 kB)

      .init : 0xc0324000 - 0xc0346000   ( 136 kB)

      .data : 0xc0346000 - 0xc0365e60   ( 128 kB)

       .bss : 0xc0365e84 - 0xc038c24c   ( 153 kB)

SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1

Preemptible hierarchical RCU implementation.

NR_IRQS:245

Console: colour dummy device 80x30

Calibrating delay loop... 148.88 BogoMIPS (lpj=744448)

pid_max: default: 32768 minimum: 301

Mount-cache hash table entries: 512

CPU: Testing write buffer coherency: ok

DaVinci: 128 gpio irqs

print_constraints: dummy:

NET: Registered protocol family 16

bio: create slab <bio-0> at 0

Switching to clocksource timer0_0

Switched to NOHz mode on CPU #0

NET: Registered protocol family 2

IP route cache hash table entries: 1024 (order: 0, 4096 bytes)

TCP established hash table entries: 1024 (order: 1, 8192 bytes)

TCP bind hash table entries: 1024 (order: 0, 4096 bytes)

TCP: Hash tables configured (established 1024 bind 1024)

TCP reno registered

UDP hash table entries: 256 (order: 0, 4096 bytes)

UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)

NET: Registered protocol family 1

RPC: Registered named UNIX socket transport module.

RPC: Registered udp transport module.

RPC: Registered tcp transport module.

RPC: Registered tcp NFSv4.1 backchannel transport module.

msgmni has been set to 56

io scheduler noop registered (default)

start plist test

end plist test

Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled

serial8250.0: ttyS0 at MMIO 0x1c42000 (irq = 25) is a 16550A

serial8250.0: ttyS1 at MMIO 0x1d0c000 (irq = 53) is a 16550A

serial8250.0: ttyS2 at MMIO 0x1d0d000 (irq = 61) is a 16550A

console [ttyS2] enabled, bootconsole disabled

console [ttyS2] enabled, bootconsole disabled

brd: module loaded

davinci_mdio davinci_mdio.0: davinci mdio revision 1.5

davinci_mdio davinci_mdio.0: detected phy mask fffffff1

davinci_mdio.0: probed

davinci_mdio davinci_mdio.0: phy[1]: device 0:01, driver unknown

davinci_mdio davinci_mdio.0: phy[2]: device 0:02, driver unknown

davinci_mdio davinci_mdio.0: phy[3]: device 0:03, driver unknown

rtc-test rtc-test.0: rtc core: registered test as rtc0

rtc-test rtc-test.1: rtc core: registered test as rtc1

i2c /dev entries driver

cpuidle: using governor ladder

cpuidle: using governor menu

TCP cubic registered

NET: Registered protocol family 17

davinci_emac davinci_emac.1: using random MAC addr: 5e:8e:3f:87:58:15

console [netcon0] enabled

netconsole: network logging started

rtc-test rtc-test.0: setting system clock to 1970-01-01 00:00:02 UTC (2)

net eth0: no phy, defaulting to 100/full

IP-Config: Complete:

     device=eth0, addr=192.168.2.144, mask=255.255.240.0, gw=192.168.0.1,

     host=xxx, domain=, nis-domain=(none),

     bootserver=192.168.2.87, rootserver=192.168.2.87, rootpath=

VFS: Mounted root (nfs filesystem) on device 0:12.

Freeing init memory: 136K

в чем причина такого?
и по каким причинам калибровка не происходит?

[sasamy]

Calibrating delay loop...

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

pr_info("Calibrating delay loop... ");
while ((loops_per_jiffy <<= 1) != 0) {
/* wait for "start of" clock tick */
ticks = jiffies;
while (ticks == jiffies)
/* nothing */;

А вот почему не работает - это другой вопрос. Сравните инициализацию таймеров в старом и новом ядре, в старом она тут
arch/arm/mach-davinci/time.c
я не знаком с этим процессором, тут ничего не подскажу. Еще на рабочем ядре погоняйте на всякий случай мемтестер нормальный - то что в убуте не находит ошибок не дает 100% гарантии, там он слишком примитивный.

Сообщение отредактировал sasamy - Dec 26 2011, 19:17

[am1808]

Еще на рабочем ядра погоняйте на всякий случай мемтестер нормальный - то что в убуте не находит ошибок не дает 100% гарантии, там он слишком примитивный.

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

еще раз спасибо

Сообщение отредактировал am1808 - Dec 26 2011, 19:24