BRPI0806729A2 - suporte de múltiplos sistemas operacionais em dispositivos de mìdia - Google Patents

Abstract

SUPORTE DE MúLTIPLOS SISTEMAS OPERACIONAIS EM DISPOSITIVOS DE MìDIA. Técnicas e ferramentas para o suporte de múltiplos sistemas operacionais nos dispositivos eletrónicos de consumidor. Por exemplo, as técnicas e ferramentas são descritas permitindo a permuta rápida entre os sistemas operacionais em aparelhos de disco de vídeo que suportam tipos de mídia diferentes enquanto reduzem o tempo de espera e mitigam os possíveis impactos negativos para a experiência do usuário.

Description

"SUPORTE DE MÚLTIPLOS SISTEMAS OPERACIONAIS EM DISPOSITIVOS DE MÍDIA"

Fundamentos

Formatos de mídia para dispositivos eletrônicos de consumidor estão se tornando cada vez mais complicados, enquanto também movem muito de sua funcionalidade avança- da de hardware para software. Como resultado disso, os ambientes de software dos disposi- tivos eletrônicos de consumidor têm se tornado cada vez mais complicados.

Adicionalmente, formatos mais antigos e mais simples tal como DVD ainda deixam parte de seu processamento para o software apesar de descarregarem o muito de seu pro- cessamento em hardware mais barato e mais simples. Por exemplo, enquanto seqüências de áudio e vídeo devem ser decodificadas por hardware dedicado, a funcionalidade de pro- cessamento de menu (ou "navegação") pode ser implementada em software. Enquanto o software de navegação básica pode ser relativamente simples, o mercado e DVD evoluiu com o tempo. Os aparelhos de DVD têm respondido com lógica de processamento de menu complicada para manusear corretamente DVDs com mais características. Como resultado disso, o formato de DVD relativamente simples evoluiu de forma que seu software de repro- dução é agora bem complicado. Muitos fabricantes de aparelhos possuem um investimento significativo nesse software, e o software evoluiu com o tempo de forma a ter dependências de seus ambientes operacionais.

Com diferentes formatos de mídia disponíveis, existe uma necessidade de os dis- positivos eletrônicos de consumidor suportarem múltiplos formatos. Por exemplo, quando se considera que os usuários geralmente esperam que seus aparelhos de DVD também repre- duzam discos de Áudio CD, que é um formato de mídia muito diferente, se torna claro que o suporte de múltiplos formatos é desejável. Um problema a ser solucionado, então, é como rodar múltiplos aplicativos de software que podem exigir seus próprios sistemas operacio- nais de forma barata.

Sumário

Esse sumário introduz uma seleção de conceitos de uma forma simplificada que são adicionalmente descritos abaixo na Descrição Detalhada. Esse sumário não pretende identificar características chave ou características essenciais da matéria reivindicada, nem está restrito a ser utilizado para limitar o escopo da matéria reivindicada.

Em suma, a Descrição Detalhada é direcionada a várias técnicas e ferramentas pa- ra suportar múltiplos sistemas operacionais nos dispositivos eletrônicos de consumidor. Por exemplo, as técnicas e ferramentas são descritas e permitem a comutação rápida entre sis- temas operacionais em aparelhos de discos de vídeo que suportam tipos diferentes de mídia enquanto reduz o tempo de espera e mitiga os possíveis impactos negativos para a experi- ência do usuário. Características e vantagens adicionais serão tornadas aparentes a partir da descri- ção detalhada a seguir de várias modalidades que prossegue com a referência aos dese- nhos em anexo.

Breve Descrição dos Desenhos

A figura 1 é um diagrama em bloco ilustrando um exemplo generalizado de um am- biente de computação adequado no qual várias das modalidades descritas podem ser im- plementadas;

A figura 2 é um fluxograma ilustrando uma técnica ilustrativa para um modelo de "graceful-handoff" de manuseio de mudanças de característica entre diferentes sistemas operacionais de acordo com uma ou mais implementações descritas;

A figura 3 é um fluxograma ilustrando uma técnica ilustrativa para um modelo "warm-boot" de manuseio de mudanças de característica entre diferentes sistemas opera- cionais de acordo com uma ou mais implementações descritas.

A figura 4 é um fluxograma ilustrando uma técnica ilustrativa para o manuseio de graceful-handoff das mudanças de formato de disco de acordo com uma ou mais das im- plementações descritas;

A figura 5 é um diagrama de sistema ilustrando firmware com um carregador de ini- cialização e serviços BIOS para o manuseio de mudanças de formato de disco de acordo com uma ou mais das implementações descritas;

A figura 6 é um fluxograma ilustrando uma técnica ilustrativa para o manuseio warm-boot das mudanças de formato de disco de acordo com uma ou mais implementações descritas;

A figura 7 é um fluxograma ilustrando uma técnica ilustrativa para a realização de operações de comutação de formato de mídia warm-boot em paralelo de acordo com uma ou mais implementações descritas.

Descrição Detalhada As técnicas e ferramentas para suportar sistemas operacionais, por exemplo, em dispositivos embutidos tal como aparelhos de reprodução de mídia, são descritas aqui.

Várias alternativas às implementações descritas aqui são possíveis. Por exemplo, determinadas técnicas descritas com referencia aos fluxogramas podem ser alteradas pela alteração da ordenação dos estágios ilustrados nos fluxogramas, pela repetição ou omissão de determinados estágios, etc. enquanto alcança os mesmos resultados. Diferentes modali- dades implementam uma ou mais das técnicas descritas e ferramentas. Algumas das técni- cas e ferramentas descritas aqui solucionam um ou mais dos problemas anotados nos Fun- damentos. Tipicamente, uma determinada técnica/ferramenta não soluciona todos os pro- blemas, no entanto.

I. Ambiente Computacionalb A figura 1 ilustra um exemplo generalizado de um ambiente computacional adequa- do (100) no qual várias das modalidades descritas podem ser implementadas. O ambiente computacional (100) não pretende sugerir qualquer limitação quanto ao escopo do uso ou funcionalidade, visto que técnicas e ferramentas podem ser implementadas em ambiente computacionais de finalidade especial ou de finalidade geral diversos. Por exemplo, o ambi- ente computacional (100) pode ser fornecido com um dispositivo de mídia tal como um apa- relho de áudio portátil, aparelho de vídeo portátil, aparelho de áudio e vídeo portátil, apare- lho de áudio de console, aparelho de vídeo de console ou aparelho de áudio e vídeo conso- le. Tal dispositivo de mídia pode ser uma unidade independente ou incluída em outro dispo- sitivo (por exemplo, dispositivo de comunicações ou unidade de exibição).

Com referência à figura 1, o ambiente de computação (100) inclui pelo menos duas unidades de processamento (110, 115) e memória associada (120, 125). As unidades de processamento (110, 115) podem incluir uma CPU, uma GPU para aceleração de vídeo, ou outras unidades de coprocessamento. Na figura 1, essa configuração mais básica (130) é incluída dentro de uma linha tracejada. Alternativamente, o ambiente de computação inclui uma unida unidade de processamento. As unidades de processamento (110, 115) executam as instruções executáveis por computador e podem ser processadores reais ou virtuais. Em um sistema de multiprocessamento, as múltiplas unidades de processamento executam ins- truções executáveis por computador para aumentar a potência de processamento. Nas situ- ações de codificação ou decodificação, um processo codificador ou decodificador hospedei- ro utiliza as unidades de processamento disponíveis (110, 115) para realizar as operações de codificação e decodificação. Determinadas operações podem ser realizadas por uma unidade de processamento especializada tal como uma GPU. A memória (120, 125) pode ser uma memória volátil (por exemplo, registros, cache, RAM); uma memória não volátil (por exemplo, ROM, EEPROM, memória flash, etc.), ou alguma combinação das duas. A memó- ria (120, 125) pode ser específica para um processador ou compartilhada por dois ou mais processadores. A memória (120, 125) armazena software (180) para um dispositivo imple- mentando estratégias para suportar múltiplos sistemas operacionais.

Um ambiente de computação pode ter características adicionais. Por exemplo, o ambiente de computação (100) inclui o armazenamento (140), um ou mais dispositivos de entrada (150), um ou mais dispositivos de saída (160), e uma ou mais conexões de comuni- cação (170). Um mecanismo de interconexão (não ilustrado) tal como um barramento, con- trolador ou rede interconecta os componentes do ambiente de computação (100). Tipica- mente, o software do sistema operacional (não ilustrado) fornece um ambiente operacional para outro software executando no ambiente de computação (100), e coordena atividades dos componentes do ambiente de computação (100).

O armazenador (140) pode ser removível ou não removível, e inclui discos magné- ticos, fitas magnéticas, CD-ROMs1 DVDs, ou qualquer outro meio que possa ser utilizado para armazenar informação e que possa ser acessado dentro do ambiente de computação (100). O armazenador (140) armazena as instruções para o software (180).

Os dispositivos de entrada (150) podem ser um dispositivo de entrada de toque tal como um teclado, mouse, caneta, tela de toque, TrackBaII, um dispositivo de entrada de voz, um dispositivo de digitalização, ou outro dispositivo que forneça entrada para o ambien- te de computação (100). Para áudio ou vídeo, os dispositivos de entrada (150) podem ser um cartão de som, um cartão de vídeo, um cartão de sintonizador de TV ou dispositivo simi- lar que aceite a entrada de áudio ou vídeo em forma analógica ou digital, ou um DVD, CD- ROM, ou CD-RW que leia áudio ou vídeo codificado no ambiente computacional (100). Os dispositivos de saída (160) podem ser um monitor, impressora, alto falante, gravador de CD ou DVD, ou outro dispositivo que forneça saída do ambiente de computação (100).

As conexões de comunicação (170) permitem a comunicação através de um meio de comunicação para outra entidade de computação. O meio de comunicação porta infor- mação tal como instruções executáveis por computador, entrada de áudio ou vídeo ou saí- da, ou outros dados em um sinal de dados modulado. Um sinal de dados modulado é um sinal que possui uma ou mais de suas características configuradas ou alteradas de tal forma a codificar a informação no sinal. Por meio de exemplo, e não de limitação, a mídia de co- municação inclui técnicas com ou sem fio implementadas com uma freqüência elétrica, óti- ca, de rádio ("RF"), infravermelho ("IR"), acústica, ou outro portador.

As técnicas e ferramentas podem ser descritas no contexto geral de mídia legível por computador. A mídia legível por computador são qualquer mídia disponível que possa ser acessada dentro de um ambiente computacional. Por meio de exemplo, e não de limita- ção, com o ambiente computacional (100), a mídia legível por computador inclui memória (120), armazenador (140), mídia de comunicação e combinações de qualquer um dos aci- ma.

As técnicas e ferramentas podem ser descritas no contexto geral das instruções executáveis por computador, tal como as incluídas nos módulos de programa, sendo execu- tadas em um ambiente de computação em um processador virtual ou real alvo. Geralmente, os módulos de programa incluem rotinas, programas, bibliotecas, objetos, classes, compo- nentes, estruturas de dados, etc. que realizam tarefas em particular ou implementam tipos de dados abstratos particulares. A funcionalidade dos módulos de programa pode ser com- binada ou dividida entre os módulos de programa como desejado em várias modalidades. As instruções executáveis por computador para os módulos de programa podem ser execu- tadas dentro de um ambiente de computação distribuído ou local.

Para fins de apresentação, a descrição detalhada utiliza os termos como "verifica- ção" e "acordar" para descrever operações de computador em um ambiente de computação. Esses termos são abstrações de alto nível para operações realizadas por um computador, e não devem ser confundidos com atos realizados por um ser humano. As operações de com- putador reais correspondendo a esses termos variam dependendo da implementação.

II. Estratégias para Suportar Múltiplos Sistemas Operacionais em Dispositivos Ele- trônicos de Consumidor

Os dispositivos eletrônicos de consumidor estão se tornando cada vez mais compli- cados e estão movendo o suporte para muito de sua funcionalidade de hardware para soft- ware. Os formatos mais antigos e mais simples tal como DVD freqüentemente deixam parte de seu processamento para o software apesar de descarregarem tipicamente muito de seu processamento para hardware mais barato e mais simples. Por exemplo, as seqüências de áudio e vídeo podem ser decodificadas por hardware dedicado, enquanto a funcionalidade de processamento de menu (ou "navegação") pode ser implementada em software. Como resultado disso, alguns dispositivos eletrônicos de consumidor que suportam formatos relati- vamente simples tal como DVD, não obstante, evoluíram para ter software complicado.

Adicionalmente, as ferramentas de reprodução para formatos de mídia diferentes podem ter diferentes exigências de sistema operacional e podem complicar ainda mais os ambientes de software dos dispositivos que manuseiam as mesmas. Por exemplo, o conte- údo de vídeo de alta definição codificado de acordo com o padrão de disco de vídeo DVD HD (algumas vezes referido aqui como um formato HD DVD) pode ser decodificado utilizan- do um aplicativo de reprodução suportado por um primeiro sistema operacional (tal como o sistema operacional Windows® CE da Microsoft Corporation ou outro sistema operacional), e o conteúdo de vídeo de alta definição codificado de acordo com o padrão de disco de ví- deo Blu-ray (algumas vezes referido aqui como formato Blu-ray) pode ser decodificado utili- zando um aplicativo de reprodução suportado por um segundo sistema operacional (tal co- mo o sistema operacional com base em Linux, outro sistema operacional tipo Unix ou variá- vel de Unix, ou outro sistema operacional). Os discos de formato duplo (por exemplo, discos com conteúdo de formato Blu-ray e conteúdo em formato HD DVD) podem ainda ter outras exigências de sistema operacional. Algum software projetado para ambientes operacionais particulares evoluíram com o tempo para depender desses ambientes operacionais. Como resultado desses e outros fatores, os dispositivos eletrônicos de consumidor apresentam ambientes de software cada vez mais complicados.

Um problema a ser solucionado pelos dispositivos eletrônicos de consumidor é co- mo rodar múltiplos aplicativos de software (cada um dos quais pode exigir seu próprio sis- tema operacional) de forma barata. Uma solução é se incluir um processador, completo com o sistema operacional e aplicativo de software, para cada tipo de formato de mídia suporta- do. Uma solução mais barata é se armazenar múltiplos sistemas operacionais e aplicativos de software (por exemplo, até um sistema operacional e aplicativo de software por formato de mídia) e fazer com que o aparelho reinicialize quando um tipo diferente de mídia é pro- cessado. Por exemplo, um aparelho pode ter um sistema operacional para HD DVD, outro para DVD, e outro para áudio CD. O mapeamento entre os sistemas operacionais e aplicati- vos suportados não precisa ser de uma para um. Por exemplo, a reprodução de áudio CD e DVD pode rodar em um sistema operacional, enquanto a reprodução HD DVD roda em um sistema operacional diferente.

No entanto, existem problemas em potencial associados com rodar múltiplos siste- mas operacionais. Considere-se um dispositivo que suporta dois formatos de mídia de disco de vídeo digital: O formato HD DVD rodando em um primeiro sistema operacional, e o for- mato Blu-ray (algumas vezes referido como formato de Disco Blu-ray) rodando em um se- gundo sistema operacional muito diferente do primeiro sistema operacional. Um problema a ser considerado é o tempo de carregamento de disco quando da transição de um formato para outro (por exemplo, reprodução Blu-ray, suportada utilizando o segundo sistema ope- racional, para a reprodução de vídeo HD DVD, suportada utilizando o primeiro sistema ope- racional). Outro problema a ser considerado é como permitir que usuários mudem entre múl- tiplos aplicativos de software (que exigem seus próprios sistemas operacionais) enquanto mantém o comutador entre os sistemas operacionais invisíveis para o usuário para reduzir o impacto negativo em potencial na experiência do usuário.

As técnicas de "múltiplas inicializações" descritas e ferramentas permitem que os dispositivos comutem entre os sistemas operacionais com baixo custo e sem interferência indevida para a experiência do usuário. Nas descrições aqui, o termo "inicialização dupla" é algumas vezes utilizado para descrever um dispositivo que comuta entre dois sistemas ope- racionais, apesar de idéias discutidas aqui poderem ser estendidas a dispositivos que são capazes de rodar mais de dois sistemas operacionais. Os dispositivos de inicialização dupla com dois sistemas operacionais disponíveis são um subconjunto de dispositivos de múltiplas inicializações, que podem ter dois ou mais sistemas operacionais disponíveis. Os termos múltiplas inicializações e inicialização dupla não indicam uma exigência que o dispositivo deva reinicializar para comutar entre os sistemas operacionais, como explicado em detalhes abaixo.

As opções para desenhos de múltiplas inicializações incluem o seguinte:

1. Transições de sistema operacional são manuseadas com um mecanismo de handoff cooperativo (ou graceful handoff) no qual dois ou mais sistemas operacionais estão operando simultaneamente. Por exemplo, em uma implementação descrita um handoff entre um primeiro sistema operacional e um segundo sistema operacional e realizado enquanto ambos os primeiro e segundo sistemas operacionais são mantidos rodando. Um sistema operacional é deixado em um estado inativo depois do handoff.

2. Transições do sistema operacional são manuseadas com um mecanismo de handoff que envolve um warm boot para um dos sistemas operacionais. 0 termo "warm bo- ot" é utilizado aqui para se referir a uma inicialização de um sistema operacional em um dis- positivo que ocorre depois que o dispositivo já foi energizado, com um sistema operacional carregado.

A seleção entre as opções de desenho de múltiplas inicializações pode depender de um número de fatores, tal como: seleção de chip (por exemplo, núcleo único ou núcleo duplo), custo da implementação e dependências externas. Muitos desenhos de chip possu- em um número de processador único e suportam um sistema operacional de cada vez (a menos que o seqüenciamento de hardware de baixo nível ou outra tecnologia forneça supor- te para rodar simultaneamentõe os múltiplos sistemas operacionais). Outros desenhos de chip possuem dois núcleos processadores, e um único sistema operacional ciente do multi- processamento simétrico tipicamente não utiliza ambos os mesmos. Em qualquer caso, as escolhas de desenho de sistema em um chip freqüentemente dependem de mais de apenas os núcleos de processador, considerando também outras unidades funcionais em um chip tal como as unidades para decodificação de áudio/vídeo, aceleração gráfica 2D, descripto- grafia, etc.

A. Exemplos

Os exemplos a seguir ilustram as técnicas para o manuseio de transições entre os sistemas operacionais e a conta de tais fatores como tempo de transição e impacto potenci- al na experiência do usuário. Exemplos nessa seção descrevem a comutação entre dois sistemas operacionais, mas é possível se comutar entre mais de dois sistemas operacio- nais. Nas implementações alternativas, as etapas ilustradas nos exemplos abaixo podem ser reordenadas, omitidas ou substituídas por etapas diferentes. Por exemplo, exemplos que descrevem a comutação do sistema operacional A para o sistema operacional B podem ser estendidas para comutar de vota para o sistema operacional A por padrão após uma carac- terística solicitada do sistema operacional B não estar sendo mais utilizada, ou em resposta a uma ação de usuário subseqüente que utiliza uma característica no sistema operacional A. As transições entre os sistemas operacionais pode continuar enquanto necessárias ou dese- jadas. Exemplos nos quais o sistema operacional A é um sistema operacional primário ou inicial podem ser modificados de forma que o sistema operacional B seja o sistema opera- cional primário ou inicial, ou vice-versa.

Os exemplos são implementados com um aparelho de mídia digital, que pode ser um dispositivo isolado ou incluído como parte de outro dispositivo. Alternativamente, os e- xemplos são implementados com outros dispositivos eletrônicos de consumidor ou outro dispositivo de computação.

1. Exemplos de Graceful-Handoff

Exemplo 1: Nessa situação de graceful-handoff, um dispositivo eletrônico de con- sumidor é configurado para permitir que o sistema operacional Aeo sistema operacional B rodem simultaneamente. Nesse exemplo, o sistema operacional A é o sistema operacional primário e controla no momento a maior parte dos aspectos do dispositivo. Detecta que um usuário está tentando utilizar uma característica fornecida pelo sistema operacional B (por exemplo, colocando um disco de vídeo de um formato particular dentro do dispositivo). O processo do exemplo 1 inclui as etapa a seguir:

1. Armazenamento das exigências de característica identificadas (por exemplo no armazenamento não volátil).

2. Liberação do controle de recursos de hardware que serão utilizados pelo sistema operacional B (se necessário).

3. Transferência do controle para o sistema operacional B.

4. Determinação (com o sistema operacional B) da característica necessária pela leitura dos dados armazenados na etapa 1, acima.

5. Ativação, se necessário, e utilização (com o sistema operacional B) dos recursos de hardware necessários para satisfazer as exigências da característica. A transição de um sistema operacional para outro pode ser realizada graciosamente para alguns recursos de hardware (por exemplo, monitores), de forma que seu estado (por exemplo, exibindo atual- mente um menu) seja completamente ou parcialmente persistido através do handoff do sis- tema operacional A para o sistema operacional B a fim de reduzir o tempo de transição e/ou mitigar o impacto negativo na experiência de usuário.

6. Fornecimento (com o sistema operacional B) da característica desejada. Na etapa 3, do exemplo 1, o controle é transferido para o sistema operacional B pe- lo envio de uma ou mais mensagens para o sistema operacional B. Essas mensagens po- dem ser implementadas de várias formas. Por exemplo, em algumas implementações, cada sistema operacional/núcleo processador (onde o sistema operacional A roda no número processador A, e o sistema operacional B roda no núcleo processador B) possui um aciona- dor no mesmo que implementa uma fila de correio de hardware. As filas de correio podem ser filas simples de primeiro a entrar/primeiro a sair utilizadas para o envio de mensagens entre o sistema operacional Aeo sistema operacional B. Um componente de controle para o sistema operacional (por exemplo, no acionador) espera pela chegada de uma mensagem em sua fila para instruir a mesma a colocar seu sistema operacional e núcleo para dormir. A mensagem pode ser uma palavra da memória cujos valores são reservados para fins de graceful handoffs entre os sistemas operacionais (por exemplo, o valor 1 indica que o com- ponente de controle deve colocar seu sistema operacional/núcleo para dormir, o valor 2 indi- ca que o componente de controle deve acordar seu sistema operacional/núcleo de um esta- do de sono, e outros valores são reservados para outros fins). Alternativamente, o envio de mensagem é implementado com outros protocolos e/ou outro tipo de estrutura de dados. Em uma implementação de fila de correio ilustrativa, quando o sistema operacional A detecta um disco em um formato que não reproduz, o mesmo envia uma mensagem (por exemplo, com um valor de 2) para seu acionador de envio de mensagens, que distribui a mensagem para a fila de correio do acionador do sistema operacional Β. O acionador para o sistema operacional B espera pelas mensagens em sua fila de correio, recebe a mensagem do sistema operacional A, interpreta a mensagem (cujo valor indica "acordar") e realiza as etapas de acordar o sistema operacional Beo núcleo B (por exemplo, reativando os acio- nadores como adequado). O sistema operacional A se coloca para dormir depois que envia a mensagem de acordar para o sistema operacional B, assumindo que o sistema operacio- nal B acorde. Alternativamente, o sistema operacional A espera por uma mensagem do sis- tema operacional B (por exemplo, com um valor de 1) instruindo um sistema operacional A a se colocar no modo latente. Fazendo com que o sistema operacional B envie tal mensagem após o sistema operacional B ter acordado permite um melhor manuseio de erro - se o sis- tema operacional A não receber tal mensagem de entrar no modo latente depois de algum período de tempo, o sistema operacional A pode iniciar o manuseio de erro informando o usuário, reinicializando todo o sistema e/ou realizando outras etapas.

O processo de envio de mensagem é invertido se o sistema operacional B encon- trar um disco em um formato que não é reproduzido. O sistema operacional B envia uma mensagem (por exemplo, com um valor de 2) para seu acionador de envio de mensagem, que distribuir a mensagem para a fila de correio do acionador do sistema operacional A. O acionador par ao sistema operacional A espera por mensagens em sua fila de correio, rece- be a mensagem do sistema operacional B1 interpreta a mensagem (cujo valor indica "acor- dar"), e realiza as etapas para acordar o sistema operacional Aeo núcleo A. O sistema ope- racional B se coloca para dormir depois que envia a mensagem de acordar para o sistema operacional A, ou, alternativamente, espera por uma mensagem para ir dormir do sistema operacional A;

Exemplo 2: A figura 2 é um fluxograma ilustrando uma técnica ilustrativa (200) de acordo com um modelo de graceful handoff para utilização de características em sistemas operacionais rodando simultaneamente. A técnica (200) ilustrada na figura 2 difere em al- guns aspectos das etapas no exemplo 1, acima, enquanto ainda alcança uma transição su- ave entre dois sistemas operacionais.

Na técnica (200), um carregador de inicialização é ativado (205) e os sistemas ope- racionais AeB são inicializados (210, 255). Na figura 2, os sistemas operacionais começam em um estado inativo (210, 255). Qualquer um dos sistemas operacionais pode ser acorda- do do estado inativo (216, 260) por uma mensagem de acordar (220, 265) do outro sistema operacional. Isso pode ocorrer, por exemplo, quando um usuário solicita uma operação, rea- liza uma ação de navegação, verifica ou altera uma configuração, ou altera o conteúdo de mídia (por exemplo, pela mudança de um disco).

Depois de acordar, o sistema operacional ativado realiza (225 ou 270) a funcionali- dade de característica ativada utilizando esse sistema operacional. Depois da detecção de uma mudança de característica (230 ou 275), o sistema operacional ativado verifica (235 ou 280) se pode realizar a nova característica. Se não, o sistema operacional prepara (240 ou 285) recursos de hardware, como necessário, para transição para outro sistema operacio- nal, e envia uma mensagem de acordar (245 ou 290) para o outro sistema operacional. O sistema operacional que envia a mensagem de acordar pode então retornar para um estado inativo para esperar por uma possível mensagem de acordar.

No exemplo ilustrado na figura 2, os sistemas operacionais AeB inicialmente en- tram nos estados inativos (215, 260) depois de serem inicializados (210, 255). Alternativa- mente, um ou mais dos sistemas operacionais estão inicialmente em um estado ativo. Por exemplo, em um aparelho de disco de vídeo que reproduz ambos os discos Blu-ray e HD DVD, um primeiro sistema operacional entra em um estado inicialmente ativo quando um disco HD DVD está no aparelho quando o mesmo é ligado. Ao invés de entrar em um esta- do inativo inicial e verificar por uma mensagem de acordar, o primeiro sistema operacional realiza a funcionalidade de característica ativada utilizando o software rodando no primeiro sistema operacional (por exemplo, lançando um menu HD DVD, ou inicializando a reprodu- ção do HD DVD) até que um evento ocorra que exija que outro sistema operacional se torne ativo (por exemplo, um usuário inserindo um disco Blu-ray). Ou, um dispositivo pode ser configurado de forma que um sistema operacional esteja ativo por definição durante a inicia- lização.

2. Exemplos de Warm Boot

Exemplo 3: Nessa situação de warm boot, o sistema operacional Aeo sistema ope- racional B são configurados para funcionarem individualmente, não simultaneamente. Nesse exemplo, o sistema operacional A é o sistema operacional primário e controla atualmente a maior parte dos aspectos do dispositivo. Detecta que um usuário está tentando utilizar uma característica fornecida pelo sistema operacional Β. O processo do Exemplo 3 inclui as eta- pas a seguir:

1. Armazenamento da exigência de característica identificada no armazenador não volátil;

2. Armazenamento da exigência do sistema operacional no armazenador não volá- til;

3. Desligamento do sistema operacional A;

4. Reinicialização;

5. Determinação (com o carregador de inicialização) do sistema operacional neces- sário pela leitura dos dados armazenados na etapa 2, acima. Nesse exemplo, esse é o sis- tema operacional Β;

6. Inicialização do sistema operacional B;

7. Determinação (com o sistema operacional B) da característica necessária pela leitura dos dados armazenados na etapa 1, acima;

8. Ativação, se necessário, e utilização (com o sistema operacional B) dos recursos de hardware necessários para satisfazer as exigências da característica. A transição de um sistema operacional para outro pode ser realizada graciosamente para alguns recursos de hardware (por exemplo, monitores), de forma que seu estado (por exemplo, atualmente exi- bindo um menu) seja completamente ou parcialmente persistido através do handoff do sis- tema operacional A para o sistema operacional B, a fim de reduzir o tempo de transição e/ou mitigar o impacto negativo na experiência do usuário;

9. Fornecimento (com o sistema operacional B) da característica desejada.

Exemplo 4: A figura 3 é um fluxograma ilustrando uma técnica ilustrativa (300) de

acordo com um modelo de warm boot para utilização das características em sistemas ope- racionais diferentes em um dispositivo, onde os sistemas operacionais não rodam simulta- neamente. A técnica (300) ilustrada na figura 3 difere em alguns aspectos das etapas no exemplo 3, acima, enquanto ainda alcança uma transição suave entre os dois sistemas ope- racionais.

Na técnica (300), um carregador de inicialização é ativado (305) e um indicador é verificado (310) indicando se o sistema operacional B deve ser inicializado. Se o indicador for configurado, o dispositivo inicializa (315) o sistema operacional B e realiza (320) a fun- cionalidade da característica ativada utilizando o sistema operacional B. Alternativamente, um marcador além do indicador é utilizado para indicar as funções que serão realizadas e/ou qual sistema operacional será utilizado.

Se uma mudança de característica for detectada (325), o sistema operacional de- termina (330) se suporta a nova característica. Se não suportar a nova característica, a in- formação sobre a característica é armazenada (335) no armazenador não volátil. O indica- dor de inicialização é reconfigurado para indicar que o outro sistema operacional deve ser utilizado, e uma reinicialização (340) ocorre.

Durante a reinicialização (340), o carregador de inicialização é ativado (305) e o in- dicador de inicialização indica (310) que o sistema operacional A deve ser inicializado. O dispositivo inicializa (350) o sistema operacional A e realiza (355) a funcionalidade de carac- terística ativada utilizando o sistema operacional A. Se uma mudança de característica for detectada (360), o sistema operacional determina (365) se suporta a nova característica. Se não suportar a nova característica, a informação sobre a característica é armazenada (370) no armazenador não volátil e o dispositivo pode reinicializar (375) para o sistema operacio- nal B. As reinicializações (340, 375) são warm boots, visto que ocorrem depois que o dis- positivo foi ligado. Uma característica típica de um warm boot de um sistema operacional é que nem tudo no sistema operacional é reinicializado. Exemplos de funcionalidade de warm boot incluem características de "espera" ou "hibernar" nos computadores laptop - alguns estados são salvados quando um computador de laptop entra no modo de standby ou hiber- nar, de forma que quando o computador laptop acorda novamente pode retomar mais rapi- damente a operação normal de onde deixou.

B. Discussão

Exemplos 1, 2, 3 e 4 acima diferem das técnicas (algumas vezes referidas como técnicas de virtualização) nas quais um ou mais ambientes de sistema operacional são hos- pedados por um sistema operacional primário, e todos os ambientes compartilham o acesso aos recursos de hardware necessários. Por exemplo, as transições do sistema operacional nos exemplos 1, 2, 3 e 4 acima não resultam necessariamente de um ato consciente por parte de um usuário de mudar os sistemas operacionais, nem envolvem um sistema opera- cional hospedando outro sistema operacional ou emulando uma plataforma na qual o outro sistema operacional roda. O usuário não precisa estar ciente dos múltiplos sistemas opera- cionais disponíveis no dispositivo.

Algumas vantagens e aperfeiçoamentos para as implementações descritas incluem a redução na quantidade de tempo para a realização das transições entre os sistemas ope- racionais necessárias para a funcionalidade específica, além de tornar as transições do sis- tema operacional não obstrutivas para os usuários.

Considera-se um dispositivo ilustrativo que utiliza dois sistemas operacionais a fim de cobrir uma faixa de características. Nesse dispositivo ilustrativo, o sistema operacional A suporta uma reprodução de mídia de disco ótico, enquanto o sistema operacional B suporta a navegação na Internet. Enquanto um usuário está navegando na Internet, o sistema ope- racional B está em controle do dispositivo. Se o usuário então inserir um disco ótico e aper- tar o botão "play" no dispositivo, o usuário espera tipicamente que a reprodução de mídia ótica ocorra sem uma ação específica por parte do usuário para mudar do sistema opera- cional B para o sistema operacional A. As implementações descritas permitem que a transi- ção e seleção do sistema operacional sejam escondidas do usuário.

Tipicamente, quando um sistema operacional inicializa e os acionadores do disposi- tivo são carregados, o acionador de dispositivo inicializará o hardware para um estado co- nhecido. N ocaso de uma tela visível para o usuário ou monitor externo, essa inicialização pode resultar em uma oscilação perceptível pelo usuário ou pode fazer com que o monitor externo perca momentaneamente a sincronização com o sinal do dispositivo. Pela mudança da implementação de acionador de dispositivo para cada caso de sistema operacional, a fase de inicialização pode ser realizada para compensar um estado de monitor atual e não realiza as etapas de inicialização desnecessárias que resultariam em oscilação, corrupção, ou perda de sinal. Isso é um exemplo de como a seqüência de inicialização pode ser dese- nhada para tomar a transição entre os sistemas operacionais menos perceptível para um usuário.

III. Implementações Ilustrativas para Dispositivos de Reprodução de Áudio e Vídeo

Essa seção inclui exemplos específicos de técnicas e ferramentas para manusear as transições do sistema operacional para dispositivos de mídia que manuseiam formatos de mídia diferentes (por exemplo, formatos de disco de vídeo) para reprodução de áudio e vídeo. Nas implementações alternativas, as etapas ilustradas nos exemplos abaixo podem ser reordenadas, omitidas ou substituídas por etapas diferentes.

Por exemplo, exemplos que descrevem a comutação de um segundo sistema ope- racional para um primeiro sistema operacional podem ser estendidos para comutar de volta para o segundo sistema operacional por definição depois que uma característica solicitada suportada com o primeiro sistema operacional não está mais sendo utilizada, ou em respos- ta a uma ação de usuário subseqüente que utiliza uma característica suportada com o se- gundo sistema operacional. As transições entre os sistemas operacionais pode continuar desde que necessárias ou desejadas. Exemplos que designam o segundo sistema opera- cional como um sistema operacional primário ou inicial podem ser modificados para desig- nar o primeiro sistema operacional como o sistema operacional primário inicial, ou vice- versa. Como outra alternativa, os dispositivos podem utilizar sistemas operacionais além dos primeiros dois sistemas operacionais para suportar formatos de mídia diferentes. Exemplos nessa seção descrevem a realização das operações de reprodução (por exemplo, reprodu- ção de vídeo HD DVD, Blu-ray ou DVD ou reprodução de áudio CD), mas os sistemas ope- racionais podem realizar outras operações específicas de um sistema operacional particular ou comum a dois ou mais sistemas operacionais. Exemplos nessa seção descrevem mu- danças de disco como eventos que podem acionar uma transição entre os sistemas opera- cionais, mas outros eventos também podem acionar transições entre sistemas operacionais, tal como a seleção de usuário de uma característica suportada com um sistema operacional particular. Exemplos nessa seção descrevem a comutação entre dois sistemas operacio- nais, mas é possível se comutar entre mais de dois sistemas operacionais.

A. Graceful Handoff para Mudanças de Formato de Mídia

Em algumas implementações, um modelo de graceful handoff para as mudanças de formato de mídia incluem um processo de seleção de múltiplos núcleos onde dois ou mais núcleos de processamento rodam, cada um, um sistema operacional diferente que suporta um formato de mídia diferente. O modelo de graceful handoff pode resultar em tempos de carregamento mais curtos para o conteúdo em formatos diferentes.

A figura 4 é um fluxograma ilustrando uma técnica ilustrativa (400) para o manuseio de graceful handoff de transições em um dispositivo que utiliza um primeiro sistema opera- cional para a reprodução de discos HD DVD e um segundo sistema operacional para repro- duzir discos de outros formatos de disco. No exemplo ilustrado na figura 4, um carregador de inicialização é ativado (405) e os sistemas operacionais AeB são inicializados (410, 455). Se um disco estiver presente, o sistema operacional B determina (465) se o disco é um disco HD DVD. Se o disco não for um disco HD DVD, o sistema operacional B pode rea- lizar a funcionalidade de característica suportada utilizando esse sistema operacional (re- produção de áudio Blu-ray, DVD ou CD (470)). Depois da detecção de uma mudança de disco (475), o sistema operacional determina (465) se o novo disco e um disco HD DVD.

Quando o sistema operacional B está verificando um disco durante a inicialização ou depois de uma mudança de disco, se o disco for um disco HD DVD o sistema operacio- nal prepara (480) os recursos de hardware, como necessário, para a transição para o siste- ma operacional A e envia uma mensagem de acordar (485) para o sistema operacional A. O sistema operacional B entra em um estado inativo (490) e verifica (495) por uma mensagem de acordar do sistema operacional A. Depois de acordar, o sistema operacional B pode rea- lizar novamente a funcionalidade de característica suportada utilizando esse sistema opera- cional (por exemplo, reprodução de áudio CD ou Blu-ray ou DVD (470)).

No exemplo ilustrado na figura 4, quando o sistema operacional A é inicializado, o mesmo entra inicialmente em um estado inativo (415). O sistema operacional A verifica (420) por uma mensagem de acordar do sistema operacional B. Depois de acordar, o siste- ma operacional A pode realizar a funcionalidade de característica suportada utilizando esse sistema operacional (por exemplo, reprodução de vídeo HD DVD (425)).

Depois da detecção de uma mudança de disco (430), o sistema operacional verifica (435) se o novo disco é um disco HD DVD. Se não, o sistema operacional prepara (440) os recursos de hardware, como necessário, para transição para o sistema operacional B e en- via uma mensagem de acordar (445) para o sistema operacional Β. O sistema operacional A pode então retornar para um estado inativo (415) para esperar por uma possível mensagem de acordar.

Em algumas implementações, um objetivo dos estados inativos para cada sistema operacional é evitar que se acesse o hardware no dispositivo quando o sistema operacional respectivo esta inativo. Por exemplo, enquanto um sistema operacional está acessando a unidade de acionamento ótico, outros sistemas operacionais nos estado inativos podem ser impedidos de acessar o acionador. Os estados inativos podem ser manuseados de formas diferentes. Por exemplo, os acionadores de dispositivo no sistema operacional podem ser codificados para suportar um modo inativo. Ou, se o sistema operacional suportar o carre- gamento e descarregamento dinâmico dos acionadores de dispositivo, o acionador pode ser descarregado para impedir que o sistema operacional acesse o hardware subjacente. Ou, um sistema operacional pode ser colocado para dormir; alguns sistemas operacionais permi- tem que seus estados sejam salvos na memória e então interrompidos, para serem posteri- ormente rapidamente reinicializados. Tais características de sono incluem as características de hibernar nos sistemas operacionais Windows® da Microsoft Corporation.

O mesmo mecanismo não precisa ser utilizado para implementar os estados inati- vos em cada sistema operacional em um dispositivo. Por exemplo, a hibernação pode ser suportada por um sistema operacional, enquanto outro sistema operacional só suporta os acionadores de carregamento e descarregamento. Um sistema operacional suportando a hibernação pode implementar um modo inativo entrando em um estado de hibernação, en- quanto outro sistema operacional pode implementar um modo inativo descarregando os a - cionadores de dispositivo. Uma combinação de carregamento de acionador de dispositivo e acionadores suportando diretamente um modo inativo pode ser utilizada, por exemplo, em um caso onde apenas um subconjunto de acionadores de dispositivo em um sistema opera- cional pode ser descarregado.

Uma alternativa para esse modelo é se abstrair os componentes de hardware nos dispositivo para atravessar uma camada de firmware. Os acionadores no sistema operacio- nal podem se comunicar com os componentes abstraídos, ao invés de diretamente com o hardware. Isso é similar a um conceito BIOS, para os ambientes de virtualização de sistema operacional, ou a um modelo utilizado nos sistemas onde o acesso ao dispositivo é abstraí- do através de uma camada que permite que o barramento físico seja canalizado através de outro mecanismo (por exemplo, de forma que um acionador de rede possa se comunicar com um cartão de rede no lado distante de um barramento USB). A funcionalidade do moto inativo pode então ser implementada na camada intermediária que abstrai o acesso aos dispositivos.

A figura 5 ilustra um exemplo de um dispositivo de inicialização dupla (500) com um desenho de núcleo duplo com firmware (530) e recursos de hardware compartilhados (540). Com referência à figura 5, um segundo sistema operacional (510) (tal como um sistema ope- racional com base em Linux, ou outro sistema operacional tipo Unix ou variação de Unix, ou outro sistema operacional) suporta uma pilha de aparelho Blu-ray (514) e acionadores (512) específicos para o segundo sistema operacional (510). Um primeiro sistema operacional (520) (tal como o sistema operacional Windows® CE ou outro sistema operacional) suporta uma pilha de aparelho HD DVD (524) e acionadores (522) específicos para o primeiro sis- tema operacional (520). O firmware (530) inclui um daemon de carregador de inicialização (532) e expõe serviços de entrada/saída (534). O firmware (530) não tem qualquer filiação com qualquer sistema operacional específico e é utilizado para arbitrar um carregamento de disco e máquina de estado de detecção de ID de disco. Os serviços de entrada/saída (534) permitem um ponto único de entrada com os recursos de hardware compartilhados (540) do hardware de dispositivo (550) para ambos os sistemas operacionais (510, 520). Os serviços de entrada/saída (534) são similares aos serviços BIOS existentes. Os serviços de entra- da/saída (534) são simples, mas poderosos o suficiente para permitir que acionadores es- pecíficos de sistema operacional diferentes (512, 522) sejam portados sem sacrificar muito o desempenho ou incorrendo em muitas mudanças fundamentais para um acionador existen- te. As semânticas de leitura/escrita/abertura/fechamento simples são utilizadas, tal como as associadas com a chamada de sistema "ioctl" encontrada nos sistemas Unix, que permite que um aplicativo controle ou se comunique com um acionador de dispositivo.

O modelo de graceful handoff pode utilizar memória adicional, modificações dos sis- temas operacionais para lidar com o compartilhamento de recurso de hardware e/ou ove- rhead de comunicação entre os sistemas operacionais para coordenar os handoffs, mas pode reduzir os tempos de transição e aperfeiçoar a experiência do usuário. Para se reduzir os custos de engenharia, é freqüentemente desejável se fazer o mínimo de trabalho possí- vel no sistema operacional. A utilização de acionadores de dispositivo padrão é freqüente- mente preferida.

B. Modelo de Warm Boot para Mudanças de Formato de Mídia

A figura 6 é um fluxograma ilustrando uma técnica ilustrativa (600) para o manuseio de mudanças de formato de disco em um dispositivo possuindo primeiro e segundo siste- mas operacionais disponíveis de acordo com um modelo de warm boot, onde os sistemas operacionais não rodam simultaneamente. Na técnica (600), um carregador de inicialização é ativado (605) e um indicador é verificado (610) que indica se a reprodução do HD DVD será realizada. Se o indicador for configurado, o dispositivo inicializa (615) um primeiro sis- tema operacional e realiza a funcionalidade suportada pelo primeiro sistema operacional (por exemplo, reprodução HD DVD (620)). Alternativamente, um marcador além do indicador e utilizado para indicar as funções que serão realizadas e/ou qual sistema operacional será utilizado. Se uma mudança de disco for detectada (625), o sistema operacional determina (630) se suporta o novo disco. Se não suportar o novo disco, o indicador HD DVD é limpo (635), e durante a reinicialização (640) o carregador de inicialização é ativado (605) e o indi- cador HD DVD limpo indica (610) que o segundo sistema operacional deve ser inicializado.

Depois da reinicialização (640), ou se o indicador HD DVD inicialmente ainda não tiver sido configurado, o dispositivo reinicializa (655) o segundo sistema operacional. O se- gundo sistema operacional verifica inicialmente (660) se um disco está presente no disposi- tivo. Se um disco estiver presente, o segundo sistema operacional determina (665) se o dis- co é um disco HD DVD. Se o disco não for um disco HD DVD, o segundo sistema operacio- nal pode realizar a funcionalidade de característica específica desse sistema operacional (por exemplo, reprodução de áudio Blu-ray, DVD ou CD (670)). Depois da detecção de uma mudança de disco (675), o sistema operacional determina (665) se o novo disco é um disco HD DVD.

Quando o segundo sistema operacional está verificando um disco durante a iniciali- zação ou depois de uma mudança de disco, se o disco for um disco HD DVD o sistema ope- racional configura (680) o indicador HD DVD, e durante a reinicialização (685) o carregador de inicialização é ativado (605) e o indicador HD DVD indica (610) que o primeiro sistema operacional deve ser inicializado.

As reinicializações (640, 685) são warm boots, visto que ocorrem depois que o dis- positivo foi ligado. Alternativamente, a lógica pode ser utilizada para carregar e lançar os sistemas operacionais diretamente, ao invés de realizar um ciclo de volta através do carre- gador de inicialização.

Durante as reinicializações ou outro carregamento e lançamento de diferentes sis- temas operacionais, os estados de alguns recursos de hardware podem ser persistidos completamente ou parcialmente através do controle de diferentes sistemas operacionais para mitigar o impacto negativo na experiência do usuário. Por exemplo, o estado de um controlador de Interface de Multimídia de Alta Definição ("HDMI") pode não ser reconfigura- do, ou o estado de um monitor de painel dianteiro pode não ser reconfigurado.

Várias alternativas e extensões do modelo de warm boot descritas acima são pos- síveis. Por exemplo, a identificação de tipo de disco pode ser escrita uma vez e existe no carregador de inicialização para o dispositivo. O carregador de inicialização pode escolher o sistema operacional correto com base na identificação de tipo de disco. Uma mudança de disco pode ser manuseada com um desligamento ou reinicialização a fim de obter a lógica de carregador de inicialização, que pode simplificar o esforço de engenharia para construir o dispositivo.

Como outro exemplo, operações demoradas podem ser paralelizadas. Por exem- plo, o carregamento do sistema operacional e o aplicativo de reprodução da memória e o processo de identificação de tipo de mídia podem consumir muito tempo.

A figura 7 é um fluxograma ilustrando uma técnica ilustrativa (700) para a realização de operações de comutação de formato de mídia de warm boot em paralelo. No exemplo ilustrado na figura 7, um aplicativo de reprodução suportado por um sistema operacional atual está inicialmente sendo rodado. Uma bandeja de disco é aberta (710), e o dispositivo para (720) o processador de reprodução atual, interrompendo o aplicativo de reprodução. (Essa etapa é opcional, mas pode ser desejável para liberar alguma memória para a próxi- ma etapa). O dispositivo inicia o carregamento (730) de outro sistema operacional na memó- ria (se existir memória livre o suficiente). Quando a nova mídia é inserida (740), o sistema identifica o tipo de mídia (750). O carregamento do sistema operacional (730) pode ser uma operação demorada, de forma que o dispositivo não bloqueie no carregamento de sistema operacional (730), permitindo que o mesmo prossiga em paralelo com uma ou mais outras etapas (por exemplo, identificação do tipo de mídia (750)). A identificação do tipo de mídia (750) também pode ser uma operação demorada, de forma que também prossegue ao mesmo tempo com uma ou mais outras etapas (por exemplo, carregamento do sistema ope- racional (730)).

O dispositivo verifica (760) se o sistema operacional atual suporta a nova mídia. Se o novo tipo de mídia utilizar o sistema operacional atual que já está sendo rodado, então o carregamento do novo sistema operacional (730) é abortado (77) e o aplicativo do aparelho adequado é lançado para a nova mídia. Se o novo tipo de mídia utilizar o sistema operacio- nal que está sendo carregado, o dispositivo espera pelo final do carregamento do sistema operacional (780) se necessário e reinicializa, reiniciando o novo sistema operacional na memória.

Algumas implementações de warm boot não se baseiam em uma plataforma de hardware em particular, exigem menos recursos de hardware, e possuem uma menor com- plexidade geral quando comparadas com algumas implementações de graceful handoff. Algumas implementações de warm boot podem incluir um custo de tempos de carregamento de conteúdo aumentados para diferentes formatos de conteúdo.

IV. Extensões e Alternativas

Um aplicativo de configuração de dispositivo é um aplicativo de software potencial- mente complicado que normalmente não é amarrado a qualquer mídia gravada. Para apare- lhos de disco de vídeo, as funções de configuração de dispositivo são freqüentemente aces- sadas através de um botão em um controle remoto ao invés de pela inserção de um disco de configuração. Quando um único sistema operacional está rodando no dispositivo de cada vez, a configuração pode ser implementada em cada sistema operacional, o que complica os esforços de engenharia para o desenvolvimento do dispositivo, mas pode resultar em uma melhor experiência para o usuário. Ou, a configuração pode ser implementada em um único sistema operacional, simplificando os esforços de engenharia a um custo possível de distanciamento da experiência do usuário se a configuração exigir que o dispositivo seja reinicializado para o sistema operacional que suporta a configuração. Uma abordagem hí- brida pode ser utilizada para se obter uma mistura dos esforços de engenharia reduzidos e capacidade de utilização aumentada. As operações freqüentemente acessadas podem ser implementadas em mais de um sistema operacional (por exemplo, ativação/desativação de legendas durante a reprodução), e as operações menos freqüentes podem ser implementa- das em um único sistema operacional (por exemplo, configuração de uma conexão de rede). Quando múltiplos sistemas operacionais são rodados em um dispositivo simultaneamente, a configuração pode ser implementada em um único sistema operacional e ainda funcionar independentemente do tipo de mídia atualmente no dispositivo. Por exemplo, a configuração pode ser implementada em um segundo sistema operacional rodando em um núcleo de CPU, produzindo uma interface de usuário que é transferida para um primeiro sistema ope- racional que controla a reprodução HD DVD. A interface de usuário pode ser exibida ao in- vés de, ou em adição a (por exemplo, misturada ou em uma janela na tela separada) uma reprodução de vídeo.

Um dispositivo pode implementar uma combinação de técnicas de transição de sis- tema operacional de warm boot e graceful handoff. Por exemplo, um dispositivo pode de- terminar se utiliza uma transição graceful handoff ou uma transição warm boot com base nos fatores tal como utilização de recursos, tempo de transição e impacto potencial para a experiência de usuário. Dessa forma, um dispositivo pode ter a flexibilidade no manuseio de transições entre os sistemas operacionais.

Alguns formatos de mídia exigem o suporte de funcionalidade avançado além do suporte para reprodução e navegação de menu, tal como o suporte de Linguagem de Mar- cação Extensível ("XML"), suporte para ECMAScript (uma linguagem de script padronizada), ou suporte Java. A seleção das características que exigem suporte para esses tipos de fun- cionalidade avançada também podem acionar as transições de sistema operacional.

O uso de discos de formato duplo pode resultar em casos que acionam as transi- ções de sistema operacional de forma similar aos eventos associados com as mudanças de disco. As técnicas e ferramentas descritas aqui podem ser utilizadas em conjunto com os discos de formato duplo.

Tendo descrito e ilustrado os princípios da invenção com referência a várias moda- lidades, será reconhecido que as várias modalidades podem ser modificadas na disposição e detalhes sem se distanciar de tais princípios. Deve-se compreender que os programas, processos, ou métodos descritos aqui não estão relacionados ou limitados a qualquer tipo particular de ambiente de computação, a menos que indicado o contrário. Vários tipos de ambientes de computação de finalidade geral ou especializados podem ser utilizados com ou realizar operações de acordo com os ensinamentos descritos aqui. Os elementos das modalidades ilustrados em software podem ser implementados em hardware e vice-versa.

Em vista das várias modalidades possíveis às quais os princípios da invenção des- crita podem ser aplicados, deve-se reconhecer que as modalidades ilustradas são apenas exemplos preferidos da invenção e não devem ser considerados limitadores do escopo da invenção. Ao invés disso, o escopo da invenção é definido pelas reivindicações em anexo. Dessa forma, se reivindica como a invenção tudo que se encontra dentro do escopo e espíri- to dessas reivindicações.

Claims (20)

1. Método de reprodução de diferentes informações de mídia digital codificadas em diferentes formatos de mídia, o método sendo CARACTERIZADO pelo fato de: receber a primeira informação de mídia digital em um aparelho de mídia digital pos- suindo um primeiro sistema operacional em um primeiro estado inativo (260) na memória e possuindo um segundo sistema operacional em um estado ativo na memória, a primeira informação de mídia digital sendo codificada de acordo com um primeiro formato de mídia; acordar (245, 265) o primeiro sistema operacional do primeiro estado inativo (260) onde o primeiro sistema operacional suporta a reprodução de mídia para o primeiro formato de mídia, e onde o segundo sistema operacional suporta a reprodução de mídia para um segundo formato de mídia diferente do primeiro formato de mídia; e reproduzir (270) a primeira informação de mídia digital utilizando um primeiro aplica- tivo que roda em um ambiente operacional fornecido pelo primeiro sistema operacional.

2. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de com- preender adicionalmente: a colocação do segundo sistema operacional em um segundo estado inativo (215) de forma a liberar recursos para uso pelo primeiro sistema operacional.

3. Método, de acordo com a reivindicação 2, CARACTERIZADO pelo fato de com- preender adicionalmente: o recebimento da segunda informação de mídia digital no aparelho de mídia digital, a segunda informação de mídia digital sendo codificada de acordo com o segundo formato de mídia; a colocação do primeiro sistema operacional em um terceiro estado inativo (260) de modo a liberar os recursos para uso pelo segundo sistema operacional; o acordar (290, 220) do segundo sistema operacional do segundo estado inativo (215); a reprodução (225) da segunda informação de mídia digital utilizando um segundo aplicativo que roda em um ambiente operacional fornecido pelo segundo sistema operacio- nal.

4. Método, de acordo com a reivindicação 2, CARACTERIZADO pelo fato de com- preender adicionalmente: o recebimento de uma solicitação para uma característica de navegação ou confi- guração; a colocação o primeiro sistema operacional em um terceiro estado inativo (260) de modo a liberar os recursos para uso pelo segundo sistema operacional; o acordar (290, 220) do segundo sistema operacional do segundo estado inativo(215); e a apresentação (225) de um menu para a característica de navegação ou configu- ração em um ambiente operacional fornecido pelo segundo sistema operacional.

5. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de o apa- relho de mídia digital ser um dispositivo independente, uma parte de um dispositivo de co- municações ou uma parte de um dispositivo de exibição.

6. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de o a- cordar (245, 265) do primeiro sistema operacional do primeiro estado inativo (260) compre- ender o envio (245) de uma mensagem de acordar do segundo sistema operacional no es- tado ativo para o primeiro sistema operacional no primeiro estado inativo (260).

7. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de a pri- meira informação de mídia digital compreender conteúdo de vídeo de alta definição, e onde o primeiro formato de mídia é um formato de vídeo de alta definição.

8. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de o a- cordar (245, 265) do primeiro sistema operacional do primeiro estado inativo (260) ser em resposta à identificação do primeiro formato de mídia no qual a primeira informação de mídia digital é codificada.

9. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de o a- cordar (245, 265) do primeiro sistema operacional do primeiro estado inativo (260) ocorrer em resposta à seleção do usuário de uma característica de navegação ou configuração su- portada pelo primeiro sistema operacional.

10. Método de reprodução de diferentes informações de mídia digital codificadas em diferentes formatos de mídia, o método sendo CARACTERIZADO pelo fato de: o recebimento da primeira informação de mídia digital em um aparelho de mídia di- gital possuindo um primeiro sistema operacional armazenado no armazenador não volátil e um segundo sistema operacional armazenado no armazenador não volátil, o segundo sis- tema operacional rodando em um estado ativo na memória; a identificação (330) de um primeiro formato de mídia de acordo com o qual a pri- meira informação de mídia digital é codificada, onde a reprodução do primeiro formato de mídia é suportada pelo primeiro sistema operacional, e onde a reprodução de um segundo formato de mídia diferente do primeiro formato de mídia é suportada pelo segundo sistema operacional; e em resposta à identificação, o carregamento (305, 310, 350) do primeiro sistema operacional dentro da memória a partir do armazenador não volátil, onde o primeiro sistema operacional fornece um ambiente operacional para a reprodução da primeira informação de mídia digital quando o primeiro sistema operacional está rodando em um estado ativo na memória.

11. Método, de acordo com a reivindicação 10, CARACTERIZADO pelo fato de compreender adicionalmente: a reprodução (355) da primeira informação de mídia digital utilizando um primeiro aplicativo rodando no ambiente operacional fornecido pelo primeiro sistema operacional, onde o primeiro aplicativo opera para decodificar a primeira informação de mídia digital codi- ficada de acordo com o primeiro formato de mídia.

12. Método, de acordo com a reivindicação 10, CARACTERIZADO pelo fato de que o aparelho de mídia digital é um dispositivo independente, uma parte de um dispositivo de comunicações ou uma parte de um dispositivo de exibição.

13. Método, de acordo com a reivindicação 10, CARACTERIZADO pelo fato de compreender adicionalmente: o recebimento de uma solicitação por uma característica de navegação ou configu- ração; o desligamento do primeiro sistema operacional; o carregamento (305, 310, 315) do segundo sistema operacional na memória a par- tir do armazenamento não volátil, onde o segundo sistema operacional fornece um ambiente operacional para apresentação de um menu para a característica de navegação ou configu- ração; e a apresentação (320) do menu no ambiente operacional fornecido pelo segundo sistema operacional.

14. Método, de acordo com a reivindicação 10, CARACTERIZADO pelo fato de a primeira informação de mídia digital compreender conteúdo de vídeo de alta definição e on- de o primeiro formato de mídia é um formato de vídeo de alta definição.

15. Método, de acordo com a reivindicação 10, CARACTERIZADO pelo fato de compreender adicionalmente o desligamento do segundo sistema operacional antes de o primeiro sistema operacional estar rodando em um estado ativo na memória.

16. Método, de acordo com a reivindicação 15, CARACTERIZADO pelo fato de compreender adicionalmente: o recebimento da segunda informação de mídia digital no aparelho de mídia digital, a segunda informação de mídia digital sendo codificada de acordo com o segundo formato de mídia; a identificação (365) do segundo formato de mídia; e em resposta à identificação do segundo formato de mídia, o desligamento do pri- meiro sistema operacional e o carregamento (305, 310, 315) do segundo sistema operacio- nal dentro da memória a partir do armazenador não volátil, onde o segundo sistema opera- cional fornece um ambiente operacional para reprodução da segunda informação de mídia digital.

17. Método de reprodução de diferentes informações de mídia digital codificadas em diferentes formatos de mídia, o método sendo CARACTERIZADO pelo fato de: o recebimento da primeira informação de mídia digital em um primeiro aparelho de mídia digital possuindo um primeiro sistema operacional em um primeiro estado inativo (260) na memória e possuindo um segundo sistema operacional em um estado ativo na memória, a primeira informação de mídia digital sendo codificada de acordo com um primeiro formato de mídia; o acordar (245, 265) do primeiro sistema operacional do primeiro estado inativo (260), onde o primeiro sistema operacional suporta a reprodução de mídia para o primeiro formato de mídia, e onde o segundo sistema operacional suporta a reprodução de mídia para um segundo formato de mídia diferente do primeiro formato de mídia; a persistência de um estado de pelo menos um dentre os vários componentes de hardware; a transferência do controle dos vários componentes de hardware do segundo sis- tema operacional para o primeiro sistema operacional; a reprodução (270) da primeira informação de mídia digital utilizando um primeiro aplicativo que roda em um ambiente operacional fornecido pelo primeiro sistema operacio- nal.

18. Método, de acordo com a reivindicação 17, CARACTERIZADO pelo fato de pe- lo menos um componente de hardware ser um monitor conectado ao aparelho de mídia digi- tal, e onde o estado persistido compreende informação exibida.

19. Método, de acordo com a reivindicação 18, CARACTERIZADO pelo fato de que a informação exibida compreende um menu.

20. Método, de acordo com a reivindicação 17, CARACTERIZADO pelo fato de uma camada de firmware (530) fornece serviços de entrada/saída (534) para abstrair o a- cesso aos vários componentes de hardware, e onde a camada de firmware implementa a funcionalidade do modo inativo para o primeiro estado inativo (260).