j'essaie d'utiliser qemu-system-sparc. J'ai téléchargé le minirootfs.gz,
dézippé, puis:
qemu-system-sparc -m 64 -hda miniroot
Le boot se bloque sur
obmem:>> NetBSD/sparc Secondary Boot, Revision 1.15
>> (builds@wb29, Sun Dec 16 01:18:09 PST 2007)
Booting diag
-
device[sd(0,0,0):d] ("halt" to halt):
et plus rien..
Qu'écrire derrière ce prompt?
Mon but est d'utiliser un NetBSD sur autre chose qu'un qemu x86. Sparc m'a
l'air engageant, mais si sous une autre architecture, c'est plus simple,
je prends.
Merci
--
Kevin
>> Visiblement l'émulation du NCR53C94 ou des transferts DMA n'est pas fonctionnelle.
Sous un linux, ça marche. La ligne esp du dmesg dit: esp0: IRQ 36 SCSI ID 7 Clk 40MHz CCYC%000 CCF=8 TOut 167 NCR53C90(esp100)
C'est un NCR53C90 à priori et pas un NCR53C94.
Ah oui, la SS5 n'a qu'un ESP100, en effet. M'enfin ils sont compatibles, à une queue de vache près.
JKB
Le 02-09-2008, à propos de Re: NetBSD SPARC et qemu-system-sparc, Miod Vallat écrivait dans fr.comp.os.bsd :
Visiblement l'émulation du NCR53C94 ou des transferts DMA n'est pas fonctionnelle.
Sous un linux, ça marche. La ligne esp du dmesg dit: esp0: IRQ 36 SCSI ID 7 Clk 40MHz CCYC%000 CCF=8 TOut 167 NCR53C90(esp100)
C'est un NCR53C90 à priori et pas un NCR53C94.
Ah oui, la SS5 n'a qu'un ESP100, en effet. M'enfin ils sont compatibles, à une queue de vache près.
s/une queue de vache près/des bugs/
Il suffit de voir le méchant hack dans que j'ai dû faire dans le driver ESP de linux pour faire tourner le bousin.
Ou alors, c'est une queue de salers ;-)
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 02-09-2008, à propos de
Re: NetBSD SPARC et qemu-system-sparc,
Miod Vallat écrivait dans fr.comp.os.bsd :
Visiblement l'émulation du NCR53C94 ou des transferts DMA n'est pas
fonctionnelle.
Sous un linux, ça marche. La ligne esp du dmesg dit:
esp0: IRQ 36 SCSI ID 7 Clk 40MHz CCYC%000 CCF=8 TOut 167 NCR53C90(esp100)
C'est un NCR53C90 à priori et pas un NCR53C94.
Ah oui, la SS5 n'a qu'un ESP100, en effet. M'enfin ils sont compatibles,
à une queue de vache près.
s/une queue de vache près/des bugs/
Il suffit de voir le méchant hack dans que j'ai dû faire dans le
driver ESP de linux pour faire tourner le bousin.
Ou alors, c'est une queue de salers ;-)
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 02-09-2008, à propos de Re: NetBSD SPARC et qemu-system-sparc, Miod Vallat écrivait dans fr.comp.os.bsd :
Visiblement l'émulation du NCR53C94 ou des transferts DMA n'est pas fonctionnelle.
Sous un linux, ça marche. La ligne esp du dmesg dit: esp0: IRQ 36 SCSI ID 7 Clk 40MHz CCYC%000 CCF=8 TOut 167 NCR53C90(esp100)
C'est un NCR53C90 à priori et pas un NCR53C94.
Ah oui, la SS5 n'a qu'un ESP100, en effet. M'enfin ils sont compatibles, à une queue de vache près.
s/une queue de vache près/des bugs/
Il suffit de voir le méchant hack dans que j'ai dû faire dans le driver ESP de linux pour faire tourner le bousin.
Ou alors, c'est une queue de salers ;-)
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Miod Vallat
> J'ai essayé de mettre le0 comme root device. Ca effectue une requête DHCP, mais il lui manque l'image du netboot. Pourtant, qemu émule un serveur DHCP, un serveur tftp, et une annonce bootp: qemu-system-sparc -tftp /var/samba/iso/SPARC -bootp /boot.net Là, qemu doit donner ce qu'il faut à netBSD pour booter sur le réseau, mais: nfs_boot: trying DHCP/BOOT¨P nfs_boot: DHCP next-serveur 10.0.2.2 nfs_boot: my_addr.0.2.15 nfs_boot: my_mask%5.255.255.0 nfs_boot: gateway.0.2.2 nfs_boot: getfh - no pathname no file system for le0 cannot mount roor, error = 79
Ben justement, il a chargé boot.net, qui ensuite a chargé un noyal (ces messages proviennent du noyal, si je ne m'abuse). Celui-ci, en revanche, n'a pas eu de réponse satisfaisante pour monter sa racine en nfs.
Il faudrait que la réponse DHCP contienne le chemin du système de fichier à monter (option root-path).
> J'ai essayé de mettre le0 comme root device. Ca effectue une requête
DHCP, mais il lui manque l'image du netboot. Pourtant, qemu émule
un serveur DHCP, un serveur tftp, et une annonce bootp:
qemu-system-sparc -tftp /var/samba/iso/SPARC -bootp /boot.net
Là, qemu doit donner ce qu'il faut à netBSD pour booter sur le réseau,
mais:
nfs_boot: trying DHCP/BOOT¨P
nfs_boot: DHCP next-serveur 10.0.2.2
nfs_boot: my_addr.0.2.15
nfs_boot: my_mask%5.255.255.0
nfs_boot: gateway.0.2.2
nfs_boot: getfh - no pathname
no file system for le0
cannot mount roor, error = 79
Ben justement, il a chargé boot.net, qui ensuite a chargé un noyal (ces
messages proviennent du noyal, si je ne m'abuse). Celui-ci, en revanche,
n'a pas eu de réponse satisfaisante pour monter sa racine en nfs.
Il faudrait que la réponse DHCP contienne le chemin du système de
fichier à monter (option root-path).
> J'ai essayé de mettre le0 comme root device. Ca effectue une requête DHCP, mais il lui manque l'image du netboot. Pourtant, qemu émule un serveur DHCP, un serveur tftp, et une annonce bootp: qemu-system-sparc -tftp /var/samba/iso/SPARC -bootp /boot.net Là, qemu doit donner ce qu'il faut à netBSD pour booter sur le réseau, mais: nfs_boot: trying DHCP/BOOT¨P nfs_boot: DHCP next-serveur 10.0.2.2 nfs_boot: my_addr.0.2.15 nfs_boot: my_mask%5.255.255.0 nfs_boot: gateway.0.2.2 nfs_boot: getfh - no pathname no file system for le0 cannot mount roor, error = 79
Ben justement, il a chargé boot.net, qui ensuite a chargé un noyal (ces messages proviennent du noyal, si je ne m'abuse). Celui-ci, en revanche, n'a pas eu de réponse satisfaisante pour monter sa racine en nfs.
Il faudrait que la réponse DHCP contienne le chemin du système de fichier à monter (option root-path).
Miod Vallat
>> Ah oui, la SS5 n'a qu'un ESP100, en effet. M'enfin ils sont compatibles, à une queue de vache près.
s/une queue de vache près/des bugs/
Il suffit de voir le méchant hack dans que j'ai dû faire dans le driver ESP de linux pour faire tourner le bousin.
Je ne parlais pas dans le contexte de systèmes d'exploitation sous-développés.
>> Ah oui, la SS5 n'a qu'un ESP100, en effet. M'enfin ils sont compatibles,
à une queue de vache près.
s/une queue de vache près/des bugs/
Il suffit de voir le méchant hack dans que j'ai dû faire dans le
driver ESP de linux pour faire tourner le bousin.
Je ne parlais pas dans le contexte de systèmes d'exploitation
sous-développés.
>> Ah oui, la SS5 n'a qu'un ESP100, en effet. M'enfin ils sont compatibles, à une queue de vache près.
s/une queue de vache près/des bugs/
Il suffit de voir le méchant hack dans que j'ai dû faire dans le driver ESP de linux pour faire tourner le bousin.
Je ne parlais pas dans le contexte de systèmes d'exploitation sous-développés.
JKB
Le 02-09-2008, à propos de Re: NetBSD SPARC et qemu-system-sparc, Miod Vallat écrivait dans fr.comp.os.bsd :
Ah oui, la SS5 n'a qu'un ESP100, en effet. M'enfin ils sont compatibles, à une queue de vache près.
s/une queue de vache près/des bugs/
Il suffit de voir le méchant hack dans que j'ai dû faire dans le driver ESP de linux pour faire tourner le bousin.
Je ne parlais pas dans le contexte de systèmes d'exploitation sous-développés.
Je maintiens qu'un masque d'interruption qui n'est pas réinitialisé lors du traitement de ladite interruption relève d'un bug du composant (bug d'ailleurs corrigé dans les successeurs de l'ESP100).
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 02-09-2008, à propos de
Re: NetBSD SPARC et qemu-system-sparc,
Miod Vallat écrivait dans fr.comp.os.bsd :
Ah oui, la SS5 n'a qu'un ESP100, en effet. M'enfin ils sont compatibles,
à une queue de vache près.
s/une queue de vache près/des bugs/
Il suffit de voir le méchant hack dans que j'ai dû faire dans le
driver ESP de linux pour faire tourner le bousin.
Je ne parlais pas dans le contexte de systèmes d'exploitation
sous-développés.
Je maintiens qu'un masque d'interruption qui n'est pas réinitialisé
lors du traitement de ladite interruption relève d'un bug du composant
(bug d'ailleurs corrigé dans les successeurs de l'ESP100).
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 02-09-2008, à propos de Re: NetBSD SPARC et qemu-system-sparc, Miod Vallat écrivait dans fr.comp.os.bsd :
Ah oui, la SS5 n'a qu'un ESP100, en effet. M'enfin ils sont compatibles, à une queue de vache près.
s/une queue de vache près/des bugs/
Il suffit de voir le méchant hack dans que j'ai dû faire dans le driver ESP de linux pour faire tourner le bousin.
Je ne parlais pas dans le contexte de systèmes d'exploitation sous-développés.
Je maintiens qu'un masque d'interruption qui n'est pas réinitialisé lors du traitement de ladite interruption relève d'un bug du composant (bug d'ailleurs corrigé dans les successeurs de l'ESP100).
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Kevin Denis
Le 02-09-2008, Miod Vallat a écrit :
J'ai essayé de mettre le0 comme root device. Ca effectue une requête DHCP, mais il lui manque l'image du netboot. Pourtant, qemu émule un serveur DHCP, un serveur tftp, et une annonce bootp: qemu-system-sparc -tftp /var/samba/iso/SPARC -bootp /boot.net Là, qemu doit donner ce qu'il faut à netBSD pour booter sur le réseau, mais: nfs_boot: trying DHCP/BOOT¨P nfs_boot: DHCP next-serveur 10.0.2.2 nfs_boot: my_addr.0.2.15 nfs_boot: my_mask%5.255.255.0 nfs_boot: gateway.0.2.2 nfs_boot: getfh - no pathname no file system for le0 cannot mount roor, error = 79
Ben justement, il a chargé boot.net, qui ensuite a chargé un noyal (ces messages proviennent du noyal, si je ne m'abuse).
Hélas, tu t'abuses. C'est le noyal situé dans minirootfs qui est chargé. Tant qu'a demander un root, je lui ai donné le0. C'est là ou j'ai vu partir une requête DHCP, d'où l'idée d'utiliser un netboot. Ca aurait abouti à une situation curieuse ou un noyau aurait chargé un noyau, mébon, je ne suis plus à une contorsion près.
Celui-ci, en revanche, n'a pas eu de réponse satisfaisante pour monter sa racine en nfs.
Il faudrait que la réponse DHCP contienne le chemin du système de fichier à monter (option root-path).
Et là, c'est le serveur DHCP interne de qemu qui manque de configurabilité. Je vais creuser tout de même. -- Kevin
Le 02-09-2008, Miod Vallat <miod@online.fr> a écrit :
J'ai essayé de mettre le0 comme root device. Ca effectue une requête
DHCP, mais il lui manque l'image du netboot. Pourtant, qemu émule
un serveur DHCP, un serveur tftp, et une annonce bootp:
qemu-system-sparc -tftp /var/samba/iso/SPARC -bootp /boot.net
Là, qemu doit donner ce qu'il faut à netBSD pour booter sur le réseau,
mais:
nfs_boot: trying DHCP/BOOT¨P
nfs_boot: DHCP next-serveur 10.0.2.2
nfs_boot: my_addr.0.2.15
nfs_boot: my_mask%5.255.255.0
nfs_boot: gateway.0.2.2
nfs_boot: getfh - no pathname
no file system for le0
cannot mount roor, error = 79
Ben justement, il a chargé boot.net, qui ensuite a chargé un noyal (ces
messages proviennent du noyal, si je ne m'abuse).
Hélas, tu t'abuses. C'est le noyal situé dans minirootfs qui est chargé.
Tant qu'a demander un root, je lui ai donné le0. C'est là ou j'ai vu
partir une requête DHCP, d'où l'idée d'utiliser un netboot. Ca aurait
abouti à une situation curieuse ou un noyau aurait chargé un noyau,
mébon, je ne suis plus à une contorsion près.
Celui-ci, en revanche,
n'a pas eu de réponse satisfaisante pour monter sa racine en nfs.
Il faudrait que la réponse DHCP contienne le chemin du système de
fichier à monter (option root-path).
Et là, c'est le serveur DHCP interne de qemu qui manque de configurabilité.
Je vais creuser tout de même.
--
Kevin
J'ai essayé de mettre le0 comme root device. Ca effectue une requête DHCP, mais il lui manque l'image du netboot. Pourtant, qemu émule un serveur DHCP, un serveur tftp, et une annonce bootp: qemu-system-sparc -tftp /var/samba/iso/SPARC -bootp /boot.net Là, qemu doit donner ce qu'il faut à netBSD pour booter sur le réseau, mais: nfs_boot: trying DHCP/BOOT¨P nfs_boot: DHCP next-serveur 10.0.2.2 nfs_boot: my_addr.0.2.15 nfs_boot: my_mask%5.255.255.0 nfs_boot: gateway.0.2.2 nfs_boot: getfh - no pathname no file system for le0 cannot mount roor, error = 79
Ben justement, il a chargé boot.net, qui ensuite a chargé un noyal (ces messages proviennent du noyal, si je ne m'abuse).
Hélas, tu t'abuses. C'est le noyal situé dans minirootfs qui est chargé. Tant qu'a demander un root, je lui ai donné le0. C'est là ou j'ai vu partir une requête DHCP, d'où l'idée d'utiliser un netboot. Ca aurait abouti à une situation curieuse ou un noyau aurait chargé un noyau, mébon, je ne suis plus à une contorsion près.
Celui-ci, en revanche, n'a pas eu de réponse satisfaisante pour monter sa racine en nfs.
Il faudrait que la réponse DHCP contienne le chemin du système de fichier à monter (option root-path).
Et là, c'est le serveur DHCP interne de qemu qui manque de configurabilité. Je vais creuser tout de même. -- Kevin
