From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Mon, 03 Sep 2007 20:18:01 -0400 Subject: [U-Boot-Users] [PATCH/RFC] mpc5200: switch to CONFIG_OF_LIBFDT In-Reply-To: References: <20070830173340.24697.19740.stgit@trillian.cg.shawcable.net> <20070903203655.GA16323@frozen.semihalf.com> <46DC83AD.6090507@gmail.com> <46DC8D58.7060000@gmail.com> Message-ID: <46DCA439.9080506@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Grant Likely wrote: > On 9/3/07, Jerry Van Baren wrote: >> Grant Likely wrote: >>> On 9/3/07, Jerry Van Baren wrote: >>>> Grant Likely wrote: >>>>> On 9/3/07, Bartlomiej Sieka wrote: >>>>>> On Thu, Aug 30, 2007 at 12:20:14PM -0600, Grant Likely wrote: >>>>>>> From: Grant Likely >>>>>>> >>>>>>> Here is a patch which converts the icecube* and tqm5200 boards from using >>>>>>> OF_FLAT_TREE to OF_LIBFDT. It also fixes the compile of cm5200. >>>>>>> >>>>>>> It's been tested on the lite5200. >>>>>> Tested also on motionpro, with the below patch that converts it to OF_LIBFDT. >>>>>> >>>>>> Grant: perhaps it would be a good idea to merge this patch with your >>>>>> upcoming updated patch for icecube and tqm5200? >>>>> Can do. I'll respin the patch and post it once more to the list >>>>> before asking wd to pull it. >>>>> >>>>> Cheers, >>>>> g. >>>> Hi Grant, >>>> >>>> My only critique/request is to change fixup_int_prop() to be >>>> fixup_u32_prop() so that we don't get confused if we ever have to fix up >>>> a u16 or u64 property. >>> No problem. Should I move it to libfdt as well? >>> >>> g. >> Sure! >> >> We have a 3-way coordination between you, Kim with the 83xx, and myself >> with libfdt and right now I'm pretty busy. I have not had the time to >> figure out where the routine should go and get together a set of patches >> for libfdt and 83xx to convert over to the New Improved helper routines. >> >> If you are willing to figure out where to put it in libfdt, I'll push >> forward from this end but it may be a couple of weeks before I can put >> some time in on it (unless my more "urgent" duties get boring ;-). >> >> In the last merge window, Kim & I traded some patches back and forth and >> git figured it out OK, so we should be able to apply the same patch to >> both your and my (and Kim's?) repositories and have it all work out. > > Alright, I'll do so. Where does the 'upstream' libfdt source live > nowdays? Do you want me to craft the change against the u-boot repo > and let you merge it back in to libfdt upstream? Or should I put a > temporary change into u-boot to fix the compile issues and base my > patch against libfdt upstream (with the mind to remove the temporary > fix when u-boot resyncs)? > > Cheers, > g. Hi Grant, The libfdt custodian repo is on the denx.de site, but should be the same as the mainline. I would say patch your 5xxx custodian repo, publishing the new functions that impact the libfdt stuff as a separate patch and The List can discuss them. I'll "ack" them and apply them to my repo as well, but NBD. I will plan on updating the 83xx implementation(s) and publish them for Kim to ack/adopt as well. When we get the basics of the New Improved[tm] utility functions set up, we can redo the 83xx at our leisure. Best regards, gvb