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

am1808

Участник
  • Постов

    124
  • Зарегистрирован

  • Посещение

Весь контент am1808


  1. вы же сами написали что вам нужно: отсюда вывод такой: проще написать самописный серверок под ваши нужды, из которого вы "более проще достучитесь до системы" а выбирать как делать, смотрите сами, как именно вам проще
  2. оптимизация на понимание логики бинаря при дизасемблировании в целом не повлияет
  3. вам уже ответили, передавайте заказчику функционал в виде либы и да, в любом случае, если аппаратно не защитите, как бы вы не хранили функционал, любой маломальски путный программист при желании дизассемблирует ваше ноу-хау
  4. например, посмотрите вот тут http://www.paulgriffiths.net/program/c/webserv.php или гуглите "simple web server on c" тут имеется ввиду какой либо веб-сервер
  5. о чем и речь, и дело даже не в том, знает линкер про секции .text, .data, .bss, а в том, по каким адресам аллокировать секции в runtime можете еще почитать ресурс вот тут http://bravegnu.org/gnu-eprog/lds.html
  6. да что вы парню голову морочите и усложняете ему задачу на си пишешь простой сервер, который слушает 80 порт, по GET || POST запросу от броузера вываливаешь ему (клиенту, тобишь броузеру) необходимые значения переменных, в виде простейшего html, вот и все решение( 100-150 строк кода )
  7. могу ошибаться, но данная секция в любом случае будет allocatable, за исключением случаев, когда этот код будет выполняться с ROM Locations represent addresses in memory if a section is allocatable; that is, its contents are to be placed in memory at program runtime. Symbolic references to these locations must be changed to addresses by the link editor. еще может быть полезным: The linker combines input files into a single output file. The output file and each input file are in a special data format known as an object file format. Each file is called an object file. The output file is often called an executable, but for our purposes we will also call it an object file. Each object file has, among other things, a list of sections. We sometimes refer to a section in an input file as an input section; similarly, a section in the output file is an output section. Each section in an object file has a name and a size. Most sections also have an associated block of data, known as the section contents. A section may be marked as loadable, which mean that the contents should be loaded into memory when the output file is run. A section with no contents may be allocatable, which means that an area in memory should be set aside, but nothing in particular should be loaded there (in some cases this memory must be zeroed out). A section which is neither loadable nor allocatable typically contains some sort of debugging information. Every loadable or allocatable output section has two addresses. The first is the VMA, or virtual memory address. This is the address the section will have when the output file is run. The second is the LMA, or load memory address. This is the address at which the section will be loaded. In most cases the two addresses will be the same. An example of when they might be different is when a data section is loaded into ROM, and then copied into RAM when the program starts up (this technique is often used to initialize global variables in a ROM based system). In this case the ROM address would be the LMA, and the RAM address would be the VMA.
  8. вы свою пользовательскую секцию линкуете с адресным пространством on-chip RAM, в таком случае секцию следует обозначить как "allocatable"; попробуйте вашу секцию в скрипте линкера связать с "on-chip non-volatile memory" без использования флага "a" в исходном коде, должно успешно слинковаться
  9. Вы не правильно трактуете вышеприведенные статьи! там говорится немного не о том, что вам надо
  10. всем преогромное спасибо, весь прикол был только в Reset unusing clock during boot, неободимо включить такой параметр. с корневой фс вопрос решен
  11. да, спасибо, для ядра 3.1.6 кеши точно отключены и пунк "Reset unusing clock during boot" включен. завтра обращу внимание на ядро 2.6.34, которое TI поставляло к EVM1707
  12. спасибо, завтра сравню регистры и конфиги для старого ядра. сегодня весь день провел за программированием ФС в нанд. все казалось бы делаю по инструкции, все вроде отрабатывает, а ядро при загрузке вот паникует и вываливает следующий лог: U-Boot > loadb ## Ready for binary (kermit) download to 0xC0700000 at 115200 bps... ## Total Size = 0x001d48c0 = 1919168 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: 1919104 Bytes = 1.8 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) ) #10 PREEMPT Tue Dec 27 11:33:39 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 earlyprintk ip=off root=/dev /mtdblock0 rw rootfstype=jffs2 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: 28584k/28584k available, 4184k 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 - 0xc0358508 (3394 kB) .init : 0xc0359000 - 0xc037a000 ( 132 kB) .data : 0xc037a000 - 0xc039f080 ( 149 kB) .bss : 0xc039f0a4 - 0xc03c40ac ( 149 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. JFFS2 version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc. msgmni has been set to 55 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 ONFI flash detected ONFI param page 0 valid NAND device: Manufacturer ID: 0x2c, Chip ID: 0xf1 (Micron MT29F1G08ABADAWP) Creating 1 MTD partitions on "davinci_nand.1": 0x000000000000-0x000008000000 : "filesystem" davinci_nand davinci_nand.1: controller rev. 2.5 spi_davinci spi_davinci.0: DMA: supported spi_davinci spi_davinci.0: DMA: RX channel: 14, TX channel: 15, event queue: 0 spi_davinci spi_davinci.0: Controller at 0xfec41000 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 watchdog watchdog: heartbeat 60 sec SoftDog: cannot register miscdev on minor=130 (err=-16) 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: d2:0d:54:78:68:1c console [netcon0] enabled netconsole: network logging started rtc-test rtc-test.0: setting system clock to 1970-01-01 00:00:02 UTC (2) Root-NFS: no NFS server address VFS: Unable to mount root fs via NFS, trying floppy. List of all partitions: No filesystem could mount root, tried: jffs2 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0) [<c000d830>] (unwind_backtrace+0x0/0xf8) from [<c0284cd4>] (panic+0x60/0x1a8) [<c0284cd4>] (panic+0x60/0x1a8) from [<c0359dcc>] (mount_block_root+0x1c8/0x224) [<c0359dcc>] (mount_block_root+0x1c8/0x224) from [<c0359ea8>] (mount_root+0x80/0 xc8) [<c0359ea8>] (mount_root+0x80/0xc8) from [<c0359ffc>] (prepare_namespace+0x10c/0 x1c8) [<c0359ffc>] (prepare_namespace+0x10c/0x1c8) from [<c035928c>] (kernel_init+0xec /0x12c) [<c035928c>] (kernel_init+0xec/0x12c) from [<c0009c9c>] (kernel_thread_exit+0x0/ 0x8) BOOTME bootargs=console=ttyS2,115200n8 mem=32M earlyprintk root=/dev/mtdblock0 rw rootfstype=jffs2 ip=off корневую ФС базовую скачал с офиц. сайта. распаковал и установил туда kernel headers and modules. собирал jffs2.bin следующим образом: # mkfs.jffs2 -p -d rootfs -s 2048 -e 0x20000 -l -q -o rootfs.jffs2 -v –n NAND Organization: – Page size x8: 2112 bytes (2048 + 64 bytes) – Page size x16: 1056 words (1024 + 32 words) – Block size: 64 pages (128K + 4K bytes) – Device size: 1Gb: 1024 blocks получившийся образ ФС я заливаю по терминалу в оперативку борды, затем делаю: 1. nand erase 0 0x08000000 2. nand write.jffs2 0xc0700000 0 $filesize все удачно программируется, затем гружу ядро( NAND & JFFS2 включены при сборке ядра) куда копать и что делать? подскажите пожалуйста. и еще, почему ядро первым делом пытается примонтировать ФС по NFS, когда я ему четко указал откуда брать корневую ФС?
  13. спасибо :beer: , для 100% уверенности, свой тестер напишу
  14. извиняюсь, не совсем понял, а как же еще ячейки памяти проверить? разве не запись числа/чтение его и сравнение с записывемым, в юбуте реализовано именно так. еще раз спасибо
  15. итак, 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 в чем причина такого? и по каким причинам калибровка не происходит?
  16. ясно, так и сделал. я к чему спросил, потому что вдруг какой то модуль тоже максрос этот подцепляет ага, ясно. я так понимаю, в первом случае для целей с расширением i выполняется какая то шаблонная цель для препроцессинга? еще раз спасибо большое!
  17. ага, понял, спасибо. а где лучше и рекомендательнее убрать FLOW_CONTROL ? и еще вот не совсем понятно, в файле arch/arm/boot/compressed/head.S есть по всей видимости отладка, которая спрятана под #ifdef DEBUG никак не могу понять, где он определен, то ли через gcc передается, то ли где то статически забит или нет. мне нужно задефайнить DEBUG или же нет? и где это лучше сделать? и еще вот такой вопрос, как то можно включить фичу при сборке ядра, чтобы посмотреть на исходный модуль(файл) после препроцессора, например, через опцию -E gcc?
  18. спасибо огромное, в понедельник проверю и отпишусь
  19. sasamy, спасибо преогромное, как раз разбираю эти функции. machid я намеренно передам другой из u-boot, в нем же выставлю правильные параметры для early_printk(). результат к сожалению смогу сказать только в понедельник. скажите пожалуйста, до какого момента я могу использовать функции early_write(), printascii(), printch(), printhex()? и еще такой момент, я не использую ubl, при портировании u-boot были проблемы с выводом на консоль с его стороны, связанные с неправильной работой UART, помогла запись 0 в регистр MDR UART ( 16× over-sampling ). в драйверах ядра этот регистр никак не используется. Как то можно предположить, что проблемы с ядром связаны с регистром UART MDR?
  20. нет, такой аргумент не добавлял. даже не знал, и нигде не написано про это
  21. нет, не пробовал. как то можно вывести буффер до start_kernel() и инициализации консоли?
  22. спасибо, да, я пробовал и с выбирать нанд вместо LCD, но это тоже не влияет
  23. могу выслать и исходный код ядра, и уже собранное ядро. да, конфигурирую ядро под определенную конфигурацию вот так: 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 my_config_kernel.zip uImage.zip
×
×
  • Создать...