Saturday, June 27, 2009

LCD type autodetection not possible

Quick post: I'm almost 100% sure that LCD type autodetection is not and will never be possible. The /RD signal of the LCD is just not connected, so despite the fact that the LCD has a specific register to identify the model, it cannot be read.

Makes sense: maintaining two or more firmwares is definitely something to avoid, so if the makers of the A320 are doing it, it's because that's the only way.

Please, note that they use a trick to somewhat alleviate the problem: the LCD initialization code is stored in a special place in the NAND flash which is never touched when performing normal firmware updates. However, those of you that have used the unbricking tool have noticed that when restoring from scratch, one has to specify the LCD model by selecting the appropriate .DL file.

So, for the time being, there will be two releases, one for each LCD type. We cannot use the trick that the original firmware does because we cannot use the NAND flash to store settings. However, if (when) linux becomes a firmware replacement, we'll go that way.

4 comments:

  1. Maybe you can checksum the LCD init routine from the original firmware? There probably aren't many different versions of it. Since the init routine should always match the hardware of the device you're booting on, it's an indirect way of figuring out what hardware is present.

    ReplyDelete
  2. Thought already about that approach, but it's hard to implement in the SPL due to the limited code size (8K).

    And it would not work when linux eventually replaces the firmware, though them we'll be able to use a NAND block to store U-Boot environment and it could be stored there.

    ReplyDelete
  3. The routines that have to know the LCD type are the SPL and the frame buffer driver in the Linux kernel, is that correct?

    Maybe do the checksum computation in the dual boot installer and install a different SPL implementation for each LCD type. In addition, write a different set of kernel arguments to the U-Boot installation, telling the frame buffer driver which LCD controller model to use.

    (I haven't studied the boot process in detail, so please tell me if I'm talking nonsense.)

    ReplyDelete
  4. @mth

    Yes, that can be done, but is quite cumbersome as compared to releasing two perfectly identified binaries.

    ReplyDelete