On 27.01.2014, at 12:12, Andreas Färber <afaer...@suse.de> wrote: > Am 27.01.2014 12:00, schrieb Alexander Graf: >> On 27.01.2014, at 11:45, Andreas Färber <afaer...@suse.de> wrote: >>> Am 27.01.2014 11:31, schrieb Alexander Graf: >>>> On 27.01.2014, at 11:11, Andreas Färber <afaer...@suse.de> 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 :). > > Patches just changing boot.scr are much less of a hassle. > > [...] >>> 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. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org