Jump to content
Sign in to follow this  
Followers 0
hst51

Date in bios won't stay put

9 posts in this topic

Recommended Posts

System is Mojave 1.341. Hardware is GA-Z97-HD3/i3/15 gb DDR3 2133/GTX 660

 

When I set the correct time in bios it is changed to an incorrect value upon reboot. Time remains correct in Mojave desktop. Both bios and desktop are configured to use 24 hr. time instead of AM/PM. I changed the CMOS battery and it made no difference. No other bios parameters are affected, just the time. Latest bios is installed I believe.

 

In researching this the only hits that turned up had to do with dual boot Mac OS/Windows or dual boot Linux/Windows. This is not a dual boot machine.

 

Any idea as to why this is happening?

 

Thanks

Share this post


Link to post
Share on other sites
Advertisement

By that I mean the time is no longer correct in bios. It has changed by hours upon reboot within a few minutes of setting and saving it in bios.

Edited by hst51

Share this post


Link to post
Share on other sites

Sig created.

 

What do those acronyms stand for? I find lots of information talking about them when I google but nothing explaining what they are.

RTC

DSDT

SSDT

Share this post


Link to post
Share on other sites

@hst51

its normal that the bios time is different from macOS. i dont know how to explain it well, probably something to so with UTC vs ????.

dsdt nor clover has nothing to do with it.

 

But thats how it just works.

Edited by ellaosx

Share this post


Link to post
Share on other sites

Thank you for your reply and explanation and the bios time being altered. I have found this same effect when running Linux.

 

I modified my search string and found some answers to my question about the acronymns:

 

Found this about DSDT: The Differentiated System Description Table is the main table in the ACPI part of a computer's BIOS.

 

And RTC: A real-time clock (RTC) is a battery-powered clock that is included in a microchip in a computer motherboard.

 

And SSDT: System Service Description Table, an internal data structure within Microsoft Windows. MAC OS must have one too.

Edited by hst51

Share this post


Link to post
Share on other sites

You dont need to worry a thing as to why its not synced.

there are patches to make time synced in macOS & Windows.

Edited by ellaosx

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
Followers 0

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By kromakey
      Hello ,
       
      Just changed my CPU to a E5450 to be able to Run Mojave , but now I can not run not even EL Capitan    (it was working well with CORE2DUO)
       
      I already flashed a modified bios to be able to recognise the CPU.
       
      here some print screens from Verbose :
       
      https://photos.app.goo.gl/kqWauSu5GZ9Kogxh7
       
      https://photos.app.goo.gl/F6kL5YbiFBqLcGyz6
       
       
      AZUS P5K PRO  - CPU E5450 - NVIDIA 9600GT - 5G RAM 
       
       
      ANY HELP is APPRECIATED
       
      Thanks/Obrigado
       
      Kromakey 
       
       
       
       
    • By ciriousjoker
      TLDR:
      I'm trying to boot MacOS on a Chromebook without UEFI. I'm stuck at getting the bootloader (Chameleon/Clover) to work.  
      My setup / context:
      I have an Acer Chromebook Spin 13.
      Available ports:
      2 x USB-C 1 x USB-A 3.0 MicroSD Slot No USB A 2.0 (I've read that Clover has problems with USB 3.0) Firmware:
      There's no UEFI firmware available and by default, it doesn't even allow booting anything other than ChromeOS. Thanks to MrChromebox (big shoutouts!), I flashed a custom legacy bios that allows me to boot anything linux related. This bios is flashed into the RW_LEGACY section of the existing bootloader (coreboot afaik) and doesn't have any configuration options. If I have to change a setting, I could try compiling his bios payload myself with the specific setting enabled.  
      What I've tried so far:
      Chameleon attempts:
      Only selected setting was "Install chameleon on the chosen path", rest was unselected.
       
      1 - Install chameleon first without restoring the basesystem:
      Output:
      > boot0: GPT
      > boot0: done
      (hangs; pressing power button once shuts down
      Chameleon installation log is attached as "Chameleon_Installer_Log_BEFORE".
       
      2 - Install Chameleon after restoring the base system:
      Output:
      > boot0: GPT
      > boot0: GPT
      > boot0: doneboot1: /boot       <- Exactly like that, no line break in between
      (hangs; pressing power button once shuts down)
       
      I haven't been able to reproduce #2 after wiping the drive and doing the same thing again. Subsequent attempts have resulted in either #1 of either Chameleon or Clover.
      Chameleon installation log is attached as "Chameleon_Installer_Log_AFTER".
       
      Clover attempts:
      I tried multiple settings and configurations, but all of them boiled down to either one of these.
       
      1 - Doesn't do anything, just hangs at "Booting from usb..."
      2 - Boots into the blue/grey mode as shown in the attached images.
      According to MrChromebox, this could be an old Tianocore DUET It doesn't detect anything (cpu frequency, ram, partitions or disks)  
      I've read pretty much every article, github readme and other types of documentation for coreboot, tianocore, clover, chameleon and MrChromebox' rw_legacy payloads and right now, I'm totally clueless as to what to try next...
       
      A few questions that came up:
      Why does chameleon hang? What is it looking for, /boot was clearly written to the disk by the Chameleon installer? What exactly is the blue/grey image? According to MrChromebox, it could be Tianocore DUET Where does it come from? Clover? The mainboard itself? Why does the blue/grey thing not detect my processor frequency or any partitions/drives? Can I use some sort of DUET bootloader to chainload Clover?  
      If you guys could answer any of them or if you have any other guesses or information as to what's happening, I'd be really happy!
      Chameleon_Installer_Log_BEFORE.txt
      Chameleon_Installer_Log_AFTER.txt





    • By Oschly
      Hi! I have a problem with 10.14.4 on booting stage (photo).
      My specs:
       
      MOBO: Z390 MAG Tomahawk
      CPU: i7-8700k
      GPU: RX 580 Nitro+
      Wifi: BCM4331CD
      RAM: Corsair Vengeance LPX 3000MHz 16CL
       
      I've updated every kext and driver (clover version too) and only difference is that I don't have lines informing about not loading kexts (common issue here as I see).

    • By mikmavros
      Thanks for accepting
      I recently installed Sierra  and I encounter the following problem ... When I restart or I start up my machine return to BIOS. If anyone knows and can any help be valuable Thank you very much. (When I boot from a Capitan disk in the same machine all  is running well.) Both discs with Clover in Legacy mode.
      gigabyte z68x-ud5-b3 F8
      I7 2600K
      GT 620 ( την βλέπει κανονικά χωρίς Web drivers)
      16 GB ddr3 1600 


    • By ludufre
      [GUIA] Correção de assinatura BIOS Insyde H2O
       
      Recentemente comprei um notebook Lenovo L440 pra instalar o macOS Mojave e fui substituir a placa wireless pela DW1560 porque a atual não é compatível. Descobri que existia uma whitelist de placas permitidas que as fabricantes estão adotando recentemente (no meu caso utiliza uma bios Phoenix Insyde BIOS H2O).
       
      Procurei em fórums de BIOS MODDING e encontrei pessoas que fizeram o patch pra mim. Só que após substituir a BIOS notei que o computador ficava apitando 5 vezes todas vez que ligava e fui me aprofundar no caso. E foi aí que descobri como resolver isso e por isso criei esse guia baseado nas informações que achei em alguns fóruns russos.
       
       
      Prefácio
       
      Quando a BIOS falha no teste te integridade, algumas funcionalidades Intel AMT param de funcionar e é emitido uma sequência de 5 apitos duas vezes no boot.
      Após modificar para remover whitelist (habilitar placas WI-FI não autorizadas), destravar MSR 0xe2 (hackintosh), habilitar menu avançado, etc. a BIOS não vai passar no teste de integridade causando esse problema.
      Essa verificação de integridade é feita através da assinatura RSA do bloco da BIOS chamado TCPABIOS (mais informações abaixo) com a chave pública no formato modulus 3 também armazenada na BIOS.
      Esse bloco TCPABIOS armazena os checksums de cada volume da BIOS.
       
      O que faremos é gerar novos checkums para esses volumes que foram modificados, gerar um para de chaves RSA (privada e pública), assinar esse bloco com a chave privada e substituir a chave pública.
       
       
      Ferramentas necessárias
       
      - EFITool NE alpha 54: https://github.com/LongSoft/UEFITool/releases
      - HxD 2.1.0: https://mh-nexus.de/en/hxd/
      - OpenSSL: http://gnuwin32.sourceforge.net/packages/openssl.htm (Download -> Binaries)
      - Microsoft File Checksum Integrity Verifier (FCIV.exe): https://www.microsoft.com/en-us/download/details.aspx?id=11533
       
      Passo a passo
       
      Vamos abrir a BIOS modificada, localizar o bloco TCPABIOS e entender sua anatomia.
       
      1. Abra a BIOS no HxD
       

      (Vamos utilizar nesse guia a BIOS modificada no fórum MyDigitalLife.com pelo usuário Serg008 para o notebook Lenovo B590)
       
      2. Busque a palavra TCPABIOS:
       


       
      3. O bloco começa com TCPABIOS e termina com antes de TCPACPUH
       

       
      4. Anatomia:
       
      54 43 50 41 42 49 4F 53 48 31 38 34 61 31 31 2F
      32 36 2F 31 33 49 42 4D 53 45 43 55 52 00 FD 27
      34 2A 35 AB 41 26 39 E3 32 E5 B6 8A D6 49 5B 0B
      77 F9 82 58 48 00 00 00 CE 18 1F 00 00 00 03 00
      00 00 00 00 00 00 27 00 00 00 00 00 00 00 00 00
      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      00 00 00 00 00 00 00 00 00 00 00 FF FF 83 04 D4
      52 52 95 C5 D7 21 55 78 0E 5C AD 47 EE C4 3D 1D
      C1 EC 69 03 2B 51 A5 42 61 96 22 F9 7B 88 57 B7
      A8 9D D0 20 DB 5B 11 10 55 07 84 6C 62 DF FA 2F
      6A A8 43 0C 8A 40 AF 79 0D 31 DB 5A 5D C8 2F EB
      F8 7C 87 B0 A6 3D 2A 88 AE 91 9D 88 E3 AA 85 E3
      5A B3 91 7F 28 68 1F BA 92 C4 7E 10 F5 1A 7E 75
      A9 6F CE C0 4F BA FA 79 A5 98 2B 50 60 BA 09 73
      7B 03 D1 0C 3E A2 9C 44 DF E9 F2 92 34 7B
       
      Cinza: Nome e informações do bloco
      Vermelho: Informações dos volumes (Checksum e Cabeçalho)
      Azul: Separação da lista de volumes para a assinatura do bloco
      Verde: Assinatura do bloco TCPABIOS são os últimos 128 bytes
       
      Lista de Volumes:
       
      Cada volume tem o formato: 00 FD 27 34 2A 35 AB 41 26 39 E3 32 E5 B6 8A D6 49 5B 0B 77 F9 82 58 48 00 00 00 CE 18 1F 00 00 00 03 00 00 00 00 00
                                                      (prefixo 3 bytes + checksum 20 bytes + offset 4 bytes + tamanho do volume 6 bytes + separador do fim 6 bytes)
       
      Os volumes são enumerados e utilizam o primeiro byte no prefixo para isso (00 FD 27), começando do 0.
      A BIOS utilizada nesse exemplo possui somente um volume, mas no caso de mais de um volume, seria: 00 FD 27 .., 01 FD 27 ..., 02 FD 27 ...
      - Checksum é o cálculo SHA1 do volume.
      - Offset é a posição do volume dentro da BIOS. Os bytes ficam invertidos, nesse caso seria 00 00 00 48 ou seja: 48h
      - Tamanho do volume também está com os bytes invertidos, então: 1F18CEh
       
      Então é isso. Precisamos corrigir essas informações (checksum, offset e tamanho)
       
      5. Para extrair os volumes abra a BIOS com o UEFITool e veja como identificar os volumes (nosso exemplo há somente um volume, se houvessem outros estariam também dentro de EfiFirmwareFileSystemGuid):
       

       
      Na BIOS original, circulado em vermelho podemos ver o nosso volume.
      Observe que em azul temos Offset e verde o tamanho. Exatamente como verificamos acima no HxD. Já na BIOS modificada vemos que está diferente o tamanho:
      Oridinal: 1F18CEh
      Modificada: 1F12D5h (vamos precisar disso mais tarde)
       
      6. Vamos extrair esse volume escolhendo a opção “Extract as is...”
       
       
       
      7. Utilize esse comando para obter o checkum desse volume: fciv.exe -sha1 File_Volume_image_FvMainCompact.ffs
       

       
      Agora temos o checksum que é 396e0dc987219b4369b1b9e010166302ce635202
       
      8. Substitua as informações no bloco TCPABIOS:
       

       
      Observe que o tamanho do volume precisa ter os bytes invertidos, então se o total são 6 bytes e é 1F12D5h, fica D5 12 1F 00 00 00 no lugar de CE 18 1F 00 00 00.
      Se o offset for diferente, também realizar o mesmo procedimento invertendo os bytes.
      Checksum alterar de 34 2A 35 AB 41 26 39 E3 32 E5 B6 8A D6 49 5B 0B 77 F9 82 58 para 39 6E 0D C9 87 21 9B 43 69 B1 B9 E0 10 16 63 02 CE 63 52 02
       
      Faça esse procedimento para cada volume na BIOS.
       
      9. Agora precisamos gerar o checksum de todo o bloco TCPABIOS mas sem considerar os últimos 131 bytes, ou seja desconsiderar de FF FF 83 + 80 bytes da assinatura anterior.
       
      Copie para um novo arquivo no HxD e salve como tcpabios
       

       
      Utilize o comando para gerar o checksum desse bloco: fciv.exe -sha1 tcpabios
       

       
      Checksum do bloco TCPABIOS: 0da6715509839a376b0a52e81fdf9683a8e70e52
       
      Crie um novo arquivo no HxD e adicione 108 bytes com 00 e cole o checksum no final e salve como tcpabios_sha, ficando assim:
       

       
      10. Agora vamos gerar a chave privada RSA com modulus 3: openssl genrsa -3 -out my_key.pem 1024
       

       
      Assinar o arquivo tcpabios_sha: openssl rsautl -inkey my_key.pem -sign -in tcpabios_hash -raw > tcpabios_sign
       

       
      Agora aproveite para gerar a chave publica: openssl rsa -in my_key.pem -outform der -pubout -out my_key_pub.der
       

       
      E gerar modulus 3 da chave pública: openssl rsa -pubin -inform der -in my_key_pub.der -text -noout
       

       
      Copie e cole a chave em um arquivo de texto para utilizar daqui a pouco. Remova todos os “:” e coloque tudo em uma única linha, ficando assim:
       

       
      11.   Abra o arquivo tcpabios_sign no HxD, copie o conteúdo e substitua a assinatura no final do bloco TCPABIOS:
       
       
       
      12. Agora vamos localizar na BIOS o local da chave pública e substituir. Essa chave começa com 12 04 e termina com 01 03 FF e fica após o bloco TCPABBLK.
       
      A chave fica assim: 12 04 + 81 bytes + 01 03 FF. Faça uma busca por 01 03 FF para localizar mais facilmente. Verifique se antes dos 81 bytes tem os bytes 12 04 para ter certeza que achou.
       

       

       
      Agora substitua pela chave pública que ficou anotado no arquivo de texto anteriormente, ficando assim:
       

       
       
      Salve e está pronto. Sua BIOS está assinada e pronta.
       
×