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. 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:[email protected]] Sent: martedì 19 maggio 2009 17.05 "Alberto Navatta" <[email protected]> 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 [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
