On 27.01.2014, at 13:06, Andreas Färber
Am 27.01.2014 12:19, schrieb Alexander Graf:
On 27.01.2014, at 12:12, Andreas Färber
wrote: Am 27.01.2014 12:00, schrieb Alexander Graf:
On 27.01.2014, at 11:45, Andreas Färber
wrote: Am 27.01.2014 11:31, schrieb Alexander Graf:
On 27.01.2014, at 11:11, Andreas Färber
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: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org