Archives du mot-clé U-Boot

Linux boote!!!

Nous avons reçu et soudé le circuit.

2014-06-15-120902

Dans un premier temps, nous avons réussi à lancer u-boot sur le circuit, ce qui nous a déjà ravis, car nous avions enfin accès à une console, même si ce n’était pas encore une console linux. Par contre, le circuit semblait très instable. En effet u-boot ne bootait qu’une fois sur quinze :

HTLC
HTLC
HTLCLCU-Boot 2014.01 (Mar 07 2014 – 13:42:07)CPU: Freescale i.MX23 rev1.4 at 454 MHz
BOOT: SSP SD/MMC #0
DRAM: 64 MiB
MMC: MXS MMC: 0HTLCL0x80501002
HTLCL0x80501002
HTLCL0x80501002
HTLCL0x80501002
HTLCLCU-Boot 2014.01 (Mar 07 2014 – 13:42:07)CPU: Freescale i.MX23 rev1.4 at 454 MHz
BOOT: SSP SD/MMC #0
DRAM: 64 MiB
HTLCLCU-Boot 2014.01 (Mar 07 2014 – 13:42:07)CPU: Freescale i.MX23 rev1.4 at 454 MHz
BOOT: SSP SD/MMC #0
DRAM: 64 MiB
MMC: MXS MMC: 0
*** Warning – bad CRC, using default environmentIn: serial
Out: serial
Err: serial
Net: Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot: 0
mmc0 is current device
** No partition table – mmc 0 **
** No partition table – mmc 0 **
Booting from net …
(Re)start USB…
USB0: USB EHCI 1.00
scanning bus 0 for devices… 1 USB Device(s) found
scanning usb for storage devices… 0 Storage Device(s) found
scanning usb for ethernet devices… 0 Ethernet Device(s) found
No ethernet found.
Wrong Image Format for bootm command
ERROR: can t get kernel image!
=> help
? – alias for help
base – print or set address offset
bdinfo – print Board Info structure
boot – boot default, i.e., run bootcmd
bootd – boot default, i.e., run bootcmd
bootm – boot application image from memory
bootp – boot image via network using BOOTP/TFTP protocol
clocks – display clocks
cmp – memory compare
coninfo – print console devices and information
cp – memory copy
crc32 – checksum calculation
dcache – enable or disable data cache
dhcp – boot image via network using DHCP/TFTP protocol
echo – echo args to console
editenv – edit environment variable
env – environment handling commands
exit – exit script
ext2load- load binary file from a Ext2 filesystem
ext2ls – list files in a directory (default /)
false – do nothing, unsuccessfully
fatinfo – print information about filesystem
fatload – load binary file from a dos filesystem
fatls – list files in a directory (default /)
fdt – flattened device tree utility commands
go – start application at address addr
gpio – input/set/clear/toggle gpio pins
help – print command description/usage
icache – enable or disable instruction cache
iminfo – print header information for application image
imxtract- extract a part of a multi-image
itest – return true/false on integer compare
led – [0|all] [on|off|toggle]
loadb – load binary file over serial line (kermit mode)
loads – load S-Record file over serial line
loadx – load binary file over serial line (xmodem mode)
loady – load binary file over serial line (ymodem mode)
loop – infinite loop on address range
md – memory display
mm – memory modify (auto-incrementing address)
mmc – MMC sub system
mmcinfo – display MMC info
mw – memory write (fill)
nfs – boot image via network using NFS protocol
nm – memory modify (constant address)
printenv- print environment variables
reset – Perform RESET of the CPU
run – run commands in an environment variable
saveenv – save environment variables to persistent storage
setenv – set environment variables
showvar – print local hushshell variables
sleep – delay execution for some time
source – run script from memory
test – minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
true – do nothing, successfully
usb – USB sub-system
usbboot – boot from USB device
version – print monitor, compiler and linker version
=> pierre
Unknown command pierre – try help
=>

 

Nous avons passé des heures et des heures à dessouder et à ressouder des composants. Nous avons également essayé de booter par USB via mxsldr pour voir ce qu’il se passait. Cela nous a amené à corriger une faiblesse dans mxsldr, qui est désormais présente sur le git officiel.

Continuer la lecture

Réalisation d’une image système pour ARM : U-boot / Linux / Debian

Aujourd’hui, nous allons travailler sur la partie système de notre calculatrice. L’objectif est de pouvoir lancer nos propres logiciels et de proposer suffisamment de souplesse pour que l’utilisateur puisse lui aussi adapter le système à ses besoins.

Depuis le début du projet, nous souhaitions utiliser un noyau Linux. C’est certainement le noyau libre le plus répandu. En choisissant Linux, nous sommes certains de trouver de la documentation et de l’aide en cas de besoin, en particulier lorsqu’il faudra mettre les mains dans le code pour supporter nos propres périphériques ! C’est aussi certainement le noyau qui supporte le plus de fonctionnalités, et le plus de matériels. De plus, le design de notre board est fortement inspiré de celui d’une Olinuxino Micro, qui utilise un SoC iMX.233.  Ce SoC semble bien supporté par Linux, nous espérons donc une mise en place sans surprise du noyau Linux sur notre board.

C’est donc décidé pour le noyau. Nous pourrions ensuite choisir de lancer directement notre émulateur de TI-83, ou un autre logiciel, directement après le boot du noyau Linux. Mais au contraire, l’intérêt de notre matériel est de fournir un système standard, sur lequel l’utilisateur pourra se sentir à l’aise et en terrain connu. Quoi de mieux alors, pour la distribution logiciels, que Debian ? :-) N’importe quel logiciel ou presque, à portée de apt-get !

Il reste une composante importante du système à déterminer, le bootloader. En effet, le mécanisme de boot du SoC ne permet pas d’amorcer directement sur le noyau Linux. Il faut un composant logiciel intermédiaire, légé, qui chargera le noyau Linux en RAM puis l’exécutera. Le bootloader offre aussi de la souplesse pendant la phase de boot : pouvoir charger le noyau depuis le réseau, depuis une clé usb, sur une partition en FAT32 ou en ext4… Ces fonctionnalités peuvent être utiles !

Notre choix se porte sur U-Boot. En effet, U-Boot est également très répandu, en particulier sur le matériel embarqué, plutôt bien documenté et supporte notre board de référence, la Olinuxino Micro.

En résumé, notre système est constitué de trois composantes :

  • U-Boot, le bootloader. Charge le noyau Linux en RAM et l’exécute.
  • Le noyau Linux. Supporte les périphériques présents sur la board.
  • Debian, la distribution logiciels.

Continuer la lecture

Premier circuit linux, avec kicad

Nous allons essayer de réaliser un premier circuit sur lequel linux pourra booter, condition indispensable à la réalisation de notre calculatrice libre.

Nous avons tout d’abord décidé d’utiliser comme logiciel de conception électronique Kicad. Car c’est le logiciel libre le plus performant et le plus utilisé pour réaliser cette tache. Il est de plus dans une phase de développement rapide, car le CERN investit du temps pour son développement, et a proposé notamment une fonctionnalité push and shove des plus prometteuses.

Concernant la conception de notre circuit, nous avons décidé d’utiliser le processeur imx233, car il parait simple à utiliser, il est facile à se procurer,  il existe un package lqfp facile à souder et de nombreux designs de références existent pour ce processeur :

Malheureusement, il n’existe aucun circuit routé et libre d’imx233 utilisant kicad. Ceux de Olimex sont libres mais utilisent Eagle, un logiciel non-libre, ce qui va à l’encontre des principes de ce projet. Il existe par contre une librairie Kicad pour le imx233 réalisée par Opendous. Nous les remercions beaucoup pour cela car ça nous a été très utile.

La première étape a été de réaliser la partie schémas électroniques avec kicad (eeschemas) . Nous relions la ram au processeur grâce à des liens symboliques (sur le schémas, ce sont les rectangles en forme de flèches rouge).

firstCircuitschem1firstCircuitschem2

La partie comptant tous les condensateurs de découplage a été mise dans une autre feuille afin de rendre le schéma principal plus lisible.

Une fois la partie schéma électronique réalisée, on passe à l’association des empruntes.

Nous avons décidé de router ce circuit en deux couches. Cela ne semblait pas être un problème pour le fonctionnement du circuit et cela paraissait plus simple dans un premier temps. N’étant pas électroniciens, c’était la première fois que l’on routait un circuit deux couches. Le routage a été long et un peu compliqué mais nous avons fini par réussir.firstProtoCircuit

Nous avons envoyé le circuit a la production, et l’avons reçu en quatre exemplaires.

Concernant la réalisation du circuit, nous avons eu au début du mal à le souder de manière fiable à la main, puis nous avons trouvé des techniques permettant de le souder facilement chez nous, ne nécessitant pas de matériel spécialisé. Nous écrirons un article à ce sujet dans le futur.

Une fois soudé, nous avons tenté d’alimenter le circuit et de voir ce qui arrivait sur le port UART grâce à un convertisseur usb-uart de type umft230xb. Dans un premier temps sans avoir inséré de carte SD dans le circuit.

Tout d’abord rien ne se passait, ou plutôt il n’y avait sur l’UART que des symboles bizarres. Nous nous sommes rendu compte que nous avions oublié dans les schémas un condensateur de 100nF sur VDDXTAL, qui est donc très important et sans quoi le imx ne fonctionnera pas.

Une fois cela réalisé, nous avons réessayé, toujours sans carte SD insérée. Nous avons alors obtenu sur l’UART  » 0x8020a014 « .

01-circuit

Ensuite nous avons eu du mal à formater la carte SD comme il le fallait afin qu’elle soit reconnue comme bootable par la imx 233. En effet, avec un formatage en MBR tel que celui proposé par Olimex nous obtenions l’erreur  » 0x8020A007 « .

Nous avons trouvé des scripts afin de formater la carte SD correctement. Ces scripts sont disponibles sur la liste de diffusion d’opendous. Afin de formater correctement une carte SD, il convient d’exécuter les scripts dans cet ordre:

perl ./write_bootstream.pl u-boot.sb /dev/mmbclk0
perl ./bootstream_make_bootable.pl u-boot.sb /dev/mmbclk0

Finalement après avoir réussi à formater la carte SD correctement, nous obtenions « HTLC » puis le circuit rebootait avec u-boot.

Nous avons à ce point demandé de l’aide sur le forum de freescale

https://community.freescale.com/thread/320520

Nous somme finalement arrivé à la conclusion, grâce aux personnes qui nous ont aidé sur ce thread, qu’il nous fallait refaire un circuit avec un meilleur routage si nous souhaitions espérer qu’il puisse booter.

Télécharger les sources du circuit non-fonctionel: firstProto.tar