Le 27/01/2014 13:16, Alexander Graf a écrit :
> On 27.01.2014, at 13:06, Andreas Färber <afaer...@suse.de> wrote:
>
>> Am 27.01.2014 12:19, schrieb Alexander Graf:
>>> 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 :).
>> 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?
Not much time ATM. What is needed here?
Guillaume
>
>> 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+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
