[Bug 813407] Re: x-loader 1.5.1 beagle breaks under qemu

[Ricardo Salveti]

** Changed in: x-loader (Ubuntu)
     Assignee: Ricardo Salveti (rsalveti) => (unassigned)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to x-loader in Ubuntu.
https://bugs.launchpad.net/bugs/813407

Title:
  x-loader 1.5.1 beagle breaks under qemu

Status in “x-loader” package in Ubuntu:
  Confirmed

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/x-loader/+bug/813407/+subscriptions