ECC check for Erased pages in NAND - linux-kernel

I wanted to verify the following patch
https://patchwork.kernel.org/patch/8368341/
For same , wrote all zero's to one of nand partition :
nandwrite -n /dev/mdt1 < /dev/zero
But now when I dump this nand partition, see following errors:
ECC: 3 uncorrectable bitflip(s) at offset 0x00000000
ECC: 2 uncorrectable bitflip(s) at offset 0x00000800
ECC: 2 uncorrectable bitflip(s) at offset 0x00001000
I thought above mentioned patch , suppose to fix this ECC errors but
it didn't.
Is they other way to verify this patch ?

Related

Error while unmounting mmcblk1p1 on beaglebone black - during repartitioning and formatting

Hi I'm a newbie of embeded linux. I'm following this tutorial (https://e2e.ti.com/support/embedded/linux/f/354/t/398780?Script-to-Erase-Emmc-independently-Beagle-Bone-Black) for flashing my linux system to beaglebone eMMC.
But I have an error: umount: can't umount /dev/mmcblk1p1: Invalid argument
This is my cmd :
Disk /dev/mmcblk1: 3825 MB, 3825205248 bytes
4 heads, 16 sectors/track, 116736 cylinders
Units = cylinders of 64 * 512 = 32768 bytes
Device Boot Start End Blocks Id System
/dev/mmcblk1p1 * 2048 2536 15648 e Win95 FAT16 (LBA)
/dev/mmcblk1p2 1 2047 65496 83 Linux
Partition table entries are not in disk order
Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table
[ 235.274729] mmcblk1: p1 p2
root#beaglebone:/# umount /dev/mmcblk1p1
umount: can't umount /dev/mmcblk1p1: Invalid argument
Sorry my English is not good. Does anybody have any idea of what did I do wrong or did I miss something?
This is an error in the script you are following. If you have created new partitions without a file system you would not expect them to be mounted.
Creating the 2nd partition in sectors 1 - 2047 is probably not what you want to do. You should use all the space after partition 1.

Allocating a larger u-boot image

I am compiling my own kernel and bootloader (U-boot). I added a bunch of new environmental variables, but U-boot doesn't load anymore (it just doesn't load anything from the memory). I am using pocketbeagle and booting from an SD card. Thus I am editing the file "am335x_evm.h" found in /include/configs/.
I am trying to allocate U-boot in a way that it has more space for the environmental variables and that it can load succesfully from the memory, but I have been unable to do so. As far as I understand, by default it allocates 128kb of memory to U-boot env variables. Since I added a bunch of them, I am trying to increase its size from 128kb to 512kb.
I have changed the following line (from 128kb to 512kb):
#define CONFIG_ENV_SIZE (512 << 10)
(By the way, anyone knows why it is shifted to the left 10 bits?)
I have also changed CONFIG_ENV_OFFSET and CONFIG_ENV_OFFSET_REDUND to:
#define CONFIG_ENV_OFFSET (1152 << 10) /* Originally 768 KiB in */
#define CONFIG_ENV_OFFSET_REDUND (1664 << 10) /* Originally 896 KiB in */
Then after compiling the new U-boot, I format the SD card and insert the new kernel and U-boot.
I start by erasing partitions:
export DISK=/dev/mmcblk0
sudo dd if=/dev/zero of=${DISK} bs=1M count=10
Then I transfer U-boot by doing:
sudo dd if=./u-boot/MLO of=${DISK} count=1 seek=1 bs=512k
sudo dd if=./u-boot/u-boot.img of=${DISK} count=2 seek=1 bs=576k
I then create the partition layout by doing:
sudo sfdisk ${DISK} <<-__EOF__
4M,,L,*
__EOF__
Then I add the kernel, binary trees, kernel modules, etc... When trying to boot and reading the serial port, I get nothing at all. U-boot is not able to load anything from the SD card. What am I doing wrong? I'd appreciate if you could point me what my problem is and exactly what I should be doing to increase the size and allocate everything correctly.

fw_printenv fw_setenv on var-som-am33 is failing

Depending on a few configurations I tried in /etc/fw_env.config such as one or two entries, I got the following errors when trying to read the U-boot environment variables:
root#varsomam33:~# fw_printenv serverip
Warning: Bad CRC, using default environment
or
root#varsomam33:~# fw_printenv serverip
Cannot read bad block mark: Invalid argument
According to this tutorial (https://developer.ridgerun.com/wiki/index.php/Setting_up_fw_printenv_to_modify_u-boot_environment_variables), I constructed my /etc/fw_env.config to look like this:
# MTD device name Device offset Env. size Flash sector size Number of sectors
/dev/mtd6 0x1C0000 0x20000 0x20000 1
/dev/mtd7 0x1E0000 0x20000 0x20000 1
FYI I'm using a TI Omap ARM chip (var-som-am33) with Yocto Fido default out-of-box from Variscite with these software versions:
U-boot version: u-boot-var-som-am33 2014-+gitrAUTOINC+adf9a14020
U-boot-fw-utils version: u-boot-fw-utils v2014.07+gitAUTOINC+524123a707-r0-arago0-var
The main problem is that "Device offset" is incorrectly described in the RidgeRun tutorial. It is not the absolute offset in NAND flash, but rather the offset from the partition which should be "0x0" in my case.
Here is my working /etc/fw_env.config
root#varsomam33:~# cat /etc/fw_env.config
# MTD device name Device offset Env. size Flash sector size Number of sectors
/dev/mtd6 0x0 0x20000 0x20000 1
/dev/mtd7 0x0 0x20000 0x20000 1
Further, the CRC error I was getting is thrown when there is not a U-boot backup (redundant) environment described in the /etc/fw_env.config file. The fw_printenv utility works by copying the "selected" environment, modifying the variable you have changed, and writing it out to the "new" environment. Then it swaps "selected" and "new".
So if you only have one environment in /etc/fw_env.config, it uses default values for the "selected" environment.
Here is the code tools/env/fw_env.c
1230 crc0_ok = (crc0 == *environment.crc);
1231 if (!HaveRedundEnv) {
1232 if (!crc0_ok) {
1233 fprintf (stderr,
1234 "Warning: Bad CRC, using default environment\n");
1235 memcpy(environment.data, default_environment, sizeof default_environment);

Floppy disk sector count

I am trying to understand why lseek() is used in this image creator. Why 5 bytes away from start of file? If I changed that number, the OS won't boot.
The image creator creates a .img file with the bootloader.bin inside.
/* modify the sector count */
total_sector_number = file_size / 512
lseek(disk_image_fd, 5, SEEK_SET);
write(disk_image_fd, &total_sector_number, 2);
write(disk_image_fd, &kernel_32_sector_number, 2);
//printf("%d\n", lawl);
printf("TOTAL_SECTOR_NUMBER : %d\n", total_sector_number);
printf("KERNEL_32_SECTOR_NUMBER : %d\n", kernel_32_sector_number);
The source code (image maker):
http://pastebin.com/raw.php?i=MuDpYP3Y
Bootloader:
http://pastebin.com/raw.php?i=kzw2ZaU1
The hexdump with lseek() and writing umber of sectors to byte at offset 5:
Without lseek() OS does not boot correctly.
I only figured this out because of your previous post Bootloader memory location which contained different source code for the bootloader.
You mentioned the two unknown variables TOTALSECTORCOUNT and KERNEL32SECTORCOUNT. These variables were near the beginning of the file, and I guess when assembled they sit 5 bytes into the binary. Calling lseek with the SEEK_SET parameter moves the file pointer to 5 bytes after the beginning of the file. It then writes the two values which will overwrite the ones in the bootloader code.
When you remove the lseek it will instead append the two values to the end of the file. If you changed the offset parameter of lseek to zero it would overwrite the jmp command of the bootloader instead.
Notice in your hexdump.
00000000 00eb b8fa 02c0 0000 c000 e08e e88e 00b8
^ ^- kernel_32_sector_number is never initialized.
|-total_sector_number which was calculated in code before the write.

atmega8 program size limit?

I am new to atmega8. I convert some old freesacle code into atmega8. but seems my chip can not hold code more than 2400 bytes? below is result, when code is 2412 bytes... all things become mess.
code below avrdude is comes from "cat /dev/ttyUSB0". my debug informations.
avrdude: verifying ...
avrdude: 2412 bytes of flash verified
avrdude: safemode: Fuses OK
avrdude done. Thank you.
55432111001-0000 6Gn�H(�h�X0443234554321190 6Gn�H (�h�X0443234554321100-FD-90-6F55432111001-0000 6Gn�H (�h�X0443234554321190 6Gn�H(�h�X0443234554321100-FD-90-6F^C
but if i reduced code(only audio data), i got right result.
avrdude: verifying ...
avrdude: 2312 bytes of flash verified
avrdude: safemode: Fuses OK
avrdude done. Thank you.
AVR-IrDA-Tone-Audio start.
version 1.2
--IrDA-- Bin: 1001-0000 Hex: 90 Complete Hex: 00-FD-90-6F
all hfuse, lfuse, lock bits are original value. my code might be 6k with some audio data.
if it is due to boot flash section?
Addtion: --------------------------------------------------------------------------------------------------
I change crystal to 8M now.
● ll h8-*
-rw-rw-r-- 1 eexp eexp 933 9月 22 00:27 h8-reduce.c
-rw-rw-r-- 1 eexp eexp 14K 9月 22 00:26 h8-org.c
● cp h8-org.c h8.c
● avr.sh main.c
......
avrdude: 5272 bytes of flash verified
now all goes mess.
● cp h8-reduce.c h8.c
● avr.sh main.c
.....
avrdude: 1872 bytes of flash verified
now all goes right, but i lost almost all audio data.
below is h8.c.
● head h8.c
const unsigned char h8[] =
{
36,14,0,0,129,129,128,129,130,127,126,128,128,127,128,130,131,128,127,127,127,126,127,129,130,130,129,129,128,128,128,128,128,126,126,129,128,127,127,130,133,130,126,126,129,128,125,127,128,129,128,127,129,128,127,127,127,128,128,129,127,127,129,128,130,130,128,128,127,126,128,128,128,130,129,128,129,126,126,125,127,132,130,127,126,129,131,127,127,133,133,127,122,125,129,130,127,127,130,129,
126,125,127,128,129,128,128,128,128,127,127,129,128,129,129,128,126,127,129,127,128,127,128,130,129,129,128,128,127,127,129,130,128,128,129,129,127,127,128,128,128,128,128,128,126,126,129,129,127,129,130,130,126,126,128,128,127,128,131,130,127,126,126,128,129,125,128,130,131,128,126,129,128,129,125,126,130,129,131,130,131,129,125,128,129,131,130,127,130,129,127,128,127,129,128,126,126,127,128,126,
127,127,128,128,128,127,127,127,127,127,129,128,129,128,128,129,129,128,128,129,128,128,128,129,0xff,
};
i guess you are loading the audio data into the ram. a variable declaration like
char* data = "somerandomdata";
is putting all the data in the SRAM, and you just have 1kbyte of SRAM in the mega8 (which also contains the stack etc).
if the lock bits are in their original state, the bootloader mechanism should not cause this error.
you should specify the audio data as program space, here is the description how:
Avr LibC PGM Space
here is how your code should look like:
h4.c
#include <avr/pgmspace.h>
const unsigned char h4[] PROGMEM = { 18,7,0,0,128,128,128,127,127,129,129,127,126,128,130,129,128,129,127,127,128,12‌​8,132,127,129,126,128,128,127,127,127,129,127,127,130,129,127,127,129,130,129,125‌​,
you need to adjust your set_audio function,
every reading of the pointer h4 shall be done in this way:
change for example
value = *h4_copy++;
to
value = pgm_read_byte(h4_copy); h4_copy++;

Resources