Clemens Koller wrote: > [OT+sarcasm on] > > So, the time is over, where you just enable a driver in the kernel config and > the device gets probed and - if it's probed successfully - it usually works.
The problem is the "probed successfully" bit -- i2c can't be automatically detected like PCI can, and the probing that was being done before was very error-prone. Thus, there needs to be something describing what hardware is actually there, not just what the kernel supports. > Now, the way is like this: > > - enable the desired driver in the kernel. As always. > - check that the platform driver fsl_soc.c (in my case) defines the > desired rtc-chip in the i2c_board_info Once the glue code gets consolidated, it'll just be a one-time thing for any given chip to be added to the OF I2C table. I don't know why it was ever done in platform-specific code. > - check that the rtc is included in the device tree. This is the substitute for probing. > - embed the device tree to the kernel (cuImage) Or get it from the firmware. > - boot'n'pray. > > That looks really groundbreaking! > > Now, I cannot use one kernel for two almost identical hardware revisions > anymore because the rtc's on i2c are different? This must be a joke! Not at all true. The kernel just needs to know, at runtime, what hardware you actually have. It uses the device tree for this. With cuImage, you're limited to one device tree in a given build, though you can invoke the wrapper manually to create multiple images. However, cuImage is a compatibility measure; if you use a newer u-boot with device tree support, the tree does not need to be statically wrapped in the kernel image. > It seems like I first need to have full device tree support included in > the boot-loader to be able to duplicate my configuration work to allow > one kernel to boot on both hardware. That's the simplest way, but not the only way. You could also have a wrapper platform that chooses the proper device tree based on something you detect. > Hmmm... this just s****! There are some growing pains, but the old method of blindly poking at i2c addresses and hoping that the first driver to ask for a port that something responds to is actually the right driver for that port is just shit. -Scott _______________________________________________ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded