Board.KolibriOS.org

Official KolibriOS board
It is currently Tue May 21, 2019 6:03 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 70 posts ]  Go to page Previous 1 2 3 4 5
Author Message
PostPosted: Wed Oct 19, 2011 2:50 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1619
С точки зрения идеальной корректности поиск пакета _S5_ простым линейным сканированием ничуть не лучше банального поиска подстроки _S5_ - в таблицах ACPI может быть много всяких заморочек, и нужно либо полностью создавать дерево объектов и быть готовым к выполнению методов, либо вообще не заморачиваться.
В чём проблема с декодированием PkgLength? Экономное кодирование, на первом скриншоте закодирована длина 53h, слишком большая для одного байта, но влезающая в два, на втором - длина 19h, влезающая в один байт.

_________________
Сделаем мир лучше!


Top
   
PostPosted: Wed Oct 19, 2011 3:21 pm 
Offline
Just Flooding
User avatar

Joined: Wed May 18, 2005 10:27 am
Posts: 430
Code:
;--- Interpreting AML ---
Interpret_AML:  lods    byte [gs:esi]   ;Get Lead Byte
                cmp     al, 0x10        ;10h = SCOPE Operator
                 jne    AML_1
;--- Interpreting 10h=ScopeOp ---
Skip_Pack:      mov     dl, [gs:esi]    ;Get Package Length, byte 0
                movzx   ebx, dl
                and     dl, 11000000b
                 jz     Skip_Package
                and     bl, 00001111b
                mov     cx, 0x104       ;Offset=1, Shifts=4
                call    Scan_AML_Local_0
                cmp     dl, 01000000b
                 je     Skip_Package
                mov     cx, 0x20C       ;Offset=2, Shifts=12
                call    Scan_AML_Local_0
                cmp     dl, 10000000b
                 je     Skip_Package
                mov     cx, 0x314       ;Offset=3, Shifts=20
                call    Scan_AML_Local_0
Skip_Package:   add     esi, ebx
                jmp     Next_AML         
данное декодирование не находит _S5_ ввиду
неправильного либо кода 19h либо... либо самого декодирования.
Возможно версия ACPI таблицы старовата, вернее что то типа ACPI v.1.0, не помню...
это старенький ящик, там южник ICH2, это точно.
Так вот думаю, может он, этот байт раньше как то по другому кодировался чтоли...
мало того гугл говорит, что народ мордующийся, проблемами корявого ACPI в ноутах, часто
говорит, что дескать поправьте сами, пропачте Вашу проблему.
Сайтов таких немало и даже специалные ,т.е. специализирующихся на коллекционировании
методов исправления ACPI корявостей. Я не специально это говорю, чтобы очернить.
Я сам в шоке с массой увиденного и прочитанного.
Подумал что с ходу оседлаю ACPI, универсальность...
Похоже ляжет очередным пластом недоделок в мой "личный ящик черновиков"...
Некогда
Нужно думать.
Думать и принимать решение(е) и вообще ограничиться бы "правильным" и нужным сегментом ACPI и не лезть в дебри. Вряд ли кто подскажет. Нужен реальнй опыт на разных чипах и производителях.
Кто бы подсказал что лишнее, что нет, что в перую очередь, а что нет.
Это если делать. А делать никто не хочет.
Все хотят бесплатной халвы и чтобы именно его чипсет работал и пофиг дальше. Факт.
Ладно, дам ссылку про ноуты, может кому и на подобную неприятность откроет глаза http://habrahabr.ru/blogs/system_programming/128449/
Приятно читать у других то, за что говорил сам (SMI).


Top
   
PostPosted: Wed Oct 19, 2011 3:42 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1619
Этот огрызок кода декодирует PkgLength. Весь код по вышеприведённой ссылке не способен даже на простое линейное сканирование - малейшее отличие таблицы от той, на которую рассчитывал автор, приводит код в ступор. Скачайте уже AML-дизассемблер с http://www.acpica.org/downloads/binary_tools.php - iasl -d в пакете - и посмотрите на таблицы:
Code:
/* первая таблица */
    Scope (\_PR) /* про оператор Scope код знает и полностью игнорирует содержимое */
    {
        Processor (\_PR.CPU0, 0x00, 0x00000410, 0x06) {}
        Processor (\_PR.CPU1, 0x01, 0x00000410, 0x06) {}
        Processor (\_PR.CPU2, 0x02, 0x00000410, 0x06) {}
        Processor (\_PR.CPU3, 0x03, 0x00000410, 0x06) {}
    }

    Name (\_S0, Package (0x04) /* про оператор Name код знает и ищет \_S5 */
    {
        0x00,
        0x00,
        0x00,
        0x00
    })
    Name (\SS1, Package (0x04)
    {
        0x01,
        0x00,
        0x00,
        0x00
    })
    Name (\_S3, Package (0x04)
    {
        0x05,
        0x00,
        0x00,
        0x00
    })
    Name (\_S4, Package (0x04)
    {
        0x06,
        0x00,
        0x00,
        0x00
    })
    Name (\_S5, Package (0x04) /* вот он \_S5, до него ничего неподдерживаемого нет */
    {
        0x07,
        0x00,
        0x00,
        0x00
    })
...

Code:
/* вторая таблица */
    Scope (\_PR)  /* про оператор Scope код знает и полностью игнорирует содержимое */
    {
        Processor (\_PR.CPU0, 0x01, 0x00004010, 0x06) {}
    }

    OperationRegion (CM72, SystemIO, 0x72, 0x02) /* а про это код не знает и тупо вываливается */
    Field (CM72, ByteAcc, NoLock, Preserve)
    {
        CI72,   8,
        CO73,   8
    }

    IndexField (CI72, CO73, ByteAcc, NoLock, Preserve)
    {
                Offset (0x50),
        SUSF,   8
    }

    Name (FLAG, 0x00)
    Name (STAT, 0x00)
    Name (\_S0, Package (0x04)
    {
        0x00,
        0x00,
        0x00,
        0x00
    })
    And (SUSF, 0x02, STAT)
    If (STAT)
    {
        Name (\_S3, Package (0x04)
        {
            0x05,
            0x00,
            0x00,
            0x00
        })
    }
    Else
    {
        Name (\_S1, Package (0x04)
        {
            0x01,
            0x00,
            0x00,
            0x00
        })
        Name (\_S4, Package (0x04)
        {
            0x07,
            0x00,
            0x00,
            0x00
        })
    }

    Name (\_S5, Package (0x04)
    {
        0x07,
        0x00,
        0x00,
        0x00
    })

_________________
Сделаем мир лучше!


Top
   
PostPosted: Wed Oct 19, 2011 4:14 pm 
Offline
Just Flooding
User avatar

Joined: Wed May 18, 2005 10:27 am
Posts: 430
CleverMouse wrote:
Этот огрызок кода декодирует PkgLength. Весь код по вышеприведённой ссылке не способен даже на простое линейное сканирование - малейшее отличие таблицы от той, на которую рассчитывал автор, приводит код в ступор.
А как же стандарт, описание...???
Автор согласно стандарту реализовал битовую работу с PkgLength или нет?
А вроде вижу, что по стандарту.
Тогда его код вправе "прыгать" по таблице DSDT блочно, перешагивать куски таблицы, я так понимаю.
Ну естественно зная, наверное структуру таблицы. Хотя я не совсем понял, что такое PkgLength.
Length ближайшего блока, а дальше будет следующий PkgLength, наверное...

В данном примере проблемы asm код этот "недошагивает" до _S5_, длина выходит короткой, т.е. 19h типа мало.
Даже глядя на дамп, что привел видно, что фактический offset до _S5_ больше чем 19h от текущей позиции.
Вот и вываливаемся из алгоритма, как ошибка декодинга таблицы.

Либо я заблуждаюсь и в таблице "роются" по блокам, таки сигнатурно, как и делают до того.
Фигню эту и др. я скачал, только непонятно, что за псевдоязык, нафига... намутили блин,
науниверсалили так, что набекрень извилины, а вкуривать некогда, да и влом уже, если честно.
Раценка свободного времени уже не та.
Ладно, как нить потом, быть может.


Top
   
PostPosted: Wed Oct 19, 2011 4:37 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1619
С PkgLength - по стандарту. Но в стандарте PkgLength - это всего лишь один вспомогательный элемент из многих. Таблица DSDT состоит из отдельных блоков; некоторые блоки имеют переменную длину, и им нужен PkgLength, а некоторые - фиксированную, и им PkgLength не нужен. Чтобы "прыгать" по таблице DSDT, нужно знать о всех блоках.

Пример на основе второго скриншота. Длина заголовка таблицы 24h, дальше начинается AML-код. Первый байт - 0x10; в таблице из 19.3 AML Byte Stream Byte Values можно увидеть, что это ScopeOp, опкод команды Scope. Для этой команды, как можно увидеть в другом месте, дальше идёт PkgLength, определяющий длину этого блока. Дальше некоторое время идут данные самого Scope и данные внутри Scope. Следующий блок начинается с байтов 0x5B 0x80; по той же таблице это OpRegionOp, который состоит из OpRegionOp NameString RegionSpace RegionOffset RegionLen; дизассемблер показывает это как OperationRegion (CM72, SystemIO, 0x72, 0x02). Этот блок фиксированной длины, у него нет PkgLength. Кривой код пропустить этот блок не может, потому что о нём не знает - знает он только о Scope и Name.

_________________
Сделаем мир лучше!


Top
   
PostPosted: Thu Oct 20, 2011 9:51 pm 
Offline

Joined: Tue Sep 20, 2011 1:02 am
Posts: 13
Serge wrote:
VaStaNi
Твои графики ничего не доказывают. Точность HPET 0.05%. Это +- 750 тактов для 1.5Ггц процессора. Точность 8254 ведома только Интелу. А разброс частоты у процессора ?
Ты же не хочешь сказать что у тебя в чипсете идеальный таймер и идеальный процессор в сокете ? Если хочешь точно считать такты используй таймер LAPIC. А пока все эти замеры ничего не доказывают. Ты микрометры меряешь школьной линейкой.

вообще для подсчета тактов используют RDTSC у нее точноть точьно побольше будет


Top
   
PostPosted: Fri Oct 21, 2011 1:32 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
abcd0081
1. Таймер LAPIC и RDTSC используют общий тактовый генератор.
2. LAPIC генерирует прерывание через установленное программистом количество тактов. Следовательно независимо от стабильности тактового генератора прерывания всегда следуют через одинаковое количество тактов.
3. Прочитав значение счётчика LAPIC в обработчике прерываний и сравнив с исходным значением легко вычислить латентность обработчика в процессорных тактах.


Top
   
PostPosted: Fri Oct 21, 2011 10:41 am 
Offline

Joined: Tue Sep 20, 2011 1:02 am
Posts: 13
Serge wrote:
abcd0081
1. Таймер LAPIC и RDTSC используют общий тактовый генератор.
2. LAPIC генерирует прерывание через установленное программистом количество тактов. Следовательно независимо от стабильности тактового генератора прерывания всегда следуют через одинаковое количество тактов.
3. Прочитав значение счётчика LAPIC в обработчике прерываний и сравнив с исходным значением легко вычислить латентность обработчика в процессорных тактах.

я имел ввиду замер тактов. например для куска кода. а не частоту вызовов прерывания.


Top
   
PostPosted: Sat Oct 22, 2011 5:15 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
abcd0081
VaStaNi интересуют паузы между прерываниями. И я писал про паузы между прерываниями.


Top
   
PostPosted: Sun Nov 23, 2014 4:26 pm 
Offline

Joined: Wed May 18, 2005 7:27 pm
Posts: 1001
http://board.flatassembler.net/topic.php?t=17069

ACPI 5.1 Released
Enjoy: http://www.uefi.org/sites/default/files ... elease.pdf

=
http://board.flatassembler.net/topic.php?t=17311


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 70 posts ]  Go to page Previous 1 2 3 4 5

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited