[U-Boot] [PATCH 07/12] sniper: Serial number support, obtained from die ID

[Paul Kocialkowski]

Le jeudi 13 août 2015 à 08:13 -0400, Tom Rini a écrit :
> On Fri, Aug 07, 2015 at 11:44:46AM +0200, Paul Kocialkowski wrote:
> > Le mardi 04 août 2015 à 14:27 -0400, Tom Rini a écrit :
> > > On Tue, Aug 04, 2015 at 08:22:39PM +0200, Paul Kocialkowski 
> > > wrote:
> > > > Le mardi 04 août 2015 à 14:16 -0400, Tom Rini a écrit :
> > > > > On Tue, Aug 04, 2015 at 08:02:40PM +0200, Paul Kocialkowski 
> > > > > wrote:
> > > > > > Le lundi 03 août 2015 à 22:08 -0400, Tom Rini a écrit :
> > > > > > > On Mon, Jul 20, 2015 at 03:17:13PM +0200, Paul 
> > > > > > > Kocialkowski wrote:
> > > > > > > 
> > > > > > > > The OMAP3 has some die-specific ID bits that we can use 
> > > > > > > > to give the device a
> > > > > > > > (more or less) unique serial number. This is 
> > > > > > > > particularly useful for e.g. USB.
> > > > > > > > 
> > > > > > > > Signed-off-by: Paul Kocialkowski <contact at paulk.fr>
> > > > > > > > ---
> > > > > > > >  board/lge/sniper/sniper.c | 13 +++++++++++++
> > > > > > > >  1 file changed, 13 insertions(+)
> > > > > > > > 
> > > > > > > > diff --git a/board/lge/sniper/sniper.c 
> > > > > > > > b/board/lge/sniper/sniper.c
> > > > > > > > index 44d422d..f26855d 100644
> > > > > > > > --- a/board/lge/sniper/sniper.c
> > > > > > > > +++ b/board/lge/sniper/sniper.c
> > > > > > > > @@ -70,7 +70,9 @@ int board_init(void)
> > > > > > > >  
> > > > > > > >  int misc_init_r(void)
> > > > > > > >  {
> > > > > > > > +	char serial_string[17] = { 0 };
> > > > > > > >  	char reboot_mode[2] = { 0 };
> > > > > > > > +	u32 dieid[4] = { 0 };
> > > > > > > >  
> > > > > > > >  	/* Reboot mode */
> > > > > > > >  
> > > > > > > > @@ -82,6 +84,17 @@ int misc_init_r(void)
> > > > > > > >  		omap_reboot_mode_clear();
> > > > > > > >  	}
> > > > > > > >  
> > > > > > > > +	/* Serial number */
> > > > > > > > +
> > > > > > > > +	get_dieid((u32 *)&dieid);
> > > > > > > > +
> > > > > > > > +	if (!getenv("serial#")) {
> > > > > > > > +		snprintf(serial_string, 
> > > > > > > > sizeof(serial_string),
> > > > > > > > +			"%08x%08x", dieid[0], 
> > > > > > > > dieid[3]);
> > > > > > > > +
> > > > > > > > +		setenv("serial#", serial_string);
> > > > > > > > +	}
> > > > > > > > +
> > > > > > > >  	return 0;
> > > > > > > >  }
> > > > > > > 
> > > > > > > Shouldn't this be in more generic code so everyone gets 
> > > > > > > this set now?
> > > > > > > Thanks!
> > > > > > 
> > > > > > Well, we had a similar discussion for sunxi, and the 
> > > > > > outcome was that
> > > > > > serial number could be obtained from other places on other 
> > > > > > devices (e.g.
> > > > > > EEPROM) or be calculated from the dieid bits in a different 
> > > > > > way, so I
> > > > > > prefer to keep this board-specific instead of omap3-generic 
> > > > > > for now.
> > > > > > 
> > > > > > This merely matches what is done on Android OMAP devices, 
> > > > > > but one could
> > > > > > do it another way, too.
> > > > > > 
> > > > > > What do you think?
> > > > > 
> > > > > I think, ug,
> > > > > arch/arm/cpu/armv7/omap
> > > > > -common/utils.c::usb_set_serial_num_from_die_id()
> > > > > should be called set_serial_num_from_die_id() and we can use 
> > > > > that for
> > > > > this board too even if it's not ideal.
> > > > 
> > > > Oh okay then, I don't have any problem with making this code 
> > > > common,
> > > > especially if it's not called by every omap3 board then.
> > > > 
> > > > I agree with your proposal. Should I submit a v2 with a patch 
> > > > in that
> > > > direction?
> > > 
> > > Sounds good, thanks!
> > 
> > Taking a closer look at things, it appears that various (non-omap3)
> > boards are grabbing the Die ID bits on their own and then calling 
> > those
> > functions (usb_fake_mac_from_die_id, 
> > usb_set_serial_num_from_die_id).
> > 
> > IMHO, we should have a common naming scheme for the function to get 
> > the
> > dieid (omap_dieid), define that for each omap platform and have it
> > called in omap-common code (with one function for the serial number 
> > and
> > one for the fake mac), just like what I did with 
> > omap_sys_boot_device.
> > 
> > Then, each board would simply call those functions directly, 
> > without
> > having to care about how to obtain the die id bits.
> > 
> > This seems like a series that would deserve to live on its own, so 
> > I
> > suggest that you merge Optimus Black support as-is for now and I'll
> > submit another series to implement that behaviour on top.
> > 
> > What do you think?
> 
> Yes, OK, follow-up series to clean-up that for everyone.

Good, thanks for merging this, I'll get around producing that series
sometime next week, I'm at CCCamp for now!

-- 
Paul Kocialkowski 

* Site web : http://www.paulk.fr/
* Blog : http://blog.paulk.fr/
* Dev blog : http://code.paulk.fr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150816/90c8729b/attachment-0001.sig>