After setting the hardware RTC with the command:
# hwclock -w
after just few minutes the RTC already lost seconds with the command:
# hwclock -r
This problem is due to an error in the AT91Bootstrap configuration. We missing to set this flag during the make menuconfig setup (see Compile AT91Bootstrap).
The right configuration is this:
Slow Clock Configuration Options --->
[*] Use external 32KHZ oscillator as source of slow clock
[ ] Use external 32kHz clock as source of slow clock
You can re-compile the AT91Bootstrap following this article:
or simply change boot.bin in the first partition of microSD with
the binaries file available on the same page
The serial RX line (PA9/DRXD) is set by Linux without the pull-up internal resistor. This could cause a lot of receiving interrupts from the debug serial port in noisy environments.
Change these lines in arch/arm/boot/dts/at91sam9x5dtsi:
Original
/* shared pinctrl settings */
dbgu {
pinctrl_dbgu: dbgu-0 {
atmel,pins =
<AT91_PIOA 9 AT91_PERIPH_A AT91_PINCTRL_NONE /* PA9 periph A */
AT91_PIOA 10 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>; /* PA10 periph A with pullup */
};
};
Changed
/* shared pinctrl settings */
dbgu {
pinctrl_dbgu: dbgu-0 {
atmel,pins =
<AT91_PIOA 9 AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PA9 periph A with pullup*/
AT91_PIOA 10 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>; /* PA10 periph A with pullup */
};
};
then compile the dts following this article:
The serial port /dev/ttyS1 (used on the Terra-M to link the GPRS modem) doesn't work using the A4 microSD with Kernel 3.11.6:
Download and save the at91-ariag25.dtb file in the first microSD partition and reboot. This error is due to a wrong device tree used on the first microSD with Kernel 3.11. Here is the right definition: at91-ariag25.dts
Sometimes with the DPI port interface plugged happen that a power cycle is not able to restart the board.
The problem is that the FTDI chip TX line is kept at 3.3V when the board is switched off.
This voltage enters the CPU through the Rx line and latches up the 3V3 power line in the CPU at over 2 Volts, preventing the CPU to correctly boot when powered up again.
To avoid this problem you can insert a series resistor on the TX line of the DPI FTDI chip. In this way the voltage loss on the series resistor is enough to prevent the latch up problem.
Cut the PCB track on the DPI board as shown here:
Then you have to put the series resistor of 47k between the two pads marked TX (shown a 56k resistor working equally well):
For a cleaner work you can use a SMD resistor like this:
The series resistor of course is slowing down the signal speed but at 115200 bit/s this is not much a problem. In the following photo you can see the signal in blue before the resistor and in green after the resistor. Even if the slew rate is lowered the signal integrity is maintained enough for correct working of the serial port.
Memory swap command causes this error:
debarm:/etc# swapon /dev/mmcblk0p4 swapon: /dev/mmcblk0p4: swapon failed: Function not implemented
The Linux Kernel is not configured to support the memory swap.
Follow this article:
and enable the memory swap in:
General setup ---> [*] Support for paging of anonymous memory (swap)
Enable the swap partition on the microSD adding these lines in /etc/fstab
#Enable the swap memory /dev/mmcblk0p4 none swap sw 0 0
Create a Linux swap partition on microSD
"Everytime I try to power down my Arietta via shutdown -h now or halt it reboots immediately afer it shuts down. What is my mistake? Or has my board any defect? Or how to power ist down properly ?"
On the Arietta, the Shutdown line is connected on the power regulator enable so to be able to put Arietta in sleep if you use a battery for the RTC.
In order to shut down Arietta properly the right command is hence
# shutdown -h -H now
In this way the shutdown command will not lower the shutdown line and you can safely remove power when the board halts.
Without the -H the shutdown line will lower at the board halt bringing down the 3V3 voltage so you are doing a very hard reset only (useful some time).
The pin TXD (PA7/S16) on serial port /dev/ttyS3 doesn't work.
Change on arch/arm/boot/dts/acme-aria.dts this section:
spi0: spi@f0000000 { status = "okay"; cs-gpios = <&pioA 14 0>, <&pioA 7 0>, <0>, <0>; device@0 { compatible = "spidev"; // spi-max-frequency = <50000000>; // 50 MHz spi-max-frequency = <5000000>; // 5 MHz reg = <0>; }; device@1 { compatible = "spidev"; // spi-max-frequency = <50000000>; // 50 MHz spi-max-frequency = <5000000>; // 5 MHz reg = <1>; }; };
in:
spi0: spi@f0000000 { status = "okay"; cs-gpios = <&pioA 14 0>, <0>, <0>, <0>; device@0 { compatible = "spidev"; // spi-max-frequency = <50000000>; // 50 MHz spi-max-frequency = <5000000>; // 5 MHz reg = <0>; }; };
In this way the PA7 pin is used for the /dev/ttyS3 instead of CS od SPI0.
Sometime after a reboot command the FOX Board G20 hangs.
If you are using a self compiled kernel 2.6.38 uImage comment these two lines on arch/arm/mach-at91/at91sam9_alt_reset.S: and make again a uImage:
//str r2, [r0, #AT91_SDRAMC_TR] @ disable SDRAM access //str r3, [r0, #AT91_SDRAMC_LPR] @ power down SDRAM
If you are using an Acme factory default uImage download this uImage file:
Rename it in uImage and copy it on the first microSD FAT32 partition called "kernel".
You can change it remotely copying the uImage in the directory /media/mmc_p1:
$ scp uImage_reboot root@[fox IP number]:/media/mmc_p1/uImage
and rebooting the FOX.
Edit the file /etc/cron.weekly/apt-xapian-index end insert "exit 0" after the first line:
#!/bin/sh exit 0
When I launch apt-get update some errors appears:
root@netusg20:~# apt-get update Hit http://ftp.it.debian.org wheezy Release.gpg ... Ign http://www.emdebian.org wheezy-grip Release.gpg Ign http://www.emdebian.org wheezy-grip Release Err http://www.emdebian.org wheezy-grip/main Sources 404 Not Found Err http://www.emdebian.org wheezy-grip/main armel Packages 404 Not Found Ign http://www.emdebian.org wheezy-grip/main Translation-en W: Failed to fetch http://www.emdebian.org/grip/dists/wheezy-grip/main/source/Sources 404 Not Found W: Failed to fetch http://www.emdebian.org/grip/dists/wheezy-grip/main/binary-armel/Packages 404 Not Found E: Some index files failed to download. They have been ignored, or old ones used instead.
Delete the file saved in /etc/apt/sources.list.d
Delete the repository url in /etc/apt/sources.list and save this new urls:
deb http://emdebian.bytesatwork.ch/mirror/grip stable-grip main deb-src http://emdebian.bytesatwork.ch/mirror/grip stable-grip main
Type:
# apt-get update
Then install the package you need or upgrade by typing:
# apt-get upgrade
Probably your FOX Board G20 mount an AcmeBoot loader version 1.19 or older. Move to the new a version 1.20 or higher (Go to AcmeBoot page).
On the FOX board G20 the rootfs goes up in read-only mode
This is due to a bug on the atmel-mci.c Kernel 2.6.32.2 driver up to September 2010. Use the the latest kernel image available on binary snapshot to avoid this problem.
On the FOX board G20 u-boot can't find foxg20-script.bin
If you are still using the U-boot bootloader instead of AcmeBoot with a Debian microSD higher than R03 add foxg20-script.bin on the first FAT partition of your bootable microSD or move from U-boot to AcmeBoot.
The EmDebian project is closed and the repository is not available anymore (read more...).
To continue to use it on your Acme Systems boards delete this file on your microSD:
/etc/apt/sources.list.d/multistrap-emdebian.list
Then type:
# apt-get update
After that you can install or upgrade any package.
Sometimes the serial port losts incoming characters.
To solve this problem enable inside the Device Tree file DMA for the serial port you are using.
usart0: serial@f801c000 { pinctrl-0 = <&pinctrl_usart0 &pinctrl_usart0_rts &pinctrl_usart0_cts>; status = "okay"; atmel,use-dma-rx; atmel,use-dma-tx; dmas = <&dma0 2 0x3>, <&dma0 2 0x204>; dma-names = "tx", "rx"; };
usart1: serial@f8020000 { pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts &pinctrl_usart1_cts>; status = "okay"; atmel,use-dma-rx; atmel,use-dma-tx; dmas = <&dma0 2 0x5>, <&dma0 2 0x206>; dma-names = "tx", "rx"; };
usart2: serial@f8024000 { pinctrl-0 = <&pinctrl_usart2>; status = "okay"; atmel,use-dma-rx; atmel,use-dma-tx; dmas = <&dma0 2 0x7>, <&dma0 2 0x208>; dma-names = "tx", "rx"; };
To compile know how to compile the Device Tree follow the tutorial on the Kernel Compilation listed in the Tutorial Index.
This problem is due to the Vodafone Station that automatically redirects any requests on port 80 icoming from new MAC addresses.
To solve this problem open a browser on a PC wired on the same LAN and go to the following URL changing ff:ff:ff:ff:ff:ff with the MAC address of your Acme board:
Then click on the top-right X to close the page and confirm on the next page.
Now try again with apt-get command on your Acme board.
In /etc/network/interfaces change the line:
auto eth0
in:
allow-hotplug eth0
Then test the configuration by typing:
ifdown eth0 ifup eth0
Calibrating delay loop... message after some errors on the Aria G25 debug port.
The reason of is problem is well explained on this post and it can be caused intentionally typing
# hwclock -w
and removing the power supply before the command ends. The problem occours only if the RTC backup battery is present.
To solve it you have to replace the AriaBoot executable file (boot.bin) on the first partition if the bootable microSD card with one of these files:
Renaming one of it in boot.bin.
The changes on AriaBoot source file are available on GitHub.
We found an insidious DDR2 RAM memory problem on the very first AriaG25-256 modules made by Acme Systems
If your board already has the patch wire shown below the problem was already solved by us before shipment. After the very first modules we send just board with the problem fixed on the PCB.
If your board has not the patch wire it could be affected by a memory fault problem highlighted only using the memtester utility.
According to our test this issue does not affect the AriaG25-128 boards:
To highlight the problem install memtester on your AriaG25-256:
# apt-get install memtester
Then lauch:
# memtester 1M
If your board fails one or more benchmarks you need to place the patch wire to avoid them. The two points to wire are the follow:
On the next production batch planned for october we'll eliminate this patch wire fixing the PCB.