Re: RockPro64 with latest image fails to boot?
Sleep Walker <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <CAHa8N8-WDZNFrMn=CHpb2NhMFNzb8KcFYnhKT+hNPFqg+K-6tQ@mail.gmail.com> |
Hi Søren! Here is a custom u-boot-2020.07 port that allows you to get eDP video on the Pinebook-Pro. https://github.com/S199pWa1k9r/ports/tree/master/sysutils/u-boot-pinebook-pro A kernel patch is also needed ... http://dev.kubsu.ru/images/PineBook-Pro/ чт, 6 авг. 2020 г. в 14:51, Emmanuel Vadot <[email protected]>: > On Thu, 6 Aug 2020 13:46:16 +0200 > Søren Schmidt <[email protected]> wrote: > > > > > > > > On 6 Aug 2020, at 12.13, Emmanuel Vadot <[email protected]> wrote: > > > > > > On Sun, 2 Aug 2020 11:30:00 +0200 > > > Søren Schmidt <[email protected] <mailto:[email protected]>> > wrote: > > > > > >> > > >> > > >>> On 1 Aug 2020, at 23.55, Bjoern A. Zeeb < > [email protected]> wrote: > > >>> > > >>> > > >>> In case you would be willing to try building a kernel yourself, try > something with a lot of non-essential modules (e.g. the allwinner modules) > removed and see what happens (just trying to make the size of the kernel > smaller). > > >> > > >> Thats where I startet to see the problem, with my own minimal kernel > config, to make certain I hadn?t goofed it up I tried the latest stock > image. > > >> > > >> I have tried different SD cards and PSU's to rule those out (and yes > it boots every time on a NetBSD image). > > >> > > >> However from 20+ boots I can say that it dies in different places but > close to the original post here. BUT it did manage to boot once (without > HDMI). > > >> As the HW boots my older custom kernel just fine (and the other > BSD?s) I don?t think its a HW problem, but more likely a race of sorts > since it did boot once. > > >> > > >> The same issue is with my pinebookpro, it behaves exactly the same, > but no output on the display at all, just console.. > > > > > > There is no support for eDP in mainline u-boot. > > > Some patches are around to add support but I don't think that they > > > have been submitted upstream. > > > There is another issue with eDP and FreeBSD kernel, u-boot set the > > > CPLL to 600Mhz (iirc) but the DTS have it set to 800Mhz so when we > > > process the assigned-clocks property and set it to 800Mhz the eDP > > > clock (which is derived from CPLL) isn't correct anymore and we lose > > > the display. > > > > OK, I?ll look around a bit and see what gives.? > > > > > > > >> I?ll try to backstep -current to where it did work and se it that > brings any light over the issue? > > > > > > Did you find anything ? > > > > Yeah VirtualBox managed to crash my Mac into oblivion, so I?m just about > finished getting things back together again (timemachine is nice :) ) > > > > However, it also fails with my previously good -current release, so that > points pretty squarely at u-boot 2020.07. I?ll try to go back to 2020.04 > (plus patches to find 4G etc). > > What patches are you talking about ? > > > --Søren > > > > [email protected] / [email protected] > > "So much code to hack, so little time" > > > > > -- > Emmanuel Vadot <[email protected]> > _______________________________________________ > [email protected] mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "[email protected]" > _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "[email protected]"