Jump to content

    

vv40in

Участник
  • Content Count

    8
  • Joined

  • Last visited

Everything posted by vv40in


  1. всем доброго здоровья! На этапе инициализации (в цепочке 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
  2. Цитата(Harbour @ Oct 16 2008, 13:29) а кто сказал что найденный диск именно 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? да? ну, правильно. так, а какой же диск замонтирован (если замонтирован)? как это определить?
  3. sparcv8.pdf (p.46): 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-ов ) и я уверен, что 64-битная проблема встретится и дальше. спаркологи! поможите чем можете! что мне делать? как добиться загрузки ядра?
  4. всем доброго здоровья! я никогда не программировал prom-ы. а оказалось, что тут дело серьезное! у меня в исходниках на С есть некий статический буфер (неконстантный). при сборке с использованием прилагающимся к компилятору ld-скриптом (если оставить в нём ram) получается бинарник (после objcopy) длиной аж 1Гб ! начале, как положено - код, а статические даннные помещены в конец - в ram. я выкинул ram из ld-скрипта. получился бинарник соответствующего размера. только, боюсь, что придется повозиться с пересылкой static-data в ram (если вообще будет работать ). и еще. у меня и нет никакого start-up кода и никакими библиотеками не пользуюсь. может дело еще в этом ? вопрос: а как это делается , т.е. как сообще автоматизируется сборка и перенос static-data в ram?
  5. УРА!!! заработало!!! вот что дал мне 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 всем спасиба!!! теперь только осталось проверить - будет ли всё это работать ?
  6. большое спасибо за ответ! Цитата(amw @ Aug 15 2008, 21:42) И вам! Чтобы понять это нужно обладать способностью к телепатии. К сожалению я ею не владею . Итак, попробую догадаться. Вы имеете пример (для какого процессора?), без использования ОС, на С, предназначенный для загрузки в ОЗУ. И хотите перекомпилировать его для флеш и прошить. Я угадал? Потому как в Вашем вопросе мало конкретной информации придется начать издалека. 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 (но проверить пока невозможно), но и самое главное я не понимаю !!! - не могли бы Вы объяснить как может программа ожидать свои данные в совершенно другом месте, чем они были изначально расположены? как я понимаю, наверное, для этого надо что-то где-то указать. заранее спасибо! вот что дал 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 ? у меня вот такой 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 ] } }
  7. доброго всем здоровья! мы вот, собираемся разрабатывать RAM для размещения в PCI-слотах (зачем, почему - не для обсуждения. надо. насколько я знаю, Sun и пр выпускают cPCi-слоты памяти). но я чайник в linux. и не могу понять как можно подсунуть pci-память операционке так, чтобы она(ОС) считала её ординарной, т.е. могла ее распределять под сегменты исполняемых модулей и данных. есть ли у кого опыт такого финта, надо что-то дописывать в mmu или еще где? есть ли примеры таких решений? или может, вообще нет никаких проблем, и в linux имеется готовый механизм для этого? и заранее огромное спасибо!