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 :).
>
> 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: [email protected]
To contact the owner, e-mail: [email protected]
