x-loader 1.5.1 beagle breaks under qemu

Bug #813407 reported by Peter Maydell
This bug affects 2 people
Affects Status Importance Assigned to Milestone
x-loader (Ubuntu)

Bug Description

The latest x-loader (1.5.1) breaks under qemu (you can see this in the 20110718 snapshot, for example). What happens:

 * x-loader misprograms the OMAP clocks, specifically by writing values to CM_CLKSEL1_PLL which are for a 19.2MHz master clock rather than the correct 26MHz clock
 * this later causes the kernel on startup to fail to program some other clock, it complains:
[ 0.000000] Clocking rate (Crystal/Core/MPU): 26.0/224/500 MHz
[ 0.000000] Reprogramming SDRC clock to 224791666 Hz
[ 0.000000] dpll3_m2_clk rate change failed: -22
 * as a result of this the kernel ends up in an infinite loop shortly after "Freeing initrd memory"

The reason x-loader isn't programming the right clock rate is that the behaviour of get_cpu_rev() has changed.
This function used (in 1.5.0) to always return 1. The code in board/omap3530beagle/omap3530beagle.c clearly expects the revision to be between 1 and 3, since it does:
        sil_index = get_cpu_rev() - 1;
        /* Getting the base address of Core DPLL param table */
        dpll_param_p = (dpll_param *) get_core_dpll_param();
        /* Moving it to the right sysclk and ES rev base */
        dpll_param_p = dpll_param_p + 3 * clk_index + sil_index;

However the new 1.5.1 get_cpu_rev() returns basically the top 4 bits from the omap IDCODE register; on qemu this happens to be 4, so we index off the end of the three-element table of clocks for a 26MHz core and into the following table.

This bug seems to have been fixed for overo, which says:
        sil_index = (get_cpu_rev() == CPU_3XX_ES10) ? 0 : 1;

(commit https://gitorious.org/x-loader/x-loader/commit/24b8b7f41a83540433024854736518876257672c)

[These functions seem very similar between beagle and overo, perhaps there are other bugs fixed only in one of them...)

You could argue that qemu should model the IDCODE the hardware does (at the moment it's kind of a "beagle with a newer omap chip" I think), but if x-loader is going to be that picky it should stop with a useful "unrecognised hardware" error message rather than just doing the wrong thing.

Related branches

Changed in x-loader (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
assignee: nobody → Ricardo Salveti (rsalveti)
Revision history for this message
Ricardo Salveti (rsalveti) wrote :
Changed in x-loader (Ubuntu):
assignee: Ricardo Salveti (rsalveti) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.