| 04:35 | jnettlet[m]> | Ke: you also can not do recovery over that uart. That is only activated on the micro-usb uart interface. |
| 07:13 | Ke> | jnettlet[m]: you mean, just throw the device into trash, once it doesn't boot? |
| 07:14 | jnettlet[m]> | Ke: no you will just need access to the micro-usb header to do a straight recovery. Of course you can always change the jumpers to use sdhc for recovery as well. |
| 07:15 | Ke> | it's not about the recovery, also about logging failures |
| 07:15 | jnettlet[m]> | it is a developer board :) |
| 07:15 | Ke> | well just |
| 07:24 | Ke> | it seems that the new dtb helped and now I get serial ports active on debian |
| 07:24 | Ke> | just a question, are the microusb headers available somewhere? |
| 07:25 | jnettlet[m]> | most likely that will not be the final configuration. I think I want one uart enabled and the other to be 2 gpios, one of which can be used for a hdd led. |
| 07:25 | jnettlet[m]> | the microusb port is connected to a ttl converter...it is only serial |
| 07:26 | Ke> | but you can use my awesome arduino design to do hdd led =o( over the serial =o( |
| 07:26 | Ke> | it even has checksums for serial comms! |
| 07:26 | jnettlet[m]> | sure, but I think most just want to plug a cable into a header |
| 07:27 | Ke> | anyway this patch already got in to the dt64 tree |
| 07:27 | jnettlet[m]> | we had a discussion about it yesterday. It isn't tagged immutable so it can be changed. |
| 07:28 | Ke> | I didn't actually know the pins were configurable to be something else |
| 07:28 | jnettlet[m]> | yep, almost all the pins can be muxed for various functionality...not as flexible as the mx6 but configurable |
| 07:29 | Ke> | I guess there is no way to just mux them as uart0? |
| 07:29 | Ke> | anyway, it's probably not too difficult to chance edk2 configuration to change the serial port |
| 07:30 | jnettlet[m]> | no. You can remap them in uefi or uboot to be the uart0 device...but the 8040 bootstrap will always use the uart connected to the microusb |
| 07:32 | jnettlet[m]> | FYI you have to be very careful not to connect the uart cable in the wrong direction. We found out that Marvell didn't protect the circuits at the SOC....so 3.3V in the wrong direction can damage the board. |
| 07:32 | jnettlet[m]> | we will need to fix this in future designs, but it is something we just came across a couple of weeks ago. |
| 08:52 | Ke> | ttyS2 works with J27, ttyS1 did not work with J25 somehow |
| 08:52 | Ke> | though I am half blind so may not have been connected |
| 09:33 | Ke> | yeah, now watchdog is inside the case |
| 09:34 | Ke> | I should perhaps wait a couple of minutes |
| 09:36 | Ke> | I would now need some good short sata cables |
| 09:36 | Ke> | then ones I have now are incredibly stiff |
| 09:39 | Ke> | also, I guess I should implement a reboot code for the watchdog |
| 09:39 | Ke> | as in reboot, when not crashing |
| 09:41 | jnettlet[m]> | Ke are you using your arduino as an external watchdog? Hooked up to the reset header? |
| 09:41 | Ke> | yes |
| 09:41 | Ke> | I was actually planning to use gpio for that, but did not find any gpio headers |
| 09:42 | Ke> | and I did not know the headers were reconfigurable |
| 09:43 | Ke> | I am also getting feeling that reset header might not be strong enough and I might have to steal the atx header signal |
| 09:43 | Ke> | ie. there is sometimes some persistent bad state |
| 10:01 | jnettlet[m]> | Ke: I use the reset header hooked to the power button of my case. If you are using a common ground then you should have no problem using that to reset the system via a GPIO |
| 10:02 | jnettlet[m]> | this is a hard reset, not via the internal watchdog |
| 10:02 | jnettlet[m]> | I can test quick if you would like. |
| 10:03 | Ke> | no need |
| 10:07 | Ke> | the watchdog works quite well to the extent of completely correctly bringing the system to ATF init, but there may be some persistent hw state that is not reset that way |
| 10:07 | Ke> | but is reset by doing full power reset to the whole system |
| 10:08 | Ke> | I almost always get up to booting linux, the RNG thing suihkulokki described may be related |
| 10:08 | Ke> | but this problem seems deterministc in this case |
| 10:09 | Ke> | but I will continue production testing now |
| 10:10 | Ke> | let's see if it ever crashes that way again |
| 10:11 | Ke> | https://users.aalto.fi/~jkarlson/files/arduino.svg |
| 10:13 | Ke> | and I am indeed assuming the ground is shared for the whole system |
| 16:35 | Ke> | now that I think of it, my watchdog is on the bottom of the case, wonder it's not short circuiting |
| 16:41 | Ke> | probably the wiring is blocking full contact |