[U-Boot-Users] [Patch 0/9] U-boot-V2: Introduce I2C support for SDP3430

Timur Tabi timur at freescale.com
Wed Jun 18 17:39:30 CEST 2008


Menon, Nishanth wrote:

> Please see U-boot v2 here: 

Sorry, I didn't notice that your patch is for U-Boot V2.

> It does not have i2c support. And IMHO, using kernel like i2c addition in U-Boot v2 is appropriate. Why this is not a bloat U-Boot v2?

If it isn't, then it means that U-Boot V2 will be pretty bloated in general.

> A) Now, if you just want i2c_transfer without any device interface, you don't need to compile in the CHARDEV.
> B) Since we use a different linking strategy in U-Boot-v2 which uses gcc link stage to decide which functions be retained and which not, it is pretty neat to see all unused functionality disappear.
> C) kernel has additional bus and class types which are useful when we think in terms of varied features, in u-boot v2, we don't have a bus and class, just a plain device+driver interface like the kernel + ioctls to allow "apps" to invoke functionality within the driver for the device. Very linux like, call it a micro-linux ;). So kernel i2c architecture fits u_boot v2 better that u-boot v1's architecture.
> D) U-boot v2 has insmod + rmmod -> though this is still to be fixed, once it is fully functioning, you can loadb just the module feature you need. In fact, you could even have a filesystem with just modules....
> E) Ofcourse, we work in a single threaded, no interrupt mode in u-boot v2+ don't care for any power management -> more savings there

Sounds to me like U-Boot V2 is just a repacked Linux kernel.  We could probably
save ourselves a lot of trouble if we just took the DDR and CPU register
initialization code in U-Boot and moved it to the kernel.

-- 
Timur Tabi
Linux kernel developer at Freescale




More information about the U-Boot mailing list