I have a fundamental doubt regarding NAND chip,
We are trying to bring up custom board based on DM365,
We are trying to boot from the NAND,
NAND used is from micron MT29F8G08ABABA. (1Giga bytes = 8 Gigabits)
Organization
– Page size x8: 4320 bytes (4096 + 224 bytes)
– Block size: 128 pages (512K +28 K bytes)
– Plane size: 2 planes x 1024 blocks per plane
– Device size: 8Gb: 2048 blocks
Now as per datasheet of MT29F8G08BABA i think block size is (512K+224)bytes.
But in u-boot terminologies they use Sector size for NAND device.
Because when i use command
nand info
from u-boot commandline,
I get nand size as follows
Device 0: NAND 1GiB 3,3V 8-bit, sector size 256 KiB
Is this sector size is block size(which is actually 512k as per datasheet) or Environment sector?
NAND read/Write is working fine from u-boot, There is no issue as such.
So i just want to understand these terminologies.
Now if this is environment sector size then is there any way to get block size information from U-boot ?
Can somebody please enlighten me on this ?
Thank you,
Regards,
Ankur
It seems eraseblock size is nothing but the sector size.
Check below link for more information.
Updated link to TI E2E forum question
Regards,
Ankur
Related
I've been trying to test my AHCI driver for my hobby OS on bare metal. Before that, I tested my driver in QEMU with the parameters:
qemu-system-i386 -boot d -cdrom elfboot.iso -machine q35 -m 2G -hda hda.img -serial stdio
The output is something like that:
...
PCI: 00:1F.2 [0106] (01): 8086:2922 Mass Storage Controller
...
AHCI: Initialize module...
...
AHCI: Found AHCI device with signature EB140101
AHCI: ahci2: sectors = 204, block size = 2048
DEV: Added block device ahci2
...
The PCI device is the AHCI controller which is used when starting QEMU with the above parameters. Now, I felt confident enough that the same setup would work on real hardware too, so I gave it a try. This is what was printed on the screen:
...
PCI: 00:17.0 [0106] (01): 8086:A102 Mass Storage Controller
...
AHCI: Initialize module...
...
AHCI: Found AHCI device with signature EB140101
AHCI: ahci1: sectors = 4068212736, block size = 0
DEV: Added block device ahci1
...
I also tested it on another machine, which doesn't have an AHCI controller, but a RAID controller which is running in AHCI mode.
On that machine, the output is basically the same as on the other bare metal setup:
...
PCI: 00:17.0 [0104] (00): 8086:282A Mass Storage Controller
...
AHCI: Initialize module...
...
AHCI: Found AHCI device with signature EB140101
AHCI: ahci1: sectors = 4068212736, block size = 0
DEV: Added block device ahci1
...
According to the SCSI specification, the value of 4068212736 (0xF27C0000) does not have a set meaning. Also, the block size is set to zero, which does not match with what I see on QEMU. Only the output shown in the QEMU console is correct. On both of my real machines the reported capacity is wrong, with the same values.
What am I supposed to do next? Is this a vendor-related issue? It seems that the read capacity (10) command is mandatory for all SCSI devices of that type, so in my inexperienced opinion, I don't think that is the problem here.
EDIT: I put an SCSI request sense after the read capacity (10) command since it was stated that request sense should be put after every SCSI command for stalling the device.
Now, the reported number of blocks is 65263, which is still wrong, but also different from 4068212736, so I'm not sure If I move in the correct direction now. Also, the block size is now correctly reported as 2048 bytes.
The READ CAPACITY (10) response is two big-endian (network byte order) unsigned 32-bit integers for the last LBA and the block size. The problems you're having look like they're related to byte ordering. I think it's likely that the highest LBA is really 0x00007CF2. The blocksize is showing as 0 because it's in the byte at the other end of the integer, and was truncated.
I'm currently working with an Atmel SAM3X8 ARM microcontroller that features a dual banked 2 x 256KB flash memory. I'm trying to implement a firmware update feature, that puts the new firmware into the currently unused flash bank, and when done swaps the banks using the flash remapping to run the new firmware.
The datasheet states to do so I need to set the GPNVM2 bit, then the MCU will remap the memory, so Flash 1 is now at 0x80000 and Flash 0 at 0xC0000. This will also lead to the MCU executing code beginning from Flash 1.
To cite the datasheet:
The GPNVM2 is used only to swap the Flash 0 and Flash 1. If GPNVM2 is ENABLE, the Flash 1 is mapped at
address 0x0008_0000 (Flash 1 and Flash 0 are continuous). If GPNVM2 is DISABLE, the Flash 0 is mapped at
address 0x0008_0000 (Flash 0 and Flash 1 are continuous).
[...]
GPNVM2 enables to select if Flash 0 or Flash 1 is used for the boot.
Setting GPNVM bit 2 selects the boot from Flash 1, clearing it selects the boot from Flash 0.
But when I set GPNVM2, either via SAM-BA or my own firmware using flash_set_gpnvm(2) (ASF SAM Flash Service API), it will still boot from the program in Flash 0, and the new program will still reside at Flash 1's offset 0xC0000. The state of GPNVM2 has been verified by flash_is_gpnvm_set(2)
Flashing the firmware itself to Flash1 bank works flawlessly, that has been verified by dumping the whole flash memory with SAM-BA.
There is an errata from Atmel about an issue, that the flash remapping only works for portions smaller than 64KB. My code is less than that (40KB), so this shouldn't be an issue.
I've not found any other people having this issue, nor any example how to use it, so maybe somebody could tell me if I'm doing something wrong here, or what else to check.
I had the same issue (see here: Atmel SAM3X8E dual bank switching for booting different behaviour).
After some more research I found an Application Note (Link: http://ww1.microchip.com/downloads/en/AppNotes/Atmel-42141-SAM-AT02333-Safe-and-Secure-Bootloader-Implementation-for-SAM3-4_Application-Note.pdf) which explains the boot behaviour of the SAM3X in a more clear way. The problem is that the datasheet is a bit misleading (at least I was confused too). The SAM3X has no ability to remap the the Flash banks. The booting behaviour is a bit different (see the picture in the link, it's a snipped from the Application note, page 33/34):
Booting behaviour SAM3X
Picture 3-9 shows the SAM3X's behaviour at the boot-up. The GPNVM bits 1 and 2 just determine which memory section (ROM/Flash0/Flash1) is mirrored to the boot memory (located at 0x00000000). The mapping of the Flash banks is not changed. Therefore Flash0 still is mapped to 0x00080000 and Flash1 to 0x000C0000).
As the Application Note states some other Atmel microcontrollers are able to really remap the Flash banks (e.g. SAM3SD8 and SAM4SD32/16). These processors change the location of the Flash banks as you can see in picture 3-10.
To be able to update your firmware it is therefore necessary to implement some kind of bootloader. I implemented one by myself and was able to update my firmware even without using the GPNVM bits at all. I also opend a support ticket at Microchip to clarify the booting behaviour. When I receive an answer I hope to tell you more.
EDIT:
Here's the answer from the Microchip support:
Setting the GPNVM2 bit in SAM3X will merely make the CPU 'jump to' or start from flash bank 1 i.e. 0xC0000.
No actual swap of memory addresses will take place.
To use flash bank 1, you will need to change the linker file (flash.ld) to reflect the flash start address 0xC0000.
For flash bank 0 application, change:
rom (rx) : ORIGIN = 0x00080000, LENGTH = 0x00080000 /* Flash, 512K /
to:
rom (rx) : ORIGIN = 0x00080000, LENGTH = 0x00040000 / Flash, 256K */
For flash bank 1 application, change:
rom (rx) : ORIGIN = 0x00080000, LENGTH = 0x00080000 /* Flash, 512K /
to:
rom (rx) : ORIGIN = 0x000C0000, LENGTH = 0x00040000 / Flash, 256K */
If this is not done, the reset handler in the flash 1 application will point to an address in the flash 0 application.
So, although code will start execution in flash 1 (if GPNVM2 is set), it will jump back to the flash 0 application.
The errata stating the 64kb limitation can be ignored.
Therefore the Application Note is right and no actual change of the mmory mapping is performed.
Cheers
Lukas
We are trying to get our Micron NAND flash chip (MT29F2G08ABAEAWP) working. We are using u-boot as bootloader and our main processor is a TI DM8148. For evaluation we are using this evaluation module.
Now, the flash itself gets recognized by u-boot as 8-bit 2Gb NAND (which is correct). I'm able to flash 1st stage u-boot to 0x0 using the following uboot commands:
// select BCH8 as HW ECC
nandecc hw 2
// erase the first block
nand erase 0x0 0x20000
// write the content from RAM address 0x81000000 to the
// first flash block (0x0)
nand write.i 0x81000000 0x0 0x20000
However, when I try to read from that address using
nand read.i 0x81000000 0x0 0x20000
I get a lot of ECC: Uncorrectable errors. Choosing another ECC algorithm doesn't help. Booting from NAND (via ROM boot) doesn't work.
Any ideas?
Update:
Writing and reading every other block works like charm. Just the first one (Block 0) has those issues.
I know that issue is very specific. But I'm hoping that someone else might have had the same problems.
Thanks and greeting,
SamuelTee
In beagle board bring up we use this specific address below to load up uImage and dtb?
loaduImage=fatload mmc 0:1 0x80007fc0 uImage
loadfdt=fatload mmc 0:1 ${dtaddr} omap3-beagle-xm.dtb
Why can't we use some other address? It is pointed out in the data sheet of beagle board xm that DRAM address in beagle board starts from 0x80000000 so why not choose any address?
Why can't we load up uImage at some address and after 128MB load up dtb as suggested in https://www.kernel.org/doc/Documentation/arm/Booting documentation.
Quoting from the link: A safe location is just above the 128MiB boundary from start of RAM.
Header is 0x40, so kernel ends up in 0x80008000, a 4k page boundry. 0x80008000 is just convention and if you want you can change the address but you need to modify kernel code accordingly.
http://processors.wiki.ti.com/index.php/HOWTO_Change_the_Linux_Kernel_Start_Address
How can I boot my small console from a disk/cd/usb, with the following configuration:
The media that I want to use will be completely raw i.e no filesystem on it.
When I insert the media in my system or assume that its already inserted, I want to make it boot my own small OS.
The procedure that I want to use is that when my system starts, it boots from the disk/cd/usb, and starts my OS. For now imagine that the OS is going to be a hello world program. I actually want to see how the real world OS implement themselves.
A bootloader must be 512 bytes. No less no more.
And it must end with the standard PC boot signature: 0xAA55.
Also note a PC boots in 16 bits mode.
You need to load your kernel or secondstage bootloader from that code into memory, and then jump to that code (and maybe switch the CPU to 32 bits protected mode).
For instance (nasm):
BITS 16
; Your assembly code here (510 bytes max)...
jmp $
; Fills the remaining space with 0
times 510 - ( $ - $$ ) db 0
; Boot signature
dw 0xAA55
Thas the job of a boot loader. The bootloader should be present in the first 512 bytes of a HardDisk. This location is called MBR(Master boot record)
When bios loads it checks if the media contains the MBR. it verifies the MBR signature 0xAA55 which should be present as the last 2 bytes of MBR.
Then the Bios loads the BootLoader into RAM at address 0x7C00
Then the boot loader is the one who actually loads the kernal into memory, by reading the filesystem.
usually you cannot fit in all the code in 512 bytes, so there will be a secondory boot loader.
secondary bootloader will be loaded by your primary bootloader.
secondary boot loader loads IDT and GDT (Interupt vector table and Global descriptor table). Enables A20 gate to move into protected mode.
secondary boot loader loads the 32 bit kernel from disk into memory, then jumps to the kernel code
For more information you can download Linux kernel v0.01 (First version). Look how it is done. to my surprise the code to read the File system + the code to move into protected mode is fit into 512 bytes of code.