Re: [Liquidfire-devel]Re: GNU/Liquid

[Marcelo S. <ma...@he...>]

On Mon, 7 Jun 2004, Lucas Mendes wrote:

>
> eu preciso rever os pinos das memorias SIMM de 72". pro lance do boot, seria

as memorias de 72 vias tem 32 bits, portanto sao 4 bytes (4 pinos CAS). e
algumas tem 1 RAS ou 2 RAS, q sao os bancos. basicamente, vc tem q pensar
q existem chips de 1Mbit, 4Mbit e 16Mbit, assim:

	1Mbit x 4 bytes x 1 banco  = 4MB
	1Mbit x 4 bytes x 2 bancos = 8MB

	4Mbit x 4 bytes x 1 banco  = 16MB
	1Mbit x 4 bytes x 2 bancos = 32MB

	16Mbit x 4 bytes x 1 banco  = 64MB
	16Mbit x 4 bytes x 2 bancos = 128MB

sera q chegou a ter de 64 ou 128MB ? nunca vi. enfim, o q nos temos: 0
68306 gera 2 CAS e 2 RAS, entao temos opcoes: fazer tudo glue-less e
ignorar metade dos bytes, assim dos pentes de 4MB usariamos 2MB, dos
pentes de 8MB usariamos 4MB, etc. infelizmente o refresh eh do tipo
CAS-before-RAS e suponho q ele tem q acionar todos os pinos CAS e depois
todos os pinos RAS. fazendo glue-less, eh facil, mas perde metade da
memoria, pq o 68306 tem 16 bits de bus e a memoria fornece 32.

outra opcao seria ignorar memorias de 2 bancos e usar apenas um banco,
nesse caso, usaria RAS0 e RAS1 para ativar os sinais CAS da palavra alta
ou baixa da palavra longa d 32 bits. nesse caso, um pente de 4MB usaria os
4MB, mas um pente de 8MB usaria 4MB (pq nao ativa o segundo banco :).
situacao similar nos outros hehehe. claro q  isso tb iria requerer algumas
portas logicas extras para fazer a selecao dos bytes, mas nada complexo.

outra solucao mais radical seria usar sram grande (1MB/banco) ou montar
um controlador dram capaz de gerar sinais suficientes, neste caso o limite
seria de 16MB/banco. eu simpatizo com memorias sram, mas certamente a
opcao mais acima, totalmente glue-less, pelo menos num primeiro instante,
seria a melhor de todas.

> mesmo interessante nao limitar as coisas em um setor, com o Intel. podemos
> puxar 2 paginas (8KB) de uma vez, que jah teria o codigo do trap #0 para acesso
> ao HD (KERNEL VFS basico - flexibilizando a opcao do sistema de arquivos do
> microkernel.. o FS nao estaria no KERNEL, mas num modulo separado e o KERNEL
> usaria o trap #0) e carregando o KERNEL para o topo do core. outro lance

questao basica: como o microkernel le o modulo de fs e driver de disco se
ele nao sabe fazer isto ? a unica solucao q eu vejo eh dar opcao de linkar
no codigo do microkernel o suporte a fs e alguns drivers basicos.

operacionalmente, nao haveria mudancas: eles rodariam como processos em
userland, mas estariam isentos de ter q viver no disco, embora possam ser
substituidos por outros processos! de qq forma, facilitaria a vida
totalmente, pq embora no boot o microkernel nao saiba acessar o disco, o
daemon q o faz jah estaria carregado na memoria, por estar linkado no
binario do proprio microkernel.

depois o cara abre o fs e puxa o resto.

> bastante interessante seriam os daemons multiplos, para hardware carente de IRQ;
> basicamente aquela nossa velha ideia de polling no IO, tipo um select. :)

fica legal, pe mesmo q seja totalmente sem hardware, ainda rolaria poling
em cima de uma multitarefa cooperativa, hahaha. soh q  dae nao dah para
exigir muita coisa de desempenho do hardware, q vai ser xoxo :)

> contei a Lorrene sobre a possibilidade de uma multitarefa cooperativa por meio
> das funcoes write/read e descrevi a comunicacao interprocesso, as ideias sobre
> queueing e MM, se nao me engano. (nao me lembro se contei do MM para ela ou outra
> pessoa - Lorrene, se nao te descrevi, manda um mail que descrevo. eh bem
> interessante).
> a pilha de rede, como realmente te falei, tambem estara em um daemon 'NET', que
> tera acesso aos teletipos (a ethernet vai ser uma especie de TTY tambem) por
> meio de uma funcao FILE *fdevopen(char *device,char *mode) da libc, que usara
> uma system call DEVOPEN do KERNEL. como abaixo:
>
> 	FILE *eth=fdevopen("eth0","r+");
> 	if(!eth) {
> 		fprintf("Could NOT open the ethernet. Networkg disabled\n");
> 		return -1;
> 	}
> 	for(;;) {
> 		/* trata a rede como RAW SOCKET, acrescido das
> 		 * facilidades das funcoes para tratamento de
> 		 * arquivos.
> 		 */
> 	}

a ideia eh essa, mas temos q dar uma discutida no COMO VAI FUNCIONAR ;)

> deu pra perceber que o ha um modulo no KERNEL que precisa registrar o dispositivo
> "eth0" e disponibilizar funcoes de write, read, lseek e close. ha 2
> possibildiades para a ethernet: uma eh fazer 'NET' escrever direto no dispositivo
> a outra eh que teriamos um outro daemon para gerenciar o fluxo de todas as
> ethernets disponiveis. pode ser uma boa ideia, jah que os discos ATA IDE tambem
> possuem um daemon 'IDE' alem do 'FS'. de qualquer maneira, mesmo tendo 20
> daemons para os drivers, somente 2 ou 3 estarao concorrendo pela CPU;
> os demais dormirao aguardando evento nos descritores.
> tambem te contei isso. soh repassando. :)
> o Stallman perguntou se da pra correr o HURD em cima do Liquid hehehe. mais tarde
> mando mail pra ele explicando que o Liquid nao eh um Mach e que teremos todos
> os daemons necessarios, fucionando de maneira proprietaria.
> a proposito, a lista 'Liquidfire-devel' esta fucionando novamente na
> sourceforge; vamos utiliza-la! melhor que ter que ficar adicionando endereco
> por endereco das pessoas aqui nos mails.
> eu tomei a liberdade de inscrever o ma...@mi... lah. :)

hahaha emulando a API do hurd, ateh corre neh ?

> #
> # o lance do 68306 seria algo bem simples, uma PCB bem basica, com
> # a eprom de inicializacao e  uma porrada de conectores. para as duas
> # seriais, precisa de circuitos de conversao de tensao, mas q sao bem
> # basicos, bem pq em eh serial hi-speed. os sinais roteiam direto no
> # conector  da  dram de 72 vias e nem tem muito segredo,  exceto por
> # algumas  questoes relacionadas a auto-config da dram, q podemos usar
> # alguns bits das portas paralelas q  o 68306 tem onchip para fazer
> # isso e selecionar automaticamente o size do pente de memoria.
> #
> # ateh aih eu garanto q funciona legal, mas soh temos um 68306 com duas
> # seriais, eprom de boot e dram. precisariamos de uns latches e algum
> # suporte de software para tentar uma IDE, q eu acho q nao h tao
> # problematica. por fim, eu acho q poderiamos colocar um conector de
> # expansao proprietario, talvez um VME16, q reflete os sinais de um 68k
> # padrao. pq isso ? simplesmente permite plugar outra placa, essa eh
> # a q eu acho q pode dar pepinos de timming e precisaria de mais debug,
> # nessa placa colocariamos ou IO 68k nativo ou um par de conectores ISA,
> # os quais tem q  ser bufferizados com bastante latches e tb precisam de
> # logica extra para gerar sinais especiais ridiculos, por exemplo,
> # decodificar mapas de memoria, io,  etc referentes ao bus ISA do PC, q
> # ainda de quebra requer uns waitstates para sincronizar seus 8MHz
> # padrao com os 16MHz do 68306.
> #
> # na pratica, uma placa flexivel e sem muito o q dar problema: tentamos
> # mover o problema para um  conector de expansao q realmente vai dar
> # problema ateh o hardware realmente se sincronizar hehehe
> #
> # mas acho q o 68306 com eprom, seriais e IDE jah permite desenvolver
> # integralmente o sistema operacional! soh temos q achar uma forma de
> # contrabandear uns 68306 para o brasil hehehe
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Liquidfire-devel mailing list
> Liq...@li...
> https://lists.sourceforge.net/lists/listinfo/liquidfire-devel
>