Difference between revisions of "Talk:Firmware upgrade"
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | == Some issues, found during testing this | + | == Some issues, found during testing this software in Shanghai == |
=== Long waiting while trying to detect IDE (sometimes USB too) === | === Long waiting while trying to detect IDE (sometimes USB too) === | ||
| Line 35: | Line 35: | ||
=== Destroy parameters in the memory === | === Destroy parameters in the memory === | ||
Current software verifies contents of the several locations of the system memory to distinguish between "cold" (power-cycling) and "warm" (just software-initiated reset). But memory sometimes hold data long after power is disconnected. In practice fvro several cameras I've got kernel panic when I did not wait for some 10 seconds before reapplying power. Solution is rather simple - destroy that memory data immediately after usage . | Current software verifies contents of the several locations of the system memory to distinguish between "cold" (power-cycling) and "warm" (just software-initiated reset). But memory sometimes hold data long after power is disconnected. In practice fvro several cameras I've got kernel panic when I did not wait for some 10 seconds before reapplying power. Solution is rather simple - destroy that memory data immediately after usage . | ||
| + | --[[User:Andrey.filippov|Andrey.filippov]] 22:33, 19 July 2007 (CDT) | ||
Latest revision as of 23:12, 19 July 2007
Some issues, found during testing this software in Shanghai
Long waiting while trying to detect IDE (sometimes USB too)
problem itself
There is no resistor pull-up/pull-down on the required IDE and USB lines on the 10353 board. It is "not a bug, but a feature" - the same lines could be used for other interfaces, so the required loads are included on the add-on boards (like 10349).
emergency solution
As an emergency measure I temporarily removed IDE+USB support from the configuration files (product and kernel - [1], [2]), but it is possible to modify the IDE driver module to detect the 10349 board and enable/disable IDE (and USB together) at run time (during initialization of the module).
real soulution
For that we can use the fact that
- signals PD15/IORDY is pulled up high on 10349,
- signals PD16/DMARQ and PD17/INTRQ - pulled low on 10349.
It is possible to use "memory" of the floating trace - if it is pulled low, released and tested with a short delay- it should stay low, if high - high.
IORDY can be both high ad low when the hard drive is connected, but there should be no activity on the DMARQ line, so the following algorithm would detect that loaD
So the following algorithm will detect existence of the 10349 board:
- program PD16 to be OUTPUT, controlled by the main CPU (not part of IDE)
- program that pin high (logic 1)
- change PD16 to be input
- (maybe not needed) udelay(1)
- read PD16.
- if it is 0 - 10349 is present pulling it low. Enable IDE (and USB too) First - change PD16 to be part of IDE (if it is not done anyway by the initialization part of the Axis IDE driver that you are modifying)
If it is read 1 - nothing is connected, disable IDE (and USB too)
In the future we'll need to find a way to delay HDD detection. In Helios 10357 board that provides CF as IDE devices needs to have FPGA programmed first.
anticipated problems
That approach will not immediately work with the 10357 board where the CF cards are connected to 10353 IDE bus through additional programmable FPGA (that is completely dumb at startup).
Solution would require to program 10357 FPGA before attempting to detect IDE devices , and you need to program 10353's FPGA even earlier as only it has control over 10357's FPGA programming pins. And JFFS should be mounted before that - the FPGA configuration files are stored there.
JFFS CRC errors after (re)flashing camera
THe script that writes to JFFS during installation should nicely use "sync" at teh end.
Don't try to reboot if button was pressed at power-up
When the camera writes the flash after booting from the network, script tries to reboot the camera. But unfortunately if the camera was powered up (not just reset) with a button held pressed it will go to network boot again. Only if it was the first boot of the camera with empty flash (then it goes to network boot even w/o button) it will reboot as desired, So maybe leave the camera running if it will fgail to reboot anyway? To prevent it from reflashing from the network forever?
Destroy parameters in the memory
Current software verifies contents of the several locations of the system memory to distinguish between "cold" (power-cycling) and "warm" (just software-initiated reset). But memory sometimes hold data long after power is disconnected. In practice fvro several cameras I've got kernel panic when I did not wait for some 10 seconds before reapplying power. Solution is rather simple - destroy that memory data immediately after usage . --Andrey.filippov 22:33, 19 July 2007 (CDT)
