Jump to content
XPEnology Community

Annoying BIOS reset issue is really bugging me!!!


Recommended Posts

Hello vejta66

 

I created this post merely to address the issue of RESET BIOS, when you set time to turn on your XPEnologized PC.

 

The intention is to create the awareness that such a problem exist when you are playing around with XPEnology.

 

And also share the "workaround solution" and NOT requesting for a permanent fix.

 

Because, neither me nor the fellow forum user is able to do it, unless we are the core developers.

 

You need to PM the administrator as to how to solve this problem. So in short, I couldn't offer any help

in answering your question regarding to X64 build. :sad:

 

As far as I know, unless you are willing to change your hardware to a different motherboard, like INTEL DQ35JOE,

there is no reset BIOS issue, but as of now, I CANNOT promise the lastest version of XPEnoboot + the lastest DSM image

will NOT cause BIOS resetting problem. Simply because I couldn't find the time to test it :grin:

 

Hi liukuohao,thanks for ur answer and sorry, because since english in not my "original language" maybe i express myself bad. Ofcourse i never dream to ask for a permanet fix. i was only speculating (not sure it's the rigth word) about possibilities and i'd like to know others opinions.

best regard :smile:

Link to comment
Share on other sites

I have just got an Atom D525 machine and installed XPEnoboot 5.2-5644 on it. Everything else is working well but the BIOS resets every time DSM starts, and shutdown action in DSM will lead to a reboot after shutdown. NanoBoot x86 5.0.3.1 worked fine though, but the DSM of DS214play can't recognize all of my network adapters.

 

After poking around the (outdated) NanoBoot source (5.0-4458, x86-64, DS3612xs), I found that the synobios.ko was the suspect: at first I didn't add required symbols into the kernel source, so synobios.ko couldn't load. And no BIOS resetting happened during this period. After the symbols being added and synobios.ko loaded, the resets began.

 

So I switched back to XPEnoboot 5.2-5644, and spent all night studying the disassembly of the file in this version (why the initramfs is packed into zImage...) I nop'ped out some suspectful function call. Then things seems to be OK. Though it still reboots when I select shutdown in the menu, but BIOS settings remain unchanged.

 

However, a power failure came after I finished a power cycle, so I can't determine whether the case is normal or just a coincidence. (I have done only one time of trial) I will test again when the electricity supply returns normal.

Link to comment
Share on other sites

I have been playing around DSM 5.2 for an hour and has rebooted several times. BIOS settings remain unchamged. I will try to schedule auto-boot and shutdown, and see if it resets the BIOS. If the schedule does not reset the BIOS, we can (almost) confirm the modified synobios.ko works...

 

ADD: if I unplug all the USB devices, including the pen drive containing bootloader, the shutdown menu will work as expected. But how can I use DSM without the pen drive?

Link to comment
Share on other sites

Maybe once is loaded the usb firmware isnt called anymore or it stay in ram (DSM OS copy itself on evry hdd u configure). I dont really know. Anyway ur results are very good. I myself thinked on something similar, but i cant access zimage so....

Edited by Guest
Link to comment
Share on other sites

I have been playing around DSM 5.2 for an hour and has rebooted several times. BIOS settings remain unchamged. I will try to schedule auto-boot and shutdown, and see if it resets the BIOS. If the schedule does not reset the BIOS, we can (almost) confirm the modified synobios.ko works...

 

ADD: if I unplug all the USB devices, including the pen drive containing bootloader, the shutdown menu will work as expected. But how can I use DSM without the pen drive?

 

Great to hear some progress :smile: Do you mind share what you have changed in that file so more people can try?

 

Thanks!

Link to comment
Share on other sites

So here is what I thought and did...

 

From the discussion pages before, we can infer that the BIOS resetting has something to do with the time setting. And from my NanoBoot build tests we know that synobios.ko is the suspect. So I digged into this file.

 

0. Extract vmlinux from zImage from XPEnoboot, then extract ramdisk cpio in the vmlinux (why does XPEnology packs the ramdisk with vmlinux?)

 

1. Extract synobios.ko from ramdisk. Load the file in IDA, and search for time related functions in the function window.

 

2. There is an imported function named rtc_cmos_write, which fits our demand perfectly: time-related(RTC), operates with hardware(cmos_write) (Actually this is an exported function in common Linux kernel) So I decided to remove all calls to this function in order to block writing to the RTC.

bgbmn8.png

 

3. List all the cross references to rtc_cmos_write. This is the common procedure for a call:

t9cbxk.png

l8z81.png

We need to replace all these calls including argument passing procedure with NOP(0x90), which instructs the processor to do nothing when we reach here.

 

4. However, the file looks like this in WinHex: (IDA's Hex View is not showing original file)

5yyg.png

[updated 2016/03/10: Wrong mark on the WinHex side]

This is due to the kernel modules are relocatable. The actual jumping address will be filled during runtime, and there is only a stub after the "call" instrcution. So we need to stop the "address filling".

 

WARNING! Byte offset is different from the instruction offset shown in IDA. You can find the actual byte offset at the bottom left corner of IDA's Hex View. Byte offset should be used for "Navigation -> Goto Offset" in WinHex.

 

5. ELFs use relocation tables for this. Each item in the table tells the linker where we should fill and what to fill with. However I don't know where the table is placed, and all I can do is to search the address of the stubs. The following picture is search results of the first stub (at 0x0000000000003820, presented as 0x2038000000000000 in little-endian)

m76ezm.png

This means the stub at 0x0000000000003820(2nd byte of "call rtc_cmos_write" in rtc_correct_wday) will be replaced with rtc_cmos_write's actual address at runtime.

There are a bunch of these stubs which refers to rtc_cmos_write. Since the function rtc_correct_wday looks harmless, let's replace all references to other stubs to the one in this function, 0x0000000000003820. As those stubs won't get filled, we can continue using NOP to skip them.

 

For example, there is "call rtc_cmos_write" in rtc_bandon_rotate_auto_poweron at 0x38c7 and the jumping target address stub begins at 0x38c8 (zeros omitted), then we search for 0xc838

2qaspaa.png

and change it to 0x2038.

120hyc9.png

Do the same for all other stubs in rtc_cmos_write calls. Be careful! Don't leave out any reference to the stubs.

 

Note: all addresses mentioned in step 5 is IDA's instruction address. But since we are searching for hex values, we won't use Goto Offset menu so don't worry about the byte offset.

 

6. Now, relocation won't interfere with our changes about NOP'ping the "call" instrcutions. It's time to change all bytes shown in step 4 to 0x90. Remember, we are not NOP'ping the one in rtc_correct_wday.

 

For example, we are removing the "call rtc_cmos_write" at 0x38c7 (0x3937 for byte offset, use Goto Offset menu).

The disassembly looks like this:

hx94pu.png

Change like this: (the argument calculating and passing procedure took a bit more (4) instructions...)

35dawlc.png

Then the disassemnly should be like this:

33z347a.png

Do the same for all other calls to rtc_cmos_write.

 

Note: if you don't know how to determine where the argument passing procedure starts, just ignore it and NOP the call instruction (0xE8 and 4 following bytes). It may work...

 

7. You are all set now. Put the modified file back into the cpio archive, copy to your boot disk, and let Grub load this archive as initrd to override the one inside zImage. If you encounter "No space left" error, you can try resizing the partition and filesystem.

Edited by Guest
Link to comment
Share on other sites

So here is what I thought and did...

 

From the discussion pages before, we can infer that the BIOS resetting has something to do with the time setting. And from my NanoBoot build tests we know that synobios.ko is the suspect. So I digged into this file.

 

0. Extract vmlinux from zImage from XPEnoboot, then extract ramdisk cpio in the vmlinux (why does XPEnology packs the ramdisk with vmlinux?)

 

1. Extract synobios.ko from ramdisk. Load the file in IDA, and search for time related functions in the function window.

 

2. There is an imported function named rtc_cmos_write, which fits our demand perfectly: time-related(RTC), operates with hardware(cmos_write) (Actually this is an exported function in common Linux kernel) So I decided to remove all calls to this function in order to block writing to the RTC.

bgbmn8.png

 

3. List all the cross references to rtc_cmos_write. This is the common procedure for a call:

t9cbxk.png

l8z81.png

We need to replace all these calls including argument passing procedure with NOP(0x90), which instructs the processor to do nothing when we reach here.

 

4. However, the file looks like this in WinHex: (IDA's Hex View is not showing original file)

103wupk.png

This is due to the kernel modules are relocatable. The actual jumping address will be filled during runtime, and there is only a stub after the "call" instrcution. So we need to stop the "address filling".

 

WARNING! Byte offset is different from the instruction offset shown in IDA. You can find the actual byte offset at the bottom left corner of IDA's Hex View. Byte offset should be used for "Navigation -> Goto Offset" in WinHex.

 

5. ELFs use relocation tables for this. Each item in the table tells the linker where we should fill and what to fill with. However I don't know where the table is placed, and all I can do is to search the address of the stubs. The following picture is search results of the first stub (at 0x0000000000003820, presented as 0x2038000000000000 in little-endian)

m76ezm.png

This means the stub at 0x0000000000003820(2nd byte of "call rtc_cmos_write" in rtc_correct_wday) will be replaced with rtc_cmos_write's actual address at runtime.

There are a bunch of these stubs which refers to rtc_cmos_write. Since the function rtc_correct_wday looks harmless, let's replace all references to other stubs to the one in this function, 0x0000000000003820. As those stubs won't get filled, we can continue using NOP to skip them.

 

For example, there is "call rtc_cmos_write" in rtc_bandon_rotate_auto_poweron at 0x38c7 and the jumping target address stub begins at 0x38c8 (zeros omitted), then we search for 0xc838

2qaspaa.png

and change it to 0x2038.

120hyc9.png

Do the same for all other stubs in rtc_cmos_write calls. Be careful! Don't leave out any reference to the stubs.

 

Note: all addresses mentioned in step 5 is IDA's instruction address. But since we are searching for hex values, we won't use Goto Offset menu so don't worry about the byte offset.

 

6. Now, relocation won't interfere with our changes about NOP'ping the "call" instrcutions. It's time to change all bytes shown in step 4 to 0x90. Remember, we are not NOP'ping the one in rtc_correct_wday.

 

For example, we are removing the "call rtc_cmos_write" at 0x38c7 (0x3937 for byte offset, use Goto Offset menu).

Change like this: (the argument calculating and passing procedure took a bit more (4) instructions...)

35dawlc.png

Do the same for all other calls to rtc_cmos_write.

 

Note: if you don't know how to determine where the argument passing procedure starts, just ignore it and NOP the call instruction (0xE8 and 4 following bytes). It may work...

 

7. You are all set now. Put the modified file back into the cpio archive, copy to your boot disk, and let Grub load this archive as initrd to override the one inside zImage. If you encounter "No space left" error, you can try resizing the partition and filesystem.

 

Ok guys pls give "updateing" a big thank you for his effort of sharing his work.

 

I am not in the position to verify the solution is workable or not, hopefully the developer can take a look and nail the problem once for all! [emoji106][emoji106][emoji106]

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

  • 2 weeks later...
So here is what I thought and did...

 

From the discussion pages before, we can infer that the BIOS resetting has something to do with the time setting. And from my NanoBoot build tests we know that synobios.ko is the suspect. So I digged into this file.

 

0. Extract vmlinux from zImage from XPEnoboot, then extract ramdisk cpio in the vmlinux (why does XPEnology packs the ramdisk with vmlinux?)

 

1. Extract synobios.ko from ramdisk. Load the file in IDA, and search for time related functions in the function window.

 

2. There is an imported function named rtc_cmos_write, which fits our demand perfectly: time-related(RTC), operates with hardware(cmos_write) (Actually this is an exported function in common Linux kernel) So I decided to remove all calls to this function in order to block writing to the RTC.

bgbmn8.png

 

3. List all the cross references to rtc_cmos_write. This is the common procedure for a call:

t9cbxk.png

l8z81.png

We need to replace all these calls including argument passing procedure with NOP(0x90), which instructs the processor to do nothing when we reach here.

 

4. However, the file looks like this in WinHex: (IDA's Hex View is not showing original file)

5yyg.png

[updated 2016/03/10: Wrong mark on the WinHex side]

This is due to the kernel modules are relocatable. The actual jumping address will be filled during runtime, and there is only a stub after the "call" instrcution. So we need to stop the "address filling".

 

WARNING! Byte offset is different from the instruction offset shown in IDA. You can find the actual byte offset at the bottom left corner of IDA's Hex View. Byte offset should be used for "Navigation -> Goto Offset" in WinHex.

 

5. ELFs use relocation tables for this. Each item in the table tells the linker where we should fill and what to fill with. However I don't know where the table is placed, and all I can do is to search the address of the stubs. The following picture is search results of the first stub (at 0x0000000000003820, presented as 0x2038000000000000 in little-endian)

m76ezm.png

This means the stub at 0x0000000000003820(2nd byte of "call rtc_cmos_write" in rtc_correct_wday) will be replaced with rtc_cmos_write's actual address at runtime.

There are a bunch of these stubs which refers to rtc_cmos_write. Since the function rtc_correct_wday looks harmless, let's replace all references to other stubs to the one in this function, 0x0000000000003820. As those stubs won't get filled, we can continue using NOP to skip them.

 

For example, there is "call rtc_cmos_write" in rtc_bandon_rotate_auto_poweron at 0x38c7 and the jumping target address stub begins at 0x38c8 (zeros omitted), then we search for 0xc838

2qaspaa.png

and change it to 0x2038.

120hyc9.png

Do the same for all other stubs in rtc_cmos_write calls. Be careful! Don't leave out any reference to the stubs.

 

Note: all addresses mentioned in step 5 is IDA's instruction address. But since we are searching for hex values, we won't use Goto Offset menu so don't worry about the byte offset.

 

6. Now, relocation won't interfere with our changes about NOP'ping the "call" instrcutions. It's time to change all bytes shown in step 4 to 0x90. Remember, we are not NOP'ping the one in rtc_correct_wday.

 

For example, we are removing the "call rtc_cmos_write" at 0x38c7 (0x3937 for byte offset, use Goto Offset menu).

The disassembly looks like this:

hx94pu.png

Change like this: (the argument calculating and passing procedure took a bit more (4) instructions...)

35dawlc.png

Then the disassemnly should be like this:

33z347a.png

Do the same for all other calls to rtc_cmos_write.

 

Note: if you don't know how to determine where the argument passing procedure starts, just ignore it and NOP the call instruction (0xE8 and 4 following bytes). It may work...

 

7. You are all set now. Put the modified file back into the cpio archive, copy to your boot disk, and let Grub load this archive as initrd to override the one inside zImage. If you encounter "No space left" error, you can try resizing the partition and filesystem.

 

@updateing

Could you publish your modified version of XPEnoboot ?

Link to comment
Share on other sites

  • 2 weeks later...

Hi,

 

it works for HP MicroserverGen8. All credits go to updateing!

 

#Link

http://www54.zippyshare.com/v/6ktoFqSp/file.html

 

#to load the modified vmlinux place the rd.gz next to syslinux.cfg on your bootstick and change syslinux.cfg

# from

APPEND root=/dev/md0 ihd_num=0 

# to

APPEND root=/dev/md0 initrd=rd.gz ihd_num=0 

 

######## Helpful commands ########

 

#mount bootdrive in ssh session

#!/bin/sh

MOUNT_FOLDER="/root/boot"

mkdir -p ${MOUNT_FOLDER}
LOOP_DEVICE="$(losetup -f)"
losetup -o 32256 ${LOOP_DEVICE} /dev/synoboot
mount -t vfat ${LOOP_DEVICE} ${MOUNT_FOLDER}

 

#unmount bootdrive

#!/bin/sh

umount /root/boot
losetup -d /dev/loop0
rmdir /root/boot

 

# And for the HP Microserver Gen8 users, with this you can change DSM to only see the 4 really existing hdd drives and not the other dummy ones

#in /etc.defaults/synoinfo.conf
#no esata ports
esataportcfg="0x0"
#4 sata ports
internalportcfg="0xf"
#6 usb ports (2 front and 4 back)
usbportcfgo="0x2f0"

Edited by Guest
Link to comment
Share on other sites

This is a disk image of my pen drive (512MB SD card). Plz try if it works or not: https://drive.google.com/file/d/0Bwkmhb ... sp=sharing

 

This file is created by:

1. Download Synoboot: https://github.com/Jman420/nanoBoot-DSM ... 3612xs.img

2. Write the file to pen drive.

3. Expand the partition and filesystem to ~100MB. Expansion of ext filesystem is way easier than FAT, and that is one of the reasons why I choose Synoboot.

4. Replace zImage with *ORIGINAL* XPEnology 5.6-5644.5 one.

5. Compress modified ramdisk (with synobios.ko hax) with gzip as rd.gz

6. Add initrd parameter in /boot/grub/grub.conf.

7. dd if=/dev/sdX of=img

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...