I am trying to replace flash memory blocks however, i could not probe any flash:
device>sf probe 0
SF: Unsupported flash IDs: manuf ff, jedec ffff, ext_jedec ffff
Failed to initialize SPI flash at 0:0
Do you know how to handle this or any possible reasons or workaround?
Thanks.
Related
I have several devices on mdio bus - 1 phy AR8035 and 3 Dual Phys DP83849ifvs. The mdio bus is controlled by AM335x SoC. The problem is that I can't get mdio access to AR8035 PHY, but DP83849ifvs mdio r/w is ok. I check it with help of u-boot 2020.07 (mdio read 0 2 command). DP83849ifvs has 0,1,2,3,8,9 PHYIDs (they are dual phys so 2 addresses on one IC), AR8035 has 4 PHYID. When I try to read it with mdio read 4 2 I get Error. I wanted to look closely on MDIO frame via oscilloscope but I found strange behavior on MDIO bus - there are a lot of frames non stop, ~100us between them. I wonder is it normal behavior for MDIO bus assuming I am in u-boot environment? Maybe AR8035 was damaged, went crazy and now flooding the bus? Thanks!
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
I am handling interrupt for a device in Android. (Android 4.2.2 Kernel 2.6.29, running on Mach-Goldfish virtual device).
So far I have registered my device with the interrupt #17. It hasn't been enabled yet so signals sent to this interrupt are ignored and my interrupt handler is not notified.
The register that enables my device is at offset 0x00, and the memory address, as returned by
(char __iomem *)IO_ADDRESS(resource->start - IO_START)
starts at 0xFE016000.
I tried: (in mydevice_probe())
writel(0x07, 0xFE016000);
//0x07 is a mask to enable three sub-devices at bit 0, bit 1 and bit 2.
But the kernel crashed right away. The following writels also did not work:
writel(0x00, 0xFE016000);
writel(0x01, 0xFE016000);
What did I miss? Could any one show me how to get this done? In case I got the start address wrong, could you point out the way to get it correctly?
Thanks.
P/S: The kernel panic:
qemu: fatal: mydevice_write: Bad offset fea000
R00=c02ef00b R01=00000000 R02=00000007 R03=e0808000
R04=c0340864 R05=c031e3b0 R06=c0173b6c R07=c031e3cc
R08=00000000 R09=00100100 R10=00000000 R11=df827e34
R12=ff016000 R13=df827e18 R14=c002e96c R15=c0030aac
PSR=20000013 --C- A svc32
Aborted (core dumped)
This is to close my question.
it turns out that the emulator is faulty.
Normally writel(MASK, IO_ADDRESS(resource->start - IO_START)); should work.