On 27.01.2014, at 13:06, Andreas Färber <[email protected]> wrote: > Am 27.01.2014 12:19, schrieb Alexander Graf: >> On 27.01.2014, at 12:12, Andreas Färber <[email protected]> wrote: >>> Am 27.01.2014 12:00, schrieb Alexander Graf: >>>> On 27.01.2014, at 11:45, Andreas Färber <[email protected]> wrote: >>>>> Am 27.01.2014 11:31, schrieb Alexander Graf: >>>>>> On 27.01.2014, at 11:11, Andreas Färber <[email protected]> wrote: >>>>>> >>>>>>> In particular I am not so happy about you guys hardcoding OMAP4 hacks in >>>>>>> generic code that is being reused by all u-boot-* packages with SPL. >>>>>> >>>>>> Uh - where exactly do we have OMAP4 hacks in generic code? >>>>> >>>>> The bulk of mlo-ext2.patch is in common/spl/spl_mmc.c! >>>>> >>>>> spl_mmc_load_image() is being patched with >>>>> + boot_mode = MMCSD_MODE_FAT; /* Fix OMAP4 boot */ >>>> >>>> Where is that an OMAP4 hack? It just sets the boot mode to FAT (which we >>>> reuse for ext2) rather than raw. >>> >>> It affects more than just "MLO". I expect mlo-ext2.patch to only affect >> >> It predates SPL. That's why it's called MLO. It really is supposed to be >> generic. >> >>> TI stuff, not Tegra, ODROID, and whomever comes along. It should really >>> be split in two otherwise, one for configs/omap{3_beagle,4_common}.h and >>> one for common SPL fiddling. Fixing "OMAP4 boot" by touching common code >>> in a patch that is applied to all linked packages is simply not OK. >> >> Yes. They really should be separate patches. I agree. It's just naturally >> grown this way because OMAP4 was the first upstream u-boot we were running >> with ext2 /boot. >> >>> >>> Same for the huge sunxi patch - why can't that live in Contrib:sunxi >>> rather than me having to count my fingers for how that patch was created >>> and what to do with it on update. >> >> IIRC It was an attempt to move towards a single code base :). > > Getting sunxi patches into upstream u-boot.git might be a better way > forward? The patch hasn't really shrunk much with the new version. :/
The last thing I remember from Dirk somewhere on this mailing list was "please remove it, I'll maintain a fork in the SunXi contrib". > > [...] >>>>> It really sucks that it's all a gross local hack that none of you >>>>> upstreamed with proper CONFIG_* guards since 2012. >>>>> My .gnu.hash patch I immediately submitted upstream after verifying that >>>>> u-boot-am335xevm builds without mlo-ext2.patch. >>>> >>>> That one's slightly less controversial too ;). >>> >>> If it's so controversial then why are we carrying it and allowing it to >>> hold up updating our generic U-Boot for, e.g., the rpi_b? :) >> >> I take no rpi support over FAT /boot any time :). But they really shouldn't >> conflict. > > I guess most of us prefer one's board(s) working over someone else's > filesystem. :) Once a board works, there's no strong reason to > zypper-update the bootloader. > > https://build.opensuse.org/request/show/215263 > > If you can clean up the patch and restore the build so that we can get > it submitted into Factory, I'll be happy. Sorry, I won't get around to anything except for KVM and QEMU patches for the next few days. I'm moving houses tomorrow and will try to squeeze in as many patch reviews as I can in between so that I don't miss the next merge window. Guillaume, do you have some spare time atm? > > Even more so if you could create a u-boot fork on openSUSE GitHub > similar to qemu, so that the next rebase will be less painful. > quilt setup refused to work with our %prep section and I didn't find out > why, thus as mentioned in .changes I sat down manually reworking some of > the .patch files in the editor, which might explain my mood... Welcome to the wonderful world of rpm packaging :). I'll be happy to apply our git based workflow to u-boot as soon as I've got some air to breathe again. Alex -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
