Hi, > i have a inet 3f tablet (pov protab 255xxl) and managed to get fedora 27 running on the board with a inet1 dtb, That means nothing to me, I'm guessing it's a cheap AllWinner based device, do you have any more details? Are you using a Fedora u-boot or your own? If Fedora what's it called? What Fedora image are you using? > The kernel from the initial image boots and everything (except for the touchscreen) works. Touch screen is no real surprise if it's an AllWinner based tablet, they change them constantly based on cost and availability. > this is version 4.13.3-300.fc27.amv7hl, > i also installed version 4.13.9-300.fc27.amv7hl, If one 4.13 works it's not surprising others do, what about 4.14.x > and these also work fine, > > Then i updated to the latest fedora 27 kernel 4.15.15-300.fc27.armv7hl and this kernel starts booting, but then the screen goes blank, and i cannot login via ssh either, Can you some how grab the output up until it goes blank, I suspect that last output might give us some idea. > the same happened with a self compiled kernel 4.17.0-0.rc0.git0.300.fc27.armv7hl with lima drivers patched. What about a Fedora 4.16.2 (built yesterday) kernel? Unfortunately we can't help with custom built kernels, it's almost impossible to remote debug the Fedora ones, custom is the never step of impossible. > I have tried to find the serial port pins on the board, but could not locate them, also kernel versions 4.14 i have not tried yet because i cannot find them precompiled. Kernels can always be found in koji to download: https://koji.fedoraproject.org/koji/packageinfo?packageID=8 You'll find every thing to the latest 4.17 linus snapshot there. > Are there any parameters i can change to try to make it boot, or get more output in the process? Or a link to documentation :) Sadly there's no MakeItWork kernel command line option, it's a matter of getting debug and trying to work out what went wrong and why. We don't explicitly support these devices due to the lack of ease of supporting them as you're finding out, but we don't do anything to actively stop them working, it's very much a best effort, I suspect there's something upstream that has regressed, the question is working out what, and the last of that early boot output will be the best spot to start. Peter _______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx
