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

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

 

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

post-41858-1324730271_thumb.png

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


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

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

post-41858-1324730271_thumb.png

нет, не пробовал.

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

 

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


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

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

 

Поддержка вывода отладочной информации до инициализации консоли для davinci есть

arch/arm/mach-davinci/include/mach/debug-macro.S

 

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

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


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

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

 

bootargs console=ttyS2,115200n8 earlyprintk

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


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

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

 

bootargs console=ttyS2,115200n8 earlyprintk

нет, такой аргумент не добавлял.

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

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


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

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

 

Да это я прошляпил - забыл сказать. Кстати напрямую в порт выводить символы есть ф-ции 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

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


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

sasamy,

спасибо преогромное, как раз разбираю эти функции.

machid я намеренно передам другой из u-boot, в нем же выставлю правильные параметры для early_printk().

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

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

 

и еще такой момент,

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

 

 

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


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

скажите пожалуйста, до какого момента я могу использовать функции 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

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


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

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

 

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

                .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

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


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

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

 

 

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

и еще вот не совсем понятно, в файле arch/arm/boot/compressed/head.S

есть по всей видимости отладка, которая спрятана под #ifdef DEBUG

 

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

мне нужно задефайнить DEBUG или же нет? и где это лучше сделать?

 

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

 

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


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

а где лучше и рекомендательнее убрать 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

 

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


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

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

 

#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 выполняется какая то шаблонная цель для препроцессинга?

 

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

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


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

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

 

да - это такая отладочная "фича" в ядре, то же самое можно сделать чтобы посмотреть что сгенерировал компилятор

make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- arch/arm/kernel/compat.s

 

 

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


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

итак, 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

 

в чем причина такого?

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

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


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

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

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

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

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

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

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

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

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