Jump to content

    

vv40in

Участник
  • Content Count

    8
  • Joined

  • Last visited

Posts posted by vv40in


  1. а кто сказал что найденный диск именно hdc1, а не скажем, hde1 или sdb4 ?

    1)как видно из лога - это 3ий диск, значт "с" (а не "е" или "а").

    2)и это ide, а не sata. там стоИт преобразователь SATA-PATA. да и пробовал я ужЕ все варианты.

     

     

     

    вставил еще пару сообщений в лог.

     

    try_name: sys_open failed /sys/block/hdc1/dev

    try_name: sys_open failed /sys/block/hdc/dev

    (try_name это в init/do_mounts.c)

     

    теперь вообще не понимаю ничего. значит диск не замонтирован в dev? да?

    ну, правильно. так, а какой же диск замонтирован (если замонтирован)? как это определить?

    :help:

  2. всем доброго здоровья!

     

    На этапе инициализации (в цепочке initcalls) диск видится в PIO режиме (identify device читается отлично).

     

    А на завершающей стадии загрузки функция kobj_lookup вызываемая из

    mount_root(в конечном счете) не находит устройства соответствующего "/dev/hdc1".

    но при инициализации диска никаких kobj_map и не создается.

    в чем же дело? как всё-таки загрузиться с диска?

     

    PS.

    У меня sparc32;Linux2.6; образ загружаю своим bios-ом.

    использую root=/dev/hdc1 т.к. (см лог: порт обнаруживает только 3-ий диск)

     

    PSS.

    вот такой вот лог.

     

    sil_init_once SIL(3114)

    ...

    ata3 port frozen

    ENTER

    about to softreset, devmask=1

    ata3: bus reset via SRST

    found ATA device by sig

    EXIT, classes[0]=1 [1]=0

    ENTER

    <6>ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310)

    EXIT

    ata3 port thawed

    ENTER

    ata3: cmd 0xEC

    ata3: protocol 2 task_state 2 (dev_stat 0x58)

    ata_pio_sect data read

    ata_data_xfer® len 200

    ata3: protocol 2 task_state 3 (dev_stat 0x50)

    ata3: dev 0 command complete, drv_stat 0x50

    ENTER

    flush #1

    <6><6>ata3.00: ATA-6: ST940813AM, 5.03, max UDMA/100

    <6>ata3.00: 78140160 sectors, multi 0: LBA48

    <6>ata3.00: applying bridge limits

    set features - xfer mode

    ata_exe_int_sg n 0

    ata3: cmd 0xEF

    ata3: protocol 1 task_state 3 (dev_stat 0x50)

    ata3: dev 0 command complete, drv_stat 0x50

    ENTER

    flush #1

    EXIT, err_mask=0

    ata_exe_int_sg n 1

    ata3: cmd 0xEC

    ata_pio_task f035a28c

    ata3: protocol 2 task_state 2 (dev_stat 0x58)

    ata_pio_sect data read

    ata_data_xfer® len 200

    ata3: protocol 2 task_state 3 (dev_stat 0x50)

    ata3: dev 0 command complete, drv_stat 0x50

    ENTER

    flush #1

    <6><6>ata3.00: ATA-6: ST940813AM, 5.03, max UDMA/100

    <6>ata3.00: 78140160 sectors, multi 0: LBA48

    xfer_shift=12, xfer_mode=0x45

    <6>ata3.00: configured for UDMA/100

    EXIT, rc=0

    EXIT

    DEV: registering device: ID = 'host3'

    CLASS: registering class device: ID = 'host3'

    class_uevent - name = host3

    port EH scheduled

    ENTER

    ENTER

    flush #1

    ENTER

    ENTER

    ata4 port frozen

    ENTER

    EXIT, classes[0]=5 [1]=0

    ENTER

    <6>ata4: SATA link down (SStatus 0 SControl 310)

    EXIT, no device

    ata4 port thawed

    ENTER

    EXIT, rc=0

    EXIT

    host probe begin

    DEV: registering device: ID = 'target2:0:0'

    DEV: registering device: ID = '2:0:0:0'

    bus scsi: add device 2:0:0:0

    CLASS: registering class device: ID = '2:0:0:0'

    class_uevent - name = 2:0:0:0

    ata_dev_add OK

    /sil_init_once SIL(3114) OK

    bound device '0000:00:12.0' to driver 'sata_sil'

    pci: Bound Device 0000:00:12.0 to Driver sata_sil

  3. sparcv8.pdf (p.46):

    :help:

    Alignment Restrictions:

     

    Halfword accesses must be aligned on a 2-byte boundary, word accesses (which include instruction fetches) must be aligned on a 4-byte boundary, and doubleword accesses must be aligned on an 8-byte boundary. An improperly aligned address causes a load or store instruction to generate a mem_address_not_aligned trap.

     

    то, о чем говорится ниже - найдено в ядре Linux!

     

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

     

    даже если аллокатор выделит память с указателем кратным 8, то при копировании такой структуры в др.область, которая не выровнена по 8, при обращении к переменной опять же произойдет трап!

     

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

    (да и вообще не знаю как писать обработчики tarp-ов :help: )

     

    и я уверен, что 64-битная проблема встретится и дальше.

    спаркологи! поможите чем можете! что мне делать? :help:

    как добиться загрузки ядра?

  4. :tort: :santa2: :tort:

     

    УРА!!! заработало!!!

     

    вот что дал мне objdump.exe -x:

     

    Idx Name Size VMA LMA File off Algn

    1 .data 00000120 40000000 00018700 000187a0 2**3

     

    я сделал в ld-скрипте : > ram AT > rom (см ниже):

     

    .data :

    {

    ....

    } > ram AT > rom

     

    всем спасиба!!! :tort: :beer:

    теперь только осталось проверить - будет ли всё это работать ?

  5. большое спасибо за ответ!

     

    И вам!

     

    Чтобы понять это нужно обладать способностью к телепатии. К сожалению я ею не владею :).

    Итак, попробую догадаться.

    Вы имеете пример (для какого процессора?), без использования ОС, на С, предназначенный для загрузки в ОЗУ. И хотите перекомпилировать его для флеш и прошить.

    Я угадал?

    Потому как в Вашем вопросе мало конкретной информации придется начать издалека.

    1. Компилятор (кстати какой? предполагаю gcc) из каждого *.c файла сделает *.o файл.

    2. Линкер (предполагаю ld) возмет эти *.o файлы и, в соответствии со скриптом, разместит их содержимое в памяти. Получим *.elf файл.

    3. objcopy возмет этот *.elf файл, и перепишет секции .text (собственно код) и .data (инициализируемые переменные) в другой файл - *.bin. Этот файл является копией всего адресного пространства процессора. Если у Вас ARM то это 4G. Естественно, если Ваша программа "умещается" в 1G то размер будет 1G.

    Естественно Вам это не подходит :).

    В таком случае нужно

    1. Переписать скрипт линкера так, чтобы секция .data в выходном бинарике размещалась сразу за секцией .text.

    2. Написать в стартап файле - это асм - кусочек, который при каждом включении питания перенесет секцию .data из флеш в ОЗУ, на то место где ее ожидает программа.

    Если у Вас ARM то поищите в этой ветке и соседней про ARM, такие вопросы уже встречались и там можно найти примеры.

    Пока будете тренироваться, воспользуйтесь objdump, readelf для просмотра заголовков секций. Там указаны LMA и VMA.

    LMA - Load memory address Адрес памяти, куда прошивать эту секцию

    VMA - Virtual memory address. Адрес памяти, где эта секция должнабыть во время выполнения программы.

    Перенос данных из LMA в VMA - это задача стартап кода.

    Еще полезно смотреть дизассемблер objdump -SD prg.elf > prg.dump

     

    насчет недостаточости информации в моем вопросе Вы совершенно правы.

    1. я прошиваю bios в prom sparc32 (точнее сказать нет возможности).

    2. bios запускает Linux (точнее сказать нет )(этот Linux не требует Open-Firmware)

    3. стандартный набор компиляторов gcc (точнее сказать нет возможности)

     

    Пока будете тренироваться, воспользуйтесь objdump, readelf для просмотра заголовков секций. Там указаны LMA и VMA.

    LMA - Load memory address Адрес памяти, куда прошивать эту секцию

    VMA - Virtual memory address. Адрес памяти, где эта секция должнабыть во время выполнения программы.

    Перенос данных из LMA в VMA - это задача стартап кода.

    Еще полезно смотреть дизассемблер objdump -SD prg.elf > prg.dump

    да..! это для меня новость!

     

     

    1. Переписать скрипт линкера так, чтобы секция .data в выходном бинарике размещалась сразу за секцией .text.

    2. Написать в стартап файле - это асм - кусочек, который при каждом включении питания перенесет секцию .data из флеш в ОЗУ, на то место где ее ожидает программа.

    я написал код перемещения секци .data (но проверить пока невозможно),

    но и самое главное я не понимаю !!! :help: -

    не могли бы Вы объяснить как может программа ожидать свои данные в совершенно другом месте, чем они были изначально расположены? как я понимаю, наверное, для этого надо что-то где-то указать.

    заранее спасибо!

     

     

    вот что дал readelf.exe :

     

    [Nr] Name Type Addr Off Size ES Flg Lk Inf Al

    [ 2] .data PROGBITS 0001ad20 01ada0 000b50 00 WA 0 0 8

     

    There is no dynamic section inthis file

    There are no relocations in this file.

    There are no unwind sections in this file.

     

    а вот что дал objdump.exe -x:

     

    Sections:

    Idx Name Size VMA LMA File off Algn

    0 .text 0001ad20 00000000 00000000 00000080 2**5

    CONTENTS, ALLOC, LOAD, CODE

    1 .data 00000b50 0001ad20 0001ad20 0001ada0 2**3

    CONTENTS, ALLOC, LOAD, DATA

     

    получается, что VMA==LMA и нЕкуда перемещать.

     

    как же сделать, чтобы VMA был в области RAM ? :help:

     

     

    у меня вот такой ld-скрит (после того как я изменил .data>ram на .data>rom).

     

    /* linkcmds

    *

    * $Id: linkcmds,v 1.8.2.1 2000/05/24 17:06:38 joel Exp $

    */

    OUTPUT_ARCH(sparc)

    __DYNAMIC = 0;

     

    /*

    * The memory map looks like this:

    * +--------------------+ <- low memory

    * | .text |

    * | etext |

    * | ctor list | the ctor and dtor lists are for

    * | dtor list | C++ support

    * | _endtext |

    * +--------------------+

    * | .data | initialized data goes here

    * | _sdata |

    * | _edata |

    * +--------------------+

    * | .bss |

    * | __bss_start | start of bss, cleared by crt0

    * | _end | start of heap, used by sbrk()

    * +--------------------+

    * | heap space |

    * | _ENDHEAP |

    * | stack space |

    * | __stack | top of stack

    * +--------------------+ <- high memory

    */

     

     

    /*

    * User modifiable values:

    *

    * _CLOCK_SPEED in Mhz (used to program the counter/timers)

    *

    * _PROM_SIZE size of PROM (permissible values are 128K, 256K,

    * 512K, 1M, 2M, 4M, 8M and 16M)

    * _RAM_SIZE size of RAM (permissible values are 256K, 512K,

    * 1M, 2M, 4M, 8M, 16M, and 32M)

    *

    */

     

    /* Default values, can be overridden */

     

    _PROM_SIZE = 256K;

    _RAM_SIZE = 2M;

     

    _RAM_START = 0x02000000;/*???*/

    /*********_RAM_START = 0x040000000;*/

    _RAM_END = _RAM_START + _RAM_SIZE;

     

    _PROM_START = 0x00000000;

    _PROM_END = _PROM_START + _PROM_SIZE;

     

    /*

    * Alternate names without leading _.

    */

     

    PROM_START = _PROM_START;

    PROM_SIZE = _PROM_SIZE;

    PROM_END = _PROM_END;

     

    RAM_START = _RAM_START;

    RAM_SIZE = _RAM_SIZE;

    RAM_END = _RAM_END;

     

    _LEON_REG = 0x80000000;

    LEON_REG = 0x80000000;

    _ERC32_MEC = 0x1f80000;

    ERC32_MEC = 0x1f80000;

     

    /* these are the maximum values */

     

    MEMORY

    {

    rom : ORIGIN = 0x00000000, LENGTH = 256K

    ram : ORIGIN = 0x40000000, LENGTH = 1024M

    }

     

    /*

    * stick everything in ram (of course)

    */

    SECTIONS

    {

    . = 0x0;

    .text 0x0 :

    {

    CREATE_OBJECT_SYMBOLS

    text_start = .;

    _text_start = .;

    *(.text)

    *(.text.*)

    . = ALIGN (16);

     

    *(.eh_frame)

    . = ALIGN (16);

     

    *(.gnu.linkonce.t*)

     

    __CTOR_LIST__ = .;

    LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)

    *(.ctors)

    *(.ctors.*)

    LONG(0)

    __CTOR_END__ = .;

    __DTOR_LIST__ = .;

    LONG((__DTOR_END__ - __DTOR_LIST__) / 4 - 2)

    *(.dtors)

    *(.dtors.*)

    LONG(0)

    __DTOR_END__ = .;

     

    _rodata_start = . ;

    *(.rodata*)

    *(.fixup)

    *(.gnu.linkonce.r*)

    _erodata = ALIGN( 0x10 ) ;

     

    _ro_init_data_start = . ;

    *(.ro_init_data*)

    _ro_init_data_end = .;

     

    etext = ALIGN(0x10);

    _etext = .;

    *(.init)

    *(.fini)

    *(.lit)

    *(.shdata)

    . = ALIGN (16);

    _endtext = .;

     

    } > rom

    .dynamic : { *(.dynamic) } >ram

    .got : { *(.got) } >ram

    .plt : { *(.plt) } >ram

    .hash : { *(.hash) } >ram

    .dynrel : { *(.dynrel) } >ram

    .dynsym : { *(.dynsym) } >ram

    .dynstr : { *(.dynstr) } >ram

    .hash : { *(.hash) } >ram

     

    .data :

    {

    data_start = .;

    _data_start = .;

    _sdata = . ;

     

    KEEP (*(.vectors))

     

    *(.data)

    *(.data.*)

    *(.gnu.linkonce.d*)

    *(.gcc_except_table)

    KEEP(*( SORT (.ecos.table.*))) ;

    . = ALIGN(0x10);

    edata = .;

    _edata = .;

    } > rom

    .shbss :

    {

    *(.shbss)

    } > ram

    .bss :

    {

    __bss_start = ALIGN(0x8);

    _bss_start = .;

    bss_start = .;

    *(.bss)

    *(.bss.*)

    *(COMMON)

    end = .;

    _end = ALIGN(0x8);

    __end = ALIGN(0x8);

    __bss_end = ALIGN(0x8);

    __heap1 = .;

    } > ram

    .jcr . (NOLOAD) : { *(.jcr) }

    .stab . (NOLOAD) :

    {

    [ .stab ]

    }

    .stabstr . (NOLOAD) :

    {

    [ .stabstr ]

    }

    }

  6. всем доброго здоровья!

    я никогда не программировал prom-ы. а оказалось, что тут дело серьезное! :help:

     

    у меня в исходниках на С есть некий статический буфер (неконстантный).

    при сборке с использованием прилагающимся к компилятору ld-скриптом (если оставить в нём ram) получается бинарник (после objcopy) длиной аж 1Гб :07: ! начале, как положено - код, а статические даннные помещены в конец - в ram.

    я выкинул ram из ld-скрипта. получился бинарник соответствующего размера. только, боюсь, что придется повозиться с пересылкой static-data в ram (если вообще будет работать :05: ).

    и еще. у меня и нет никакого start-up кода и никакими библиотеками не пользуюсь. может дело еще в этом ?

     

    вопрос: а как это делается , т.е. как сообще автоматизируется сборка и перенос static-data в ram?

  7. доброго всем здоровья!

    мы вот, собираемся разрабатывать RAM для размещения в PCI-слотах (зачем, почему - не для обсуждения. надо. насколько я знаю, Sun и пр выпускают cPCi-слоты памяти).

    но я чайник в linux. и не могу понять как можно подсунуть pci-память операционке так, чтобы она(ОС) считала её ординарной, т.е. могла ее распределять под сегменты исполняемых модулей и данных.

    есть ли у кого опыт такого финта, надо что-то дописывать в mmu или еще где?

    есть ли примеры таких решений?

    или может, вообще нет никаких проблем, и в linux имеется готовый механизм для этого?

     

    и заранее огромное спасибо!