> On 15 Oct 2016, at 13:37, Andreas Färber <afaer...@suse.de> wrote:
> Am 15.10.2016 um 13:09 schrieb Alexander Graf:
>> Am 15.10.2016 um 12:14 schrieb Andreas Färber <afaer...@suse.de>:
>>> Am 15.10.2016 um 12:07 schrieb Alexander Graf:
>>>> Am 15.10.2016 um 11:59 schrieb Andreas Färber <afaer...@suse.de>:
>>>>> Am 13.10.2016 um 10:37 schrieb Guillaume Gardet:
>>>>>> On devel:ARM:Factory:Contrib:RaspberryPi3 project, there are currently
>>>>>> 2 DTB packages:
>>>>>> * dtb-aarch64 : compiled broadcom DTBs from sources and output a
>>>>>> bcm2837-rpi-3-b.dtb file too.
>>>>> I've recovered my rpi3 setup and successfully tested the above .dtb now:
>>>>> It showed the wlan0 interface. :)
>>>>> Booting required changes to /etc/dracut.conf.d/raspberrypi_modules.conf:
>>>>> * Add bcm2835-sdhost to add_drivers line
>>>>> * Add new line omit_drivers+=" sdhci-iproc" (courtesy of Fabian)
>>>>> (Remember to run mkinitrd or dracut with suitable options afterwards.)
>>>>> I'll later prepare a JeOS SR making the switch.
>>>> Please beware that this renders the image incompatible with upstream
>>>> kernels, so you can't just install 4.8 and have it work.
>>> Yes, but we don't yet have a working 4.8 image anyway.
>> What I'm worried about is that we block the upgrade path. A JeOS image which
>> blacklists iproc won't be able to upgrade to a newer kernel - unless the
>> bcm2835-sdhost driver also goes upstream.
> Well, what alternative solution is there? The upgrade path is already
> blocked today for rpi3, rpi2 and rpi for lack of sdhci-iproc. And I am
> trying to close a bug here:
> We could add both drivers to add_drivers for raspberrypi3_aarch64 for
> futureproofness - that should not regress then. But supposedly without
> the omit_drivers there were probing issues. I can leave that commented
> out, but that's no full solution for the bug in the current image then.
> Also FTR I have repeatedly said that in order to update these config
> files we should put them in a package; but you Alex were against that,
> saying they were just temporary hacks and shouldn't need to exist at
> all. We need to die one death or another! Either people need to manually
> tweak the configs from time to time, or we can't just throw them into
> the JeOS package.
Yeah, I guess putting them into board support packages is the sane way to go in
this case. Then we can at least have the “normal” upgrade path work. So people
will be able to upgrade Tumbleweed from contrib to proper or 42.2 to 42.3.
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org