2018年7月28日 星期六

RU 5.21.0344

New features
  1. RU.EFI: Add ROM layout info to CTRL-I System Info page
Minor changes
  1. Fix RU.EFI F12 saved incomplete image if File pull-down menu is opened
  2. Add CSM16 version to CTRL-I System Info [Firmware] section
  3. Fix ALT-9 SMBIOS highlighted area size is wrong if you use PgUp/PgDn to navigate types
  4. Fix ALT-9 SMBIOS type 0 BIOS Version does not show string
  5. Fix AHCI MMIO device name overlapped
  6. Fix RU.EXE ALT-5 can't detect AHCI devices devices since version 5.16
  7. Fix ALT-L (ENTER) is not working in DDR4 page 2
  8. Fix arrow keys can't move cursor after entered editing mode (cursor flashing) since version 5.20
  9. Fix SMBUS SPD always have 2 pages
  10. Fix search function (CTRL-D / CTRL-F) not working properly while reading ALT-F1 HDD
  11. E820 ALT-F2: Change "End Address" to Size on the list for better reading
  12. RU.EXE: Fix "RU /D E820" file.ext hangs
  13. Fix displaying wrong binary bits content (it could be all 1s always) from version 5.20
  14. Fix some minor UI problems
Get RU 5.21.0344 Beta here 
Password: 332012091007

25 則留言:

Unknown 提到...

您好,我是RU.EXE的一名使用者,在使用的过程中发现一点奇怪的地方,希望能得到解答。
我在用RU读取地址为0x00000000的值时,发现读取到的值和我直接用程序读取到的值略有不同,我很好奇这是怎么一回事,而且我后来用debug32.exe读取该地址的值时,读到的和程序读取到的值是相同的。我的师兄告知我说可能是RU将自己的中断hook到了那个地址,所以在RU中读到的值才会不同。
如果方便,希望能得到您的回复,谢谢。

作为参考:
RU读取到的32位值为:164A0162,debug等读到的值为164A5AD0。

Hello, I'm a user of RU.EXE. There's something strange while I'm using it. And I do wish that I can get reply from you ,since I cannot figure it out myself.
When I read the value of the whose address is 0x00000000 with RU, I found that the value is a little different from the value I read with my program. I'm curious about the reason. Then I read the value with debug32.exe, which is the same as I read with my program. My senior told me that maybe it's because RU hooked its interrupt vector there. And I wonder if it's true.
If convenient, plz help me. Thank you very much.
BTW I'm not very good at English ,if you find it offensive, plz forgive me.
my email:czlczln211@gmail.com

James Wang 提到...

Hi Unkown,

I am not sure why it different to DEBUG32 on address 0x0. It's INT 0 vector but RU did not change it.
I will check why.

James Wang 提到...

Hi Unknown,

I think it is OS loader who modified the INT0 vector, RU did not change it.
I checked DEBUG.EXE and DEBUG32.EXE they have different values of address 0x0 as well.

Unknown 提到...

Hi James,
Thank you for your answering.
I Replied via email, but it seems that it didn't work, so I 'll just come here.

Maybe it is OS that changed it, but I mean, why is it different that I read the value of 0:0, with RU and debug? Anyway, either RU or debug, or debug32, they all run on the DOS, shouldn't they be the same even that OS changed the value?
BTW, I wrote a simple program by assembly like mov eax, [0], and output it to 0x80 port to the debug card. The vale is the same as DEBUG32.EXE. I mean, is it possible that RU didn't make it to read the real value of address 0:0?

匿名 提到...

I am using ru to read HD audio card vendor id(not HD audio bus pci id) of an amd mainboard, when I CTRL+G to mmio address, it returns all 0xff. But for intel HD audio bus, it's OK. Is there any amendments for this?

匿名 提到...

Hi James,

Firstly Thank you so much for your RU Tools for me to debug BIOS.
I just want to let you know that the RU.efi latest version 5.21.0344 in skylake-D intel CPU, I saw exception. Here below the log.
!!!! X64 Exception Type - 01(#DB - Debug) CPU Apic ID - 00000000 !!!!
RIP - 00000000612A528E, CS - 0000000000000038, RFLAGS - 0000000000200246
RAX - F000322FF0003287, RCX - 0000000000000004, RDX - 0000000000000004
RBX - 0000000000000000, RSP - 000000006E46D130, RBP - 0000000000000000
RSI - 000000006E46D29C, RDI - 0000000061269CAC
R8 - 0000000000000004, R9 - 0000000000000000, R10 - 000000000000000D
R11 - 000000006E2EC240, R12 - 0000000063EA9B98, R13 - 0000000000000000
R14 - 0000000061389508, R15 - 0000000061389658
DS - 0000000000000030, ES - 0000000000000030, FS - 0000000000000030
GS - 0000000000000030, SS - 0000000000000030
CR0 - 0000000080000013, CR2 - 0000000000000000, CR3 - 000000006E2ED000
CR4 - 0000000000000668, CR8 - 0000000000000000
DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
GDTR - 0000000069392DA0 0000000000000047, LDTR - 0000000000000000
IDTR - 0000000066FF2018 0000000000000FFF, TR - 0000000000000000
FXSAVE_STATE - 000000006E46CD90
!!!! Find PE image (No PDB) (ImageBase=0000000061261000, EntryPoint=000000006127FAF0) !!!!

for Version 2

Already tried on 5.20, 5.19, 5.17, looks working fine.

Thank you.

James Wang 提到...

Hi Unknown,

It is possible that debug.exe and debug32.exe changed the 0000:0000 for their own purpose. After all they are debug purpose program and INT0 is "dived by zero". Anyway RU did not change INT0.

James Wang 提到...

Hi 匿名,

Can you give me the AMD's model for me to check what could be wrong?

James Wang 提到...

Hi 匿名,

Oops, not sure why it has exception. Can you tell me how I can reproduce the problem on Skylake-D?

Unknown 提到...

Thanks James, still happy in using AMI ru tool.

James Wang 提到...

Hi Andy,

Thanks!

RossLu 提到...

有機會把EC的功能一起做上去嗎?
類似RW 裡面的Embedded Controller 的ITEM.

James Wang 提到...

Hi Ross,

I think I can try to do that.

RossLu 提到...

非常感謝...
有任何需要協助的地方, 請讓我知道!

匿名 提到...

您好
我在UEF環境使用RU.efi 讀取ISA的2E 2F 無法顯示值,是要做什麼設定呢?

我使用dos版本是可以讀的到的

謝謝您

James Wang 提到...

I think I will need the system to reproduce the 2E/2F problem.

Jiang Junyu 提到...

Hi James,
Is there a way to read SMI counter in UEFI application? It's located in register 0x34.
Thank you.

James Wang 提到...

Hi Jiang Junyu,

What SMI counter you are referring to?

Jiang Junyu 提到...

Please refer to programming guide volumn 4, MSR offset 0x34, SMI counter. How many SMI has been triggered after reset.

James Wang 提到...

Just using RDMSR in your ASM file.

Jiang Junyu 提到...

Hi James,
I am sorry, are you saying I created an assembly application running on DOS then boot into DOS to read it?
Your RU EFI application has the CPU MSR reading method, correct?

Thank you.

James Wang 提到...

Hi Junyu,

You can still have ASM file used in UEFI Application, just put it to INF file.

Jiang Junyu 提到...

Hi James,

Sorry I don't quite understand your answer. Are you saying to build my self own efi application?

Thanks

James Wang 提到...

Hi Jiang Junyu,

I can add that MSR in RU. Will be release in next version.

James Wang 提到...

I think I might have fixed the exception problem, please get the latest 5.22.0354