From: Alberto Navatta Sent: Thursday, May 21, 2009 6:42 PM > > Hi Kevin, > > in general you are right, but in this case is the execution of the > bootloader to fail and there's no way to address the problem after > reboot. > > I think there's a problem in the logic implemented in the cfi flash > driver: > some driver operations don't leave the chip in read array mode and > this, > according to my point of view, causes the malfunction.
Alberto, as Onkar suggested, looks like this problem should have been fixed in board design. Are you facing this on DM644x EVM? Looking at the schematics here: http://c6000.spectrumdigital.com/davincievm/revf/files/DaVinciEVM_Schematic.pdf, the RST# of NOR flash is connected to RESETn of the DM644x. Watchdog reset should drive the RESETn low, which should put the NOR flash in read array mode. So, irrespective of what state the NOR flash was in at the time of watchdog reset, it should be in read array mode by the time ROM bootloader gets to reading it. Thanks, Sekhar > > If a clean reboot procedure is executed, a reboot notifier routine is > executed that puts the chip in the right state > In case of watchdog reboot the chip performs a maximum reset without > executing any software cleanup procedure and a subsequent boot fails > due to > impossibility to execute the bootloader from the flash (flash in an > inconsistent state). > > In fact, walking into the driver's code I've seen that: > * when the kernel loads the flash driver several operations are > performed > (chip probe, geometry detection, etc.), most of them put the chip in > ready > array mode after completion. > * when the NOR Flash partitions are given to the driver it configures > the > partitions to be write protected or unprotected, this operation > doesn't seem > to leave the chip in read array mode when completed. > * if later a read is issued on the device, the chip is correctly > configured > in read array mode > > In my case I was using the NOR flash to host the bootloader and the > kernel > while root file system stays on NFS so there was no read operation > after > partition configuration so: > * when a clean reboot was issued on the board everything went fine, > the > reboot notifier of the driver is called, the chip is configured in > read > array mode and reboot is successful > * when the watchdog expires the chip remains in the last state > asserted > during boot (FL_STATUS) so reset is successful but bootloader load > fails > because chip is not readable. > > I just changed the following lines in the cfi_cmdset_0001.c to go > always to > the ready state when an operation is completed (put_chip function): > diff -r1.1.1.1 cfi_cmdset_0001.c > 853d852 > < case FL_READY: > 855a855,858 > > case FL_READY: > > /* let's be safe: go back to ready state */ > > map_write(map, CMD(0xff), adr); > > chip->state = FL_READY; > > I've not made exhaustive tests to check that everything works fine > with this > change, anyway this fix seems to be ok in all the scenarios I have in > my > environment (kernel/root file system update performed by means of > ftp/flashcp commands executed in a shell script). > > Alberto > > -----Original Message----- > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > Sent: martedì 19 maggio 2009 17.05 > > "Alberto Navatta" <anava...@imnet.it> writes: > > > We?re trying to use the Davinci (dm6446) hardware watchdog in a > > custom board configured to boot from flash (u-boot 1.1.3 on an Intel > > PC28F128P30). > > > > We have seen that during soft reboot (e.g. reboot ?f command issued > > from the shell) the function ?cfi_intelext_reset? is called before > > machine reboot is triggered by means of the davinci watchdog > > (davinci_watchdog_reset function call), and this works fine. > > > > Instead, if we configure the watchdog to reboot the board on timer > > expire (e.g. configuring and triggering watchdog timer with the > > davinci_wdt device), the board seems to perform the maximum reset as > > expected but it never restarts. > > > > My understanding of this behavior is that the cfi_intelext_reset > > function performs a reset of the intel flash device so that the > > flash is found in the right state (array mode, to be used during > > boot), so, in the first case after the watchdog triggered reset the > > flash is readable by the CPU and boot process is performed > > successfully, while in the second one I suppose the flash chip is in > > an undetermined state and, after the reset, the boot process fails. > > > > Does anyone know a reasonable way to override this problem and to > > have a clean hardware watchdog triggered reset/reboot of the board? > > > > I mean we can have a timer based soft watchdog (e.g. softdog) that > > calls the flash reset function (cfi?) before to trigger the machine > > reset, but this requires some kind of software processing still > > available on the board (interrupt handlers, etc.): our environment > > is very critical and we cannot rely on any software portion to take > > care of software/kernel error conditions, we need to do it in > > hardware (possibly without adding an external hardware watchdog to > > the board). > > This sounds to me like a u-boot problem. The bootloader should make > sure the flash is in a usable state before booting. > > The point of a watchdog is to be able to do a hard reset in case > things go wrong. In these situations, you may not be able to do any > additional function calls etc. and just need to hard reset. > > It's the job of the bootloader to be able to reboot in this situation. > > Kevin > > > > > > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
