Et lidt underligt spørgsmål måske, men er der nogen der har gjort sig erfaringer med Micro:bit i frostvejr – Er den stabil, og kan den starte op i f.eks. -20 grader ? Jeg har googlet – men søgeresultatet på de relevante søgning er temmelig forurenet af at der jo er en indbygget temperatursensor…
Ja, det ser da lidt underligt ud. Der er ikke opgivet nogen driftstemperatur (“oprarating temperature”) eller for så vidt opbevaringstemperatur (“storage temperature”) i specifikationerne for hverken V1.5 (https://tech.microbit.org/hardware/1-5-revision/) eller V2 (https://tech.microbit.org/hardware/). En søgning i dokumentationens git-arkiv bekræfter at der kun nævnes noget om temperaturer når den indbyggede sensor i nRF-SoC’en omtales (https://github.com/microbit-foundation/dev-docs/search?q=temperature+&type=). Ligeledes bruges ordet “operating” kun om spænding, strøm og system (=OS) (https://github.com/microbit-foundation/dev-docs/search?q=operating&type=). Så den oplysning er Micro:bit Foundation åbenbart ikke særligt vilde med at dele, hvilket tyder på at det ikke har været en prioritet under design og produktion (hvilket er forståeligt nok for et ikke-industrielt stykke undervisningsmateriale). Så du skal nok under alle omstændigheder ikke forvente en konsistent oplevelse. Hvis man skulle give et kvalificeret bud, kunne man kigger på hovedkomponenternes specificerede driftstemperaturer, hvilket i hvert fald siger noget om de øvre og nedre grænser, men komponenternes komplekse interaktioner med hinanden (mekanisk, termisk, elektrisk) i det færdige produkt har selvfølgelig betydning for de endelige grænser. V1.5: nRF51822 (primær SoC): -25 – 75 grader C (http://infocenter.nordicsemi.com/pdf/nRF51822_PS_v3.1.pdf#page=38) KL26 (USB-interfacechip): -40 – 105 grader C: (http://www.nxp.com/docs/pcn_attachments/16440_KL26P64M48SF5_Rev.4.pdf) V2: nRF52833 (primær SoC): -40 – 85 grader C (kan gå op til 105 grader C under specielle betingelser) (https://infocenter.nordicsemi.com/pdf/nRF52833_PS_v1.3.pdf#page=608) KL27 (USB-interfacechip): -40 – 105 grader C (https://www.nxp.com/docs/en/data-sheet/KL27P64M48SF6.pdf) Det giver da et fingerpeg, god fornøjelse med fryseren ;).
Lidt flere dråber i Spørgsmål&Svar-kategorien fra Facebook.
Når jeg endelig forvilder mig derind, og går på opdagelse i de tekniske grupper, ender det ofte med at får jeg skrevet en fristil i forsøget på at hjælpe.
Denne gang en snak om Android på “PC”, og basale digitale processeringsbehov for den almindelige dansker.
Stillet i gruppen “Danske Android Brugere “:
Er der nogen som ved, om man kan få en pc med Android system?
Mit svar:
Som andre omtaler, kan der fås en uofficiel variant af det frie styresystem Android til x86-arkitekturen (den gængse Intel/AMD-baserede computer kendt som “personlig computer”). Det projekt lever på https://www.android-x86.org/. Installationsvejledning på engelsk er på https://www.android-x86.org/installhowto.html. Man kan både installere som multiboot på samme disk som et eksisterende operativsystem, starte fra en ekstern disk (USB-medie, cd/dvdrom e.l.) eller evt. køre i en virtuel maskine på et eksisterende operativsystem (VirtualBox,QEMU/KVM, VMware Player/Workstation). Jeg har kun erfaring med livedisk boot fra USB og VM, og der synes jeg ikke altid tingene spiller perfekt, så forvent ikke en helt problemfri oplevelse. “Android på PC” er på kanten af noget understøttet, hvor man ofte er på egen hånd. Nogle af folkene bag Andoid-x86 forsøgte at lave en kommerciel forretning på det, hvor det var tanken at sælge det som færdige hardwareenheder, RemixOS – https://en.wikipedia.org/wiki/Remix_OS, men det gik ikke så godt og er lukket ned igen. Hvis behovet bare er “en bærbar computer uden for meget vrøvl”, så er en færdig Chromebook med Chrome OS (der ligesom Android også er bygget på GNU/Linux) eller noget af det der dyre Frugt-udstyr nok det mest tilgængelige (men jeg fornemmer at pris også kunne være en faktor?). Til forskel fra traditionelle operativsystemer til computere, er Chrome OS dog møntet specifikt på at få dig til at bruge Googles webbaserede tjenester (mere om softwaren bag på https://www.chromium.org/chromium-os), så hverken software eller hardware er beregnet til at lagre data på selve enheden, og der er sjældent meget diskplads tilgængelig til f.eks. billeder. Et hurtigt kig på markedet identificerer Acer Chromebook 15 (https://www.edbpriser.dk/produkt/acer-chromebook-15-cb515-1h-c7kg/) og Lenovo S330 (https://www.edbpriser.dk/produkt/lenovo-chromebook-s330-81jw-3292492/) som populære Chromebook i 2k kr.-klassen, men kender ikke maskinerne specifikt. God jagt :).
Som andre omtaler, kan der fås en uofficiel variant af det frie styresystem Android til x86-arkitekturen (den gængse Intel/AMD-baserede computer kendt som “personlig computer”).
Det projekt lever på https://www.android-x86.org/. Installationsvejledning på engelsk er på https://www.android-x86.org/installhowto.html. Man kan både installere som multiboot på samme disk som et eksisterende operativsystem, starte fra en ekstern disk (USB-medie, cd/dvdrom e.l.) eller evt. køre i en virtuel maskine på et eksisterende operativsystem (VirtualBox,QEMU/KVM, VMware Player/Workstation).
Jeg har kun erfaring med livedisk boot fra USB og VM, og der synes jeg ikke altid tingene spiller perfekt, så forvent ikke en helt problemfri oplevelse.
“Android på PC” er på kanten af noget understøttet, hvor man ofte er på egen hånd. Nogle af folkene bag Andoid-x86 forsøgte at lave en kommerciel forretning på det, hvor det var tanken at sælge det som færdige hardwareenheder, RemixOS – https://en.wikipedia.org/wiki/Remix_OS, men det gik ikke så godt og er lukket ned igen.
Hvis behovet bare er “en bærbar computer uden for meget vrøvl”, så er en færdig Chromebook med Chrome OS (der ligesom Android også er bygget på GNU/Linux) eller noget af det der dyre Frugt-udstyr nok det mest tilgængelige (men jeg fornemmer at pris også kunne være en faktor?). Til forskel fra traditionelle operativsystemer til computere, er Chrome OS dog møntet specifikt på at få dig til at bruge Googles webbaserede tjenester (mere om softwaren bag på https://www.chromium.org/chromium-os), så hverken software eller hardware er beregnet til at lagre data på selve enheden, og der er sjældent meget diskplads tilgængelig til f.eks. billeder.
Et hurtigt kig på markedet identificerer Acer Chromebook 15 (https://www.edbpriser.dk/produkt/acer-chromebook-15-cb515-1h-c7kg/) og Lenovo S330 (https://www.edbpriser.dk/produkt/lenovo-chromebook-s330-81jw-3292492/) som populære Chromebook i 2k kr.-klassen, men kender ikke maskinerne specifikt.
God jagt :).
EDIT: further images from this process were lost in a phone smash incident, sorry
Here’s a preliminary HOWTO from my recent external flashing of the BIOS ROM on a Lenovo X200 thinkpad (Wikipedia). The particular firmware flashed was a Libreboot build for this machine (instructions for X200 and details of the external flashing procedure) but anything goes (but anything may not be useful, though).
I’ll amend this HOWTO with more detailed instructions and pictures in the following days (warning: a prediction) to hopefully make it more complete and useful for the vary inhabitants of LibreBootLand.
A programmer kit was bought on AliExpress for $4.20 containing a USB programmer board and an SOIC-8 clip which ended up not being used as the particular X200 had a SOIC-16 chip so a separately ordered SOIC-16 chip ($3.11) was used.
Buy: https://www.aliexpress.com/item/32898599200.html @ $4.20
The programmer is based on the WCH CH341a chip which is an USB <-> seriel/parallel/uart interface. The manufacturer WCH being WinChipHead aka. WCH (Nanjing QinHeng Electronics Co.,Ltd) (maybe also aka. WCH-IC (Jiangsu Qinheng Co., Ltd)). There are lots of options for buying board varieties based on the CH341a chip, to get you started here is a BangGood search and an AliExpress search.
Boards like this has also been described by others including a deduced schematic, EEVblog critique of the I/O pin power on similar boards (not yet confirmed whether that is true for this programmer too, I guess so, but at least one flashing done without damage) and a mention on hackaday of other board types.
There are a bunch of downloads from the WCH site regarding the chip including a Chinese datasheet, no English language documentation seems to be available from the manufacturer however. There are some English editions of the datasheet to be found, of unknown origin. They seem plausible enough to use, though. Somebody has attempted to collect documentation about the chip in a Git repository.
Buy: https://www.aliexpress.com/item/32869145935.html @ $3.11
To attach physically to the Macronix MX25L6405D flash memory chip in a SOIC-16 package present on the X200 in question (words are that this is the norm although the board can be populated with a SOIC-8 too) a clip that matches the pins of the SOIC-16 package is needed. I bought the one mentioned above for $3.11 at random from AliExpress and this worked fine. In the pictures the wiring is hooked up correctly to the programmer to allow for flashing as described below.
6405 <-> CH341a
MISO<->MIOS (label error, should be MISO)
MOSI<->MOSI
CLK <-> CLK
CS <-> SS
GND <-> GND
First tried driving the the flash chip from VDD on ch341a but this was unsuccessful, no chip could be found, so the 6405 was hooked up to external 3.3v power supply with supply GND connected to GND on CH341a to align the ground potential between ch341a I/O supply and 6405 supply (important!).
To get the latest ECP (Embedded Controller Program) from Lenovo (no free alternative exists) containing software for the MCU controlling low level hardware like battery charging/keyboard/backlight stuff you need to update the BIOS which also updates the ECP. Most recent version for X200 is “BIOS: 3.22 / ECP: 1.07“. This is not needed if you already have these versions on the machine, check current versions by pressing ThinkVantage during boot and choosing “Enter Setup”. If your system has a Windows installation download and run the “BIOS Update Utility“executeable. Else you’ll need to get the “BIOS Update Bootable CD” and somehow get it on a CD and find a CD-ROM drive. Alternatively on a Linux system the CD file system can be extracted and added to Grub to be directly bootable. Below was done on an Ubuntu 16.04 system: $ sudo apt install genisoimage syslinux $ wget -q https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/6duj48us.iso $ geteltorito 6duj48us.iso > 6duj48us.img Booting catalog starts at sector: 20 Manufacturer of CD: NERO BURNING ROM Image architecture: x86 Boot media type is: harddisk El Torito image starts at sector 27 and has 75776 sector(s) of 512 Bytes Image has been written to stdout …. $ sudo cp 6duj48us.im /boot $ sudo cp /usr/lib/syslinux/memdisk /boot $ sudo nano /etc/grub.d/40_custom <add lines below to the end of file, preserve the “exec tail…” line> menuentry “BIOS Update” { linux16 /memdisk initrd16 /6duj48us.im } $ sudo update-grub Reboot, press <left shift> key while booting to access Grub, choose BIOS Update menu entry and follow the Lenovo update procedure. To start flashing it requires both a connected power supply and also a working, non-exhausted battery (!) mounted in the machine. This is tiresome for owners of worn out batteries… Some notes about the flashing process can be found in the documentation of a patch set for the Lenovo BIOS.
To get the latest ECP (Embedded Controller Program) from Lenovo (no free alternative exists) containing software for the MCU controlling low level hardware like battery charging/keyboard/backlight stuff you need to update the BIOS which also updates the ECP. Most recent version for X200 is “BIOS: 3.22 / ECP: 1.07“. This is not needed if you already have these versions on the machine, check current versions by pressing ThinkVantage during boot and choosing “Enter Setup”.
If your system has a Windows installation download and run the “BIOS Update Utility“executeable. Else you’ll need to get the “BIOS Update Bootable CD” and somehow get it on a CD and find a CD-ROM drive. Alternatively on a Linux system the CD file system can be extracted and added to Grub to be directly bootable. Below was done on an Ubuntu 16.04 system:
$ sudo apt install genisoimage syslinux $ wget -q https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/6duj48us.iso $ geteltorito 6duj48us.iso > 6duj48us.img Booting catalog starts at sector: 20 Manufacturer of CD: NERO BURNING ROM Image architecture: x86 Boot media type is: harddisk El Torito image starts at sector 27 and has 75776 sector(s) of 512 Bytes Image has been written to stdout …. $ sudo cp 6duj48us.im /boot $ sudo cp /usr/lib/syslinux/memdisk /boot $ sudo nano /etc/grub.d/40_custom <add lines below to the end of file, preserve the “exec tail…” line> menuentry “BIOS Update” { linux16 /memdisk initrd16 /6duj48us.im } $ sudo update-grub Reboot, press <left shift> key while booting to access Grub, choose BIOS Update menu entry and follow the Lenovo update procedure. To start flashing it requires both a connected power supply and also a working, non-exhausted battery (!) mounted in the machine. This is tiresome for owners of worn out batteries… Some notes about the flashing process can be found in the documentation of a patch set for the Lenovo BIOS.
$ sudo apt install genisoimage syslinux $ wget -q https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/6duj48us.iso $ geteltorito 6duj48us.iso > 6duj48us.img Booting catalog starts at sector: 20 Manufacturer of CD: NERO BURNING ROM Image architecture: x86 Boot media type is: harddisk El Torito image starts at sector 27 and has 75776 sector(s) of 512 Bytes Image has been written to stdout …. $ sudo cp 6duj48us.im /boot $ sudo cp /usr/lib/syslinux/memdisk /boot $ sudo nano /etc/grub.d/40_custom <add lines below to the end of file, preserve the “exec tail…” line> menuentry “BIOS Update” { linux16 /memdisk initrd16 /6duj48us.im } $ sudo update-grub
Reboot, press <left shift> key while booting to access Grub, choose BIOS Update menu entry and follow the Lenovo update procedure. To start flashing it requires both a connected power supply and also a working, non-exhausted battery (!) mounted in the machine. This is tiresome for owners of worn out batteries…
Some notes about the flashing process can be found in the documentation of a patch set for the Lenovo BIOS.
sudo apt install flashrom
ch341a support in flashrom
Download the stable LibreBoot firmware: https://www.mirrorservice.org/sites/libreboot.org/release/stable/20160907/rom/grub/libreboot_r20160907_grub_x200_8mb.tar.xz
The brave will of course want to compile it themselves.
$ cd $ wget https://www.mirrorservice.org/sites/libreboot.org/release/stable/20160907/rom/grub/libreboot_r20160907_grub_x200_8mb.tar.xz --2019-06-07 07:35:21-- https://www.mirrorservice.org/sites/libreboot.org/release/stable/20160907/rom/grub/libreboot_r20160907_grub_x200_8mb.tar.xz Resolving www.mirrorservice.org (www.mirrorservice.org)... 212.219.56.184, 2001:630:341:12::184 Connecting to www.mirrorservice.org (www.mirrorservice.org)|212.219.56.184|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 1632800 (1,6M) [application/x-xz] Saving to: ‘libreboot_r20160907_grub_x200_8mb.tar.xz’ libreboot_r20160907_grub_x200_8mb.tar.xz 100%[================================================================================>] 1,56M --.-KB/s in 0,1s 2019-06-07 07:35:21 (13,9 MB/s) - ‘libreboot_r20160907_grub_x200_8mb.tar.xz’ saved [1632800/1632800] $ tar tf libreboot_r20160907_grub_x200_8mb.tar.xz libreboot_r20160907_grub_x200_8mb/ libreboot_r20160907_grub_x200_8mb/x200_8mb_deqwertz_txtmode.rom libreboot_r20160907_grub_x200_8mb/x200_8mb_esqwerty_txtmode.rom libreboot_r20160907_grub_x200_8mb/x200_8mb_frazerty_txtmode.rom libreboot_r20160907_grub_x200_8mb/x200_8mb_frdvbepo_txtmode.rom libreboot_r20160907_grub_x200_8mb/x200_8mb_itqwerty_txtmode.rom libreboot_r20160907_grub_x200_8mb/x200_8mb_svenska_txtmode.rom libreboot_r20160907_grub_x200_8mb/x200_8mb_ukdvorak_txtmode.rom libreboot_r20160907_grub_x200_8mb/x200_8mb_ukqwerty_txtmode.rom libreboot_r20160907_grub_x200_8mb/x200_8mb_usdvorak_txtmode.rom libreboot_r20160907_grub_x200_8mb/x200_8mb_usqwerty_txtmode.rom libreboot_r20160907_grub_x200_8mb/x200_8mb_deqwertz_vesafb.rom libreboot_r20160907_grub_x200_8mb/x200_8mb_esqwerty_vesafb.rom libreboot_r20160907_grub_x200_8mb/x200_8mb_frazerty_vesafb.rom libreboot_r20160907_grub_x200_8mb/x200_8mb_frdvbepo_vesafb.rom libreboot_r20160907_grub_x200_8mb/x200_8mb_itqwerty_vesafb.rom libreboot_r20160907_grub_x200_8mb/x200_8mb_svenska_vesafb.rom libreboot_r20160907_grub_x200_8mb/x200_8mb_ukdvorak_vesafb.rom libreboot_r20160907_grub_x200_8mb/x200_8mb_ukqwerty_vesafb.rom libreboot_r20160907_grub_x200_8mb/x200_8mb_usdvorak_vesafb.rom libreboot_r20160907_grub_x200_8mb/x200_8mb_usqwerty_vesafb.rom libreboot_r20160907_grub_x200_8mb/ChangeLog libreboot_r20160907_grub_x200_8mb/NEWS libreboot_r20160907_grub_x200_8mb/version libreboot_r20160907_grub_x200_8mb/versiondate $
As the MAC address of the ethnernet PHY is stored in the flash, yo have your X200 ethernet MAC address correspond to the sticker on the back of the machine, and also avoid a potential but improbable DHCP/ARP conflict, the MAC address from the label/ifconfig from the existing system must be embedded into the flash file that we are going to program into the flash chip.
For this a tool called ich9gen is needed, this is a part of the libreboot repository and we need to build it ourselves.
$ git clone https://notabug.org/libreboot/libreboot Cloning into 'libreboot'... remote: Counting objects: 29080, done. remote: Compressing objects: 100% (9855/9855), done. remote: Total 29080 (delta 18748), reused 27899 (delta 18057) Receiving objects: 100% (29080/29080), 63.90 MiB | 11.13 MiB/s, done. Resolving deltas: 100% (18748/18748), done. Checking connectivity... done. $ cd libreboot/projects/ich9gen/sources $ make gcc -I. -Wall -Wextra -g -std=c99 -c src/ich9deblob.c -o obj/ich9deblob.o gcc -I. -Wall -Wextra -g -std=c99 -c src/common/descriptor_gbe.c -o obj/common/descriptor_gbe.o gcc -I. -Wall -Wextra -g -std=c99 -c src/descriptor/descriptor.c -o obj/descriptor/descriptor.o gcc -I. -Wall -Wextra -g -std=c99 -c src/gbe/gbe.c -o obj/gbe/gbe.o gcc -I. -Wall -Wextra -g -std=c99 -c src/common/x86compatibility.c -o obj/common/x86compatibility.o gcc -I. -Wall -Wextra -g -std=c99 obj/ich9deblob.o obj/common/descriptor_gbe.o \ obj/common/x86compatibility.o obj/descriptor/descriptor.o obj/gbe/gbe.o \ -o ich9deblob gcc -I. -Wall -Wextra -g -std=c99 -c src/ich9gen.c -o obj/ich9gen.o gcc -I. -Wall -Wextra -g -std=c99 -c src/ich9gen/mkdescriptor.c -o obj/ich9gen/mkdescriptor.o gcc -I. -Wall -Wextra -g -std=c99 -c src/ich9gen/mkgbe.c -o obj/ich9gen/mkgbe.o gcc -I. -Wall -Wextra -g -std=c99 obj/ich9gen.o obj/ich9gen/mkdescriptor.o obj/ich9gen/mkgbe.o \ obj/common/descriptor_gbe.o \ obj/common/x86compatibility.o obj/descriptor/descriptor.o obj/gbe/gbe.o \ -o ich9gen gcc -I. -Wall -Wextra -g -std=c99 -c src/demefactory.c -o obj/demefactory.o gcc -I. -Wall -Wextra -g -std=c99 obj/demefactory.o obj/common/descriptor_gbe.o \ obj/common/x86compatibility.o obj/descriptor/descriptor.o obj/gbe/gbe.o \ -o demefactory $
Running ich9gen itself generates the flash descriptor (fd) header including possible configuration section where the MAC address is stored for the gigabit ethernet (gbe) PHY onboard the ICH9 chipset. When run six 12 KiB files for respectively 4, 8 and 16 MiB binary images and chipsets including (gbe) and excluding (nogbe) gigabit ethernet PHY are generated.
“aa:bb:cc:dd:ee:ff” in the commandline should be replaced with the actual 12 hex digits from the label on the machine or by running ifconfig on the machine using the existing Lenovo BIOS.
$ cd ~/libreboot_r20160907_grub_x200_8mb/ $ ~/libreboot/projects/ich9gen/sources/ich9gen --macaddress aa:bb:cc:dd:ee:ff You selected to change the MAC address in the Gbe section. This has been done. The modified gbe region has also been dumped as src files: mkgbe.c, mkgbe.h To use these in ich9gen, place them in src/ich9gen/ and re-build ich9gen. descriptor and gbe successfully written to the file: ich9fdgbe_4m.bin Now do: dd if=ich9fdgbe_4m.bin of=libreboot.rom bs=1 count=12k conv=notrunc (in other words, add the modified descriptor+gbe to your ROM image) descriptor and gbe successfully written to the file: ich9fdgbe_8m.bin Now do: dd if=ich9fdgbe_8m.bin of=libreboot.rom bs=1 count=12k conv=notrunc (in other words, add the modified descriptor+gbe to your ROM image) descriptor and gbe successfully written to the file: ich9fdgbe_16m.bin Now do: dd if=ich9fdgbe_16m.bin of=libreboot.rom bs=1 count=12k conv=notrunc (in other words, add the modified descriptor+gbe to your ROM image) descriptor successfully written to the file: ich9fdnogbe_4m.bin Now do: dd if=ich9fdnogbe_4m.bin of=yourrom.rom bs=1 count=4k conv=notrunc (in other words, add the modified descriptor to your ROM image) descriptor successfully written to the file: ich9fdnogbe_8m.bin Now do: dd if=ich9fdnogbe_8m.bin of=yourrom.rom bs=1 count=4k conv=notrunc (in other words, add the modified descriptor to your ROM image) descriptor successfully written to the file: ich9fdnogbe_16m.bin Now do: dd if=ich9fdnogbe_16m.bin of=yourrom.rom bs=1 count=4k conv=notrunc (in other words, add the modified descriptor to your ROM image)
$ cd ~/libreboot_r20160907_grub_x200_8mb/ $ cp -v x200_8mb_usqwerty_vesafb{,_customised}.rom 'x200_8mb_usqwerty_vesafb.rom' -> 'x200_8mb_usqwerty_vesafb_customised.rom' $ dd if=ich9fdgbe_8m.bin of=x200_8mb_usqwerty_vesafb_customised.rom bs=1 count=12k conv=notrunc 12288+0 records in 12288+0 records out 12288 bytes (12 kB, 12 KiB) copied, 0,0299453 s, 410 kB/s $
flashrom -p ch341a_spi -c MX25L6405D -r rom1.bin flashrom -p ch341a_spi -c MX25L6405D -r rom2.bin flashrom -p ch341a_spi -c MX25L6405D -r rom3.bin flashrom -p ch341a_spi -c MX25L6405D -r rom4.bin flashrom -p ch341a_spi -c MX25L6405D -r rom5.bin cmp rom{1,2}.bin cmp rom{1,3}.bin cmp rom{1,4}.bin cmp rom{1,5}.bin
flashrom -p ch341a_spi -c MX25L6405D -r rom1.bin
flashrom -p ch341a_spi -c MX25L6405D -r rom2.bin
flashrom -p ch341a_spi -c MX25L6405D -r rom3.bin
flashrom -p ch341a_spi -c MX25L6405D -r rom4.bin
flashrom -p ch341a_spi -c MX25L6405D -r rom5.bin
cmp rom{1,2}.bin
cmp rom{1,3}.bin
cmp rom{1,4}.bin
cmp rom{1,5}.bin
$ sudo flashrom -p ch341a_spi -c MX25L6405D -w ~/libreboot_r20160907_grub_x200_8mb/x200_8mb_usqwerty_vesafb_customised.rom $
The support request replicated below was posted as ticket #20427 on Micro:bit support on 2019-01-31 22:19 CET spawned by discussion in F-Droid RFP #662 about inclusion of the official Micro:bit Android Companion application in the free software application store F-Droid.
Hi at Micro:bit Educational Foundation. We are wondering a bit in the F-Droid free software community (https://gitlab.com/fdroid/rfp/issues/662) whether it is worthwhile for us to try to loosen the official Android companion application (https://microbit.org/guide/mobile/#og-app) from its non-free dependencies to make it available in the free software application store F-Droid (https://f-droid.org/). This leads to a couple of questions you can hopefully help answering; 1) Do you regard the application as alive and supported? The latest release of the application was v2.0 2017-01-17 (https://play.google.com/store/apps/details?id=com.samsung.microbit) and the publicly available code base (https://github.com/Samsung/microbit/) seems to have been completely abandoned. Only two commits were ever made by Samsung and no involvement with the community has been seen at all. 2) How come the big difference in maturity between the iOS and Android mobile applications? It seems like the iOS application has received some more attention seeing regular updates through to v3.0.2 released 2018-11-01 (https://itunes.apple.com/gb/app/micro-bit/id1092687276?mt=8). Also it appears to have a much wider fetaureset (https://play.google.com/store/apps/details?id=com.samsung.microbit&reviewId=gp%3AAOqpTOGpgo4CF2qrry4qWqLXyj0TZaEEJcrTB-yZ61o4nJbqhq-2mBojlYQJP7BzdkAzseGaLD1sVO9fBv1R3sY) developed along the way by Insight Resources (http://www.insightresources.co.uk/microbit/index.html). The Android application appears to have been more of a one-off project from Samsung having all sorts of issues especially with Bluetooth that has never been attended to (http://www.suppertime.co.uk/blogmywiki/2016/04/mobile-microbit/, https://support.microbit.org/support/solutions/articles/19000041104-diagnosing-bluetooth-problems-android). 3) Is there a plan to bring the application in better shape? Some activity can be seen in repository forks and branches from the original Samsung committer ailrohit (https://github.com/Samsung/microbit/compare/master…ailrohit:school_project) and microbit-sam (https://github.com/Samsung/microbit/compare/master…microbit-sam:partial-flash) identifying as being from the foundation but none of this work seem to be included in releases yet. 4) If a freed fork is made for inclusion in F-Droid would you be willing and able to integrate the changes into the official sources? F-Droid prefers an upstream source which can be directly built without non-free dependencies using an appropriate set of build options. This greatly simplifies maintenance and build efforts. A forked repository is already in place at the foundation’s Github organization (https://github.com/microbit-foundation/microbit-android) but is at the moment even with the stale Samsung repository. Thanks for any clarifications you can provide. Regards, Mikkel
Hi at Micro:bit Educational Foundation.
We are wondering a bit in the F-Droid free software community (https://gitlab.com/fdroid/rfp/issues/662) whether it is worthwhile for us to try to loosen the official Android companion application (https://microbit.org/guide/mobile/#og-app) from its non-free dependencies to make it available in the free software application store F-Droid (https://f-droid.org/).
This leads to a couple of questions you can hopefully help answering;
1) Do you regard the application as alive and supported?
The latest release of the application was v2.0 2017-01-17 (https://play.google.com/store/apps/details?id=com.samsung.microbit) and the publicly available code base (https://github.com/Samsung/microbit/) seems to have been completely abandoned. Only two commits were ever made by Samsung and no involvement with the community has been seen at all.
2) How come the big difference in maturity between the iOS and Android mobile applications?
It seems like the iOS application has received some more attention seeing regular updates through to v3.0.2 released 2018-11-01 (https://itunes.apple.com/gb/app/micro-bit/id1092687276?mt=8). Also it appears to have a much wider fetaureset (https://play.google.com/store/apps/details?id=com.samsung.microbit&reviewId=gp%3AAOqpTOGpgo4CF2qrry4qWqLXyj0TZaEEJcrTB-yZ61o4nJbqhq-2mBojlYQJP7BzdkAzseGaLD1sVO9fBv1R3sY) developed along the way by Insight Resources (http://www.insightresources.co.uk/microbit/index.html).
The Android application appears to have been more of a one-off project from Samsung having all sorts of issues especially with Bluetooth that has never been attended to (http://www.suppertime.co.uk/blogmywiki/2016/04/mobile-microbit/, https://support.microbit.org/support/solutions/articles/19000041104-diagnosing-bluetooth-problems-android).
3) Is there a plan to bring the application in better shape?
Some activity can be seen in repository forks and branches from the original Samsung committer ailrohit (https://github.com/Samsung/microbit/compare/master…ailrohit:school_project) and microbit-sam (https://github.com/Samsung/microbit/compare/master…microbit-sam:partial-flash) identifying as being from the foundation but none of this work seem to be included in releases yet.
4) If a freed fork is made for inclusion in F-Droid would you be willing and able to integrate the changes into the official sources?
F-Droid prefers an upstream source which can be directly built without non-free dependencies using an appropriate set of build options. This greatly simplifies maintenance and build efforts. A forked repository is already in place at the foundation’s Github organization (https://github.com/microbit-foundation/microbit-android) but is at the moment even with the stale Samsung repository.
Thanks for any clarifications you can provide.
Regards, Mikkel
Thanks to the fine people at the libimobiledevice project, who bothers to reverse engineer Apple products, I recently succeeded in resurrecting a relative’s iPad stuck in a boot loop (something with jailbreaking, running Sydia, missing an iOS update and attempted Sydia removal) without any use of proprietary tools.
This is a brief recipe of the procedure done using Ubuntu 16.04.
As the required tool from libimobiledevice, idevicerestore, is not packaged in the Ubuntu libimobiledevice package we need to build this from scratch from the sources.
iPad in recovery mode during firmware download using libimobiledevice
sudo apt install libusbmuxd-dev libplist-dev libplist++contents under-dev libzip-dev
cd git clone https://git.libimobiledevice.org/libimobiledevice.git cd libimobiledevice/ ./autogen.sh make
cd git clone https://git.libimobiledevice.org/libirecovery.git cd libirecovery ./autogen.sh make
cd git clone https://git.libimobiledevice.org/idevicerestore.git cd idevicerestore CFLAGS="-I$HOME/libirecovery/include -I$HOME/libimobiledevice/include" LDFLAGS="-L$HOME/libirecovery/src/.libs \ -L$HOME/libimobiledevice/src/.libs" PKG_CONFIG_PATH=~/libirecovery:~/libimobiledevice/src ./autogen.sh make
sudo $HOME/idevicerestore/src/idevicerestore --latest NOTE: using cached version data Found device in Recovery mode Identified device as j71ap, iPad4,1 Latest firmware is iPad_64bit_11.2_15C114_Restore.ipsw Verifying 'iPad_64bit_11.2_15C114_Restore.ipsw'... Checksum matches. Extracting BuildManifest from IPSW Product Version: 11.2 Product Build: 15C114 Major: 15 INFO: device serial number is DMPM4V3SFK15 Device supports Image4: true Variant: Customer Upgrade Install (IPSW) This restore will update your device without losing data. Using cached filesystem from 'iPad_64bit_11.2_15C114_Restore/058-86080-124.dmg' Found ECID 6653578882512 Getting ApNonce in recovery mode... 03 6b cc ac 57 8a b4 29 29 c1 a9 fe e4 97 54 3b a8 36 59 5a Trying to fetch new SHSH blob Getting SepNonce in recovery mode... df 5c ad 67 48 bd 38 b4 6f 72 0a 5c b0 81 87 c3 95 37 4a da WARNING: Unable to find BbChipID node WARNING: Unable to find BbSkeyId node Request URL set to https://gs.apple.com/TSS/controller?action=2 Sending TSS request attempt 1... response successfully received Received SHSH blobs Extracting iBEC.ipad4.RELEASE.im4p... Personalizing IMG4 component iBEC... Sending iBEC (710360 bytes)... Recovery Mode Environment: iBoot build-version=iBoot-4076.30.43 iBoot build-style=RELEASE Sending AppleLogo... Extracting applelogo@2x~ipad.im4p... Personalizing IMG4 component AppleLogo... Sending AppleLogo (22709 bytes)... ramdisk-size=0x10000000 Extracting 058-85997-124.dmg... Personalizing IMG4 component RestoreRamDisk... Sending RestoreRamDisk (59978774 bytes)... Extracting DeviceTree.j71ap.im4p... Personalizing IMG4 component RestoreDeviceTree... Sending RestoreDeviceTree (101420 bytes)... Extracting kernelcache.release.ipad4... Personalizing IMG4 component RestoreKernelCache... Sending RestoreKernelCache (13226783 bytes)... About to restore device... Waiting for device... Device 3fb0f5cc97b83c61c85d4b8333796d9e536a4c83 is now connected in restore mode... Connecting now... Connected to com.apple.mobile.restored, version 15 Device 3fb0f5cc97b83c61c85d4b8333796d9e536a4c83 has successfully entered restore mode Hardware Information: BoardID: 16 ChipID: 35168 UniqueChipID: 6653578882512 ProductionMode: true Starting FDR listener thread About to send NORData... Found firmware path Firmware/all_flash Getting firmware manifest from build identity Extracting LLB.ipad4.RELEASE.im4p... Personalizing IMG4 component LLB... Extracting applelogo@2x~ipad.im4p... Personalizing IMG4 component AppleLogo... Extracting batterycharging0@2x~ipad.im4p... Personalizing IMG4 component BatteryCharging0... Extracting batterycharging1@2x~ipad.im4p... Personalizing IMG4 component BatteryCharging1... Extracting batteryfull@2x~ipad.im4p... Personalizing IMG4 component BatteryFull... Extracting batterylow0@2x~ipad.im4p... Personalizing IMG4 component BatteryLow0... Extracting batterylow1@2x~ipad.im4p... Personalizing IMG4 component BatteryLow1... Extracting glyphplugin@2x~ipad-lightning.im4p... Personalizing IMG4 component BatteryPlugin... Extracting DeviceTree.j71ap.im4p... Personalizing IMG4 component DeviceTree... Extracting recoverymode@2x~ipad-lightning.im4p... Personalizing IMG4 component RecoveryMode... Extracting iBoot.ipad4.RELEASE.im4p... Personalizing IMG4 component iBoot... Extracting sep-firmware.j71.RELEASE.im4p... Personalizing IMG4 component RestoreSEP... Extracting sep-firmware.j71.RELEASE.im4p... Personalizing IMG4 component SEP... Sending NORData now... Done sending NORData About to send RootTicket... Sending RootTicket now... Done sending RootTicket Waiting for NAND (28) Checking filesystems (15) Checking filesystems (15) Unmounting filesystems (29) Unmounting filesystems (29) Creating filesystem (12) About to send filesystem... Connected to ASR Validating the filesystem Filesystem validated Sending filesystem now... [==================================================] 100.0% Done sending filesystem Verifying restore (14) [==================================================] 100.0% Checking filesystems (15) Checking filesystems (15) Mounting filesystems (16) Mounting filesystems (16) About to send KernelCache... Extracting kernelcache.release.ipad4... Personalizing IMG4 component KernelCache... Sending KernelCache now... Done sending KernelCache Installing kernelcache (27) About to send DeviceTree... Extracting DeviceTree.j71ap.im4p... Personalizing IMG4 component DeviceTree... Sending DeviceTree now... Done sending DeviceTree Certifying Savage (61) Flashing firmware (18) [==================================================] 100.0% Updating gas gauge software (47) Updating gas gauge software (47) Updating Stockholm (55) About to send FUD data... Sending FUD data now... Done sending FUD data About to send FUD data... Sending FUD data now... Done sending FUD data Fixing up /var (17) Modifying persistent boot-args (25) Unmounting filesystems (29) Unmounting filesystems (29) Got status message Status: Restore Finished Cleaning up... DONE
iPad during firmware flashing using libimobiledevice
If you want to interact with iDevices from within Ubuntu during ordinary use, you could also install some utils and plugins for that. Below will fx. add a context menu in nautilus with info about the iDevice and install the ideviceinstaller command line utility which can be used to administer installed applications on the device.
sudo apt install libimobiledevice-utils nautilus-ideviceinfo ideviceinstaller
Redigeret 2018-08-03: rettet døde links
Min kommentar til LoRa og LoRaWANs åbenhed i forbindelse med artikel i Version2 med overskriften “TDC holder fast i proprietær IoT-standard – andre kører billig open source”, som nok mest minder om et bidrag til “open washing” af LoRa/LoRaWAN-teknologien. Se mere om open washing i denne blogpost fra Open Knowledge Foundation Denmark (Engelsk udgave).
Det er noget misvisende at snakke om at LoRa eller LoRaWAN er “open source”. Man er i hvert fald nødt til at skelne hårdt mellem LoRa og LoRaWAN.
LoRa specificerer radiomodulationen i luften, og det er en proprietær teknologi udviklet af virksomheden Semtech, som både har varemærkebeskyttet og patenteret den (EPO-patent);
LoRa is a proprietary spread spectrum modulation scheme that is derivative of Chirp Spread Spectrum modulation (CSS)
Kilde: Semtech AN1200.22, LoRa(TM) Modulation Basics (https://www.semtech.com/uploads/documents/an1200.22.pdf, afsnit 1)
LoRaWAN er en åben protokol der anvender LoRa som transmissionsmedie, men som yderligere definerer hvordan flere enheder der alle kan snakke LoRa kan fungere sammen i et netværk. Den specificeres af et samarbejde mellem mange interessenter i LoRa Alliance, herunder også Semtech.
Q: What is LoRaWAN(TM)? A: The LoRa modulation is the pshysical layer (PHY), and LoRaWAN is a MAC protocol for a high capacity, long range star network that the LoRa Alliance is standardizing for Low Power WideArea Networks (LPWAN).
Kilde: Semtech LoRa® FAQ (http://www.semtech.com/wireless-rf/lora/LoRa-FAQs.pdf, spgm. 3)
En mere teknisk beskrivelse kan findes her; https://www.lora-alliance.org/What-Is-LoRa/Technology (from). LoRaWAN-specifikationen selv er næsten frit tilgængelig, det er kun folk med offentlige email-adresser der ikke må få den (dette er senere ændret, pr. 2018-08-03 er den frit tilgængelig).
For mig ser det dog ud som om Semtech og LoRa Alliance helt bevidst mudrer sondringen mellem LoRa og LoRaWAN, og synes det lugter af at det udelukkende er Semtech der kan og må producere silicium der implementerer LoRa. Selvom jeg ikke har kunnet finde steder det bliver sagt helt eksplicit.
Microchip og andre har produkter der snakker LoRa, men Semtech ser ud til altid at være med inde over, så jeg vil tro det stadig er en chip fra deres fabrik der ligger til grund for LoRa-funktionaliteten.
Der er dog folk der har kigget i sprækkerne på LoRa;
Spændende hvad der sker på dette felt. En mere fri og uafhængig infrastruktur i åbne licensbånd skal da være så velkommen.
Mikkel
Mit svar på et spørgsmål i Facebook-gruppen Danske Arduino Entusiaster omkring Arduino ROM/Flash, PROGMEM og system-inklude-filer.
Spørgsmål
Hej er der en der ved hvor jeg kan hente dett lib. <avr/pgmspace.h> jeg skal bruge denne funktion PROGMEM så jeg kan gemme et billede i Arduino uden SD kort det kan være der er en der kender en anden måde at gøre det på.
Svar
pgmspace.h er en inklude-fil som er en del af c-biblioteket til AVR-arkitekturen (avr-libc). C-bibliotekets inklude-filer vil normalt ligge i kompilerens “system include”-sti (se GCC options -I og -isystem). Dermed kan den inkluderes blot med “#include <avr/pgmspace.h>”. Se evt. også Arduino-referencen på https://www.arduino.cc/en/Reference/PROGMEM. Bemærk at PROGMEM ikke er en funktion, men en storage modifier (lager-modifikator) som fortæller kompileren at den kan placere en en given variabel i ikke-skrivbar lager (ROM/Flash). Der skal efterfølgende anvendes specielle funktioner til at læse data fra en sådan variabel (se referencen). Arduino-frameworket har dog lavet en nem måde at placere konstant-strenge i Flash på (normalt lagres de i SRAM!), nemlig funktionen F() som kan anvendes direkte i f.eks. printf/write/print (Serial.print(F(“Waiting for connection”));) Hvis du vil inspicere indholdet af pgmspace.h, kan du finde filen i Arduino IDE’ets installations-mappe under hardware/tools/avr/avr/include/avr/pgmspace.h. Det er ikke en man kan/skal redigere manuelt i, da den er tæt koblet med den binære kode i selve biblioteket. Der findes også EEPROM-lager du sikkert vil kunne bruge til samme formål; https://www.arduino.cc/en/Reference/EEPROM
Se svaret på Facebook.
Den videre færd med F()
Da jeg ikke kunne finde en uddybende forklaring på F()-funktionen (som egentlig er en makro) i Arduino-dokumentationen (brugen nævnes meget kort i PROGMEM , Memory og Print), gravede jeg efterfølgende lidt rundt for at lære mere. I de sparsomme Arduino-eksempler er den anvendt udelukkende med konstante strenge, hvilket også viser sig at være et krav (eller i hvert fald noget der kan castes til const char *).
Makroen er defineret af Arduino-frameworket i filen hardware/arduino/avr/cores/arduino/WString.h (referencerne er ifht. min lokale installation af Arduino 1.6.9, pt. er nyeste 1.6.13) således:
#define F(string_literal) (reinterpret_cast<const __FlashStringHelper *>(PSTR(string_literal)))
Altså parametren til F() bruges som parameter til PSTR() (progmem string, er mit bud på navn) som er en makro defineret i pgmspace.h fra avr-libc.
Dens funktion er at caste parametrens type til konstant streng-pointer med PROGMEM modifier;
#define PSTR(s) ((const PROGMEM char *)(s))
Skal vi se på hvad PROGMEM rent faktisk er, så finder vi endnu et sæt makroer der ender med at blive udviddet til kompiler-attributten __progmem__, igen definieret i pgmspace.h (hardware/tools/avr/avr/include/avr/pgmspace.h):
#define PROGMEM __ATTR_PROGMEM__ #define __ATTR_PROGMEM__ __attribute__((__progmem__))
#define PROGMEM __ATTR_PROGMEM__
#define __ATTR_PROGMEM__ __attribute__((__progmem__))
__progmem__ attributten er en instruks til kompileren (GCC) og linkeren om ved programmering/flashing af programmet at placere disse data i en sektion af hukommelsen der hedder “.progmem“. Se evt. mere om dette i GCC-kompilerens dokumentation. For hver AVR-chip kompileren understøtter er der eksakte definitioner af hvilke hukommelsesadresser .progmem ligger på for netop denne chip.
Dvs. når man i sin kode skriver F(“test”) får man i virkeligheden:
(reinterpret_cast<const __FlashStringHelper *>(((const __attribute__((__progmem__)) char *)(“test”)))
Altså en konstant streng der lagres i AVR-processorens progmem-sektion, og som returværdi får en pointer til en konstant instans af en klasse kaldet “__FlashStringHelper“. Denne klasse må være lavet sådan at den anvender de korrekte mekanismer til at læse fra progmem-området (måske mere om dette i en senere artikel). Arduinos funktion-bibliotek (Serial.print() mm.) er lavet således at de direkte kan tage en parameter af denne type som erstatning for en konstant-streng (og det er netop her Arduino-frameworket viser sin værdi ved at abstrahere sådanne kompleksiteter væk fra programmøren).
Stumbled across a very cheap RGB LED strip where I live in Denmark from the brand Frostlight. Priced at down to DKK 50 ~ EUR 6.5 ~ USD 7.5 in Fleggaard at Danish/German border but goes for around DKK 200 ~ EUR 26 ~ USD 30 in the ordinary DIY and internet shops (still cheap compared to other sources). For this amount you get a product which on the packaging is called “3 meter farvede LED bånd (RGB)” (which is a little gibberish Danish and not grammatically correct), English: “3 meter colored LED strip (RGB)”, containing these components;
According to the description this setup “does it all”; RGB multi color LEDS, controller doing colour change, fading etc.
The big question for me as a maker/hacker/tinkerer was; Does it use individually addressable LEDs?
And no, it doesn’t;
Obviously (as could be expected from the price), this strip is made from plain RGB LEDs with discrete R, G & B LEDS in a common anode setup (12V pin is common, current needs to be sinked from each RGB to control colour and intensity).
The brand Frostlight is unknown to me (they have a very non-informative website without any real product information), but they seem to supply LED products to many discount supermarkets in Denmark. They have a youtube channel (which is not even mentioned on the homepage) containing some product information. Even one for the “Frostlight LED farve-bånd”.
I was looking for a quick and cheap way to source LEDs for the awesome WordClock project by grahamvinyl (Arduino source code at github.com/grahamvinyl/WordClock_color_edit). However, it won’t work as all LEDs on the strip will light up in the same colour, but I consider using it for a cheaper tweak of it.
At least I’m confident I’ll find something to use the strip for anyway.
Having used the Arduino prototyping platform (a loose combination of specific pieces of somewhat open/free hardware and a more open/free software stack) for some time for educational and tinkering purposes in my local hackerspace (geeklabs.dk) I have seen and studied the Arduino UNO hardware and lots of its “clones/compatibles/knockoffs” and their common MCU (MicroController Unit);
Atmel ATmega328P
I had begun wondering what the P in the microcontroller model name actually meant. So here is an attempt to decode the Atmel megaAVR chip numbering system. The other existing AVR based series UC3, tinyAVR, XMEGA, Battery & Automotive, will probably employ similar naming schemes.
The remainder of the product name following “ATmega” expresses the available flash memory and the approximate pin count of the package in an integer and optionally other features as either integer or letter (like the initial wondering of P in 328P above).
Starting with the integer, it is a concatenation of two separate integers encoding the flash size and pin count as defined below. The division of the two is non-ambiguous leaving some interpretation to be done.
1st integer: onboard flash size 8 = 4 KiB 8 = 8 KiB 16 = 16 KiB 32 = 32 KiB 64 = 64 KiB 128 = 128 KiB 256 = 256 KiB
2nd integer: total pin number (none) = standard pin count (differs) 8=28/32-pin 4= 40/44/49-pin 5= 64-pin 0= 100-pin
Suffix (char or integer), multiple possible P = picoPower (max. consumption 9mA@8MHz,5v vs. 12mA@8Mhz,5v for non-P) 9=LCD controller U2 = USB controller U4 = USB controller A = ?
Exceptions Note that some of the product names are completely void of these rules. Others employ different numbering but still with a familiarity to the above.
An example: ATmega6490A: 64KB flash, 100-pin, LCD Controller
Sources
Patch for u-boot mainline master (http://git.denx.de/u-boot.git) to prevent BBB’s to get stuck in a u-boot prompt because of spurious characters being received on the serial console (see http://www.mikini.dk/index.php/category/beaglebone-black/boot-issue).
diff –git a/include/configs/ti_am335x_common.h b/include/configs/ti_am335x_common.h index 5ed86d9..c58f467 100644 — a/include/configs/ti_am335x_common.h +++ b/include/configs/ti_am335x_common.h @@ -12,6 +12,12 @@ #ifndef __CONFIG_TI_AM335X_COMMON_H__ #define __CONFIG_TI_AM335X_COMMON_H__ +#define CONFIG_AUTOBOOT_KEYED +#define CONFIG_AUTOBOOT_STOP_STR “stop” +#define CONFIG_AUTOBOOT_PROMPT “autoboot in %d seconds (type ‘%s’ to abort)\n”,bootdelay,CONFIG_AUTOBOOT_STOP_STR +#define CONFIG_BOOT_RETRY_TIME 30 +#define CONFIG_RESET_TO_RETRY + #define CONFIG_AM33XX #define CONFIG_ARCH_CPU_INIT #define CONFIG_SYS_CACHELINE_SIZE 64 @@ -102,4 +108,7 @@ /* Now bring in the rest of the common code. */ #include <configs/ti_armv7_common.h> +#undef CONFIG_BOOTDELAY +#define CONFIG_BOOTDELAY 5 + #endif /* __CONFIG_TI_AM335X_COMMON_H__ */
diff –git a/include/configs/ti_am335x_common.h b/include/configs/ti_am335x_common.h index 5ed86d9..c58f467 100644 — a/include/configs/ti_am335x_common.h +++ b/include/configs/ti_am335x_common.h @@ -12,6 +12,12 @@ #ifndef __CONFIG_TI_AM335X_COMMON_H__ #define __CONFIG_TI_AM335X_COMMON_H__
+#define CONFIG_AUTOBOOT_KEYED +#define CONFIG_AUTOBOOT_STOP_STR “stop” +#define CONFIG_AUTOBOOT_PROMPT “autoboot in %d seconds (type ‘%s’ to abort)\n”,bootdelay,CONFIG_AUTOBOOT_STOP_STR +#define CONFIG_BOOT_RETRY_TIME 30 +#define CONFIG_RESET_TO_RETRY + #define CONFIG_AM33XX #define CONFIG_ARCH_CPU_INIT #define CONFIG_SYS_CACHELINE_SIZE 64 @@ -102,4 +108,7 @@ /* Now bring in the rest of the common code. */ #include <configs/ti_armv7_common.h>
+#undef CONFIG_BOOTDELAY +#define CONFIG_BOOTDELAY 5 + #endif /* __CONFIG_TI_AM335X_COMMON_H__ */
Patch and compiled binaries at http://www.mikini.dk/wp-content/uploads/2015/01/u-boot_mainline_BBB-autoboot-patch_201501151.zip.
Install the new u-boot by copying the files “MLO” and “u-boot.img” to the root directory of your boot device (first FAT-partition on your SD-card or onboard MMC). Using the stock Debian image (http://beagleboard.org/latest-images) this can be done via USB by powering the board from your computers USB-interface, waiting for the BBB to boot and register its drive as an usb mass-storage in your OS. Now use your favorite file management application to copy the files from the above zip-file replacing the existing files.
Disclaimer: this is mostly an experiment, there is a lot of u-boot trees and patches floating around for the BBB (like https://github.com/beagleboard/u-boot), so probably mainline hasn’t got the most recent stuff for AM335x/BBB yet.
