JTAG debug disabled for old firmware with new SD card image

[Bernie Ogden]

I'm using two V11 Snowballs. One has its original firmware on emmc, the other has been reflashed with Linaro 12.02.

Conditions:
Linaro 12.02 on emmc, booting Linaro 12.02 on emmc: JTAG available
Linaro 12.02 on emmc, booting Linaro 12.02 on SD card: JTAG available
Original firmware on emmc, booting Linaro on emmc: JTAG available
Original firmware on emmc, booting Linaro 12.02 on SD card: JTAG unavailable

In the case where JTAG is unavailable, 'dmesg | grep -i jtag' says '[ 1.557067] ux500-product: JTAG is disabled'

'Original firmware' means:
U-Boot 2009.11 (sept. 19 2011 - 17:03:11)
Linaro 11.09 (development branch) (GNU/Linux 2.6.38-1001-ux500 armv7)

'12.02' means:
U-Boot 2009.11 (Dec 07 2011 - 20:26:08)
Linaro 12.02 LEB (kernel 3.2.0-1000-ux500 #7)

I've seen similar behaviour with Linaro 12.01 SD images.

I'm not sure whether this will be considered a bug or expected behaviour - but, given that SD card images are provided, it would be good if they worked in all respects without touching the on-board flash.

I'm also not clear on whether newer V11 Snowballs are likely to have newer firmware and thus not show this problem. It's less of a problem if this is the case.

[Sunil Kamath (sunil-kamath)]

Normally any developer will do debugging in any of these two methods:
1. use JTAG/T32 to load entire image to SDRAM and start debugging.
2. Flash the image in eMMC and use JTAG/T32 to attach and debug.
Normally 2nd method is preferred when debugging ICS/Ubuntu.

SD card based images also have their own advantages. It’s very easy for people who debug using trace. Easy to formal or replace images or to test same image on multiple boards. But with a mandate that boot binaries are flashed in respective board’s eMMC.

We do not consider this as problem. This is feature. All methods of debugging have their own advantage and drawbacks’ as well.
If one plans to use trace based debugging, continue to use SD card images. (even eMMC can be used)
If issue cannot be debugged with traces, and usage of T32 is mandatory then use eMMC images.

[Kalle Vahlman (kvahlman)]

Also as a general note, booting from SD means that the boot binaries and u-boot could be from the initial deliveries which would be roughly a year ago.

Supporting all combinations of each released rootfs since (and in the future) and each version of boot binaries and u-boot that ever existed is not only practically impossible; there have been changes in the boot binaries and especially in u-boot also propagate to the kernel side occasionally. This is basically what the bug report is about.

So the answer is that if you are having trouble with the old firmware/u-boot, please flash up-to-date ones. There should be no reason to do that really.

[Kalle Vahlman (kvahlman)]

"... no reason to NOT do that."

duh.

[Bernie Ogden (bogden)]

My concerns are really about usability, but I raised this in hopes that it would turn out to be a bug. Just for the record, these are the sorts of issues I'm concerned about -

1) It's a pain to have to reflash the board on a monthly basis in addition to generating a new SD image - which I need to do if tracking Linaro LEBs.
2) Any 'getting started' instructions that 3rd parties write become that much more complex, or become fragmented by pointers to the flashing HOWTO on igloocommunity.
3) Nothing on the linaro.org download page for the Snowball LEB suggests that you might need to reflash the firmware. By implication, there's no need to. I'll ask about getting the page updated.
4) Reflashing the firmware eliminates a known state that you would otherwise be able to return to.

I appreciate that if the present situation makes sense technically then we just have to live with some more complexity, so I'm not really objecting to the decision not to fix.

[Kalle Vahlman (kvahlman)]

1) It's not mandatory to reflash every time, just if you have problems...

2) I'm not sure why that would be, any instructions should start with "get the latest/certain version of sw here and install it according to flashing howto". I mean, any instructions need to ensure that the baseline is the same or they will be obsoleted by sw upgrades (not only firmware).

3) Yes, it's a bit unfortunate that Linaro favors so much the SD approach which is vulnerable for this issue. Documenting that there is a dependency on the release page is definitely a good idea.

4) Depends on the POV, reflashing for me _restores_ the known state ;)