This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Fedora
#1
I can't believe that there's not a Fed release yet.  I've tried FedArm 28 and it doesn't even try to boot.  No flashing green light and no activity on the HDMI port.

Any suggestions?
Reply
#2
That is not listed as installable OS, so it would take a skill to prepare the boot loader to load the kernel and rootfs.
I've tried for Archlinux ARM, and it's just operational (I haven't try to set up a GUI, yet). So for the first step I did just to remove all the rootfs and set the new OS in it. Then I needed to copy the kernel and the few modules that linaro gave and use depmod to refresh the module dependencies.

It might need to pay attention to leave the partition as is, otherwise the boot loader won't recognize the rootfs, so I deleted only the files contained, without formatting the partition.

This method may work for several distros, but doesn't offer chances to upgrade, because the kernel will definitely hold all the dependencies.
 
At the second attempt I studied to compile the u-boot. Then I done the necessary steps to give the correct parameters and configuration to the kernel. So that's working now with
Code:
$ uname -a
Linux alarm 4.18.1-1-ARCH #1 SMP PREEMPT Fri Aug 17 02:34:50 UTC 2018 armv7l GNU/Linux
Big Grin Big Grin

Fedora != debian, then there might be differences to solve. Did you installed before ?
Reply
#3
(08-30-2018, 03:25 AM)Im4Tinker Wrote: That is not listed as installable OS, so it would take a skill to prepare the boot loader to load the kernel and rootfs.
I've tried for Archlinux ARM, and it's just operational (I haven't try to set up a GUI, yet). So for the first step I did just to remove all the rootfs and set the new OS in it. Then I needed to copy the kernel and the few modules that linaro gave and use depmod to refresh the module dependencies.

It might need to pay attention to leave the partition as is, otherwise the boot loader won't recognize the rootfs, so I deleted only the files contained, without formatting the partition.

This method may work for several distros, but doesn't offer chances to upgrade, because the kernel will definitely hold all the dependencies.
 
At the second attempt I studied to compile the u-boot. Then I done the necessary steps to give the correct parameters and configuration to the kernel. So that's working now with
Code:
$ uname -a
Linux alarm 4.18.1-1-ARCH #1 SMP PREEMPT Fri Aug 17 02:34:50 UTC 2018 armv7l GNU/Linux
Big Grin Big Grin

Fedora != debian, then there might be differences to solve. Did you installed before ?

Hm, I was afraid this might be the only solution.  It won't upgrade with the normal process.

I've run CentOS for years and have begun using Fedora for projects that require newer software.  I've installed FedArm28 on the Pi 3B+ with no problems, but I need more capable hardware.  Prior to CentOS I'd run Debian for 18 years but it got too old and rarely had current software.

What are your settings for uBoot?
Reply
#4
Well, you should try first to swap the rootfs.
To be able to boot a different OS, it is required to recompile u-boot.
My procedure is this after getting the patches, but is advisable to read all thread.

If the u-boot compilation succeed, there should be to adjust the boot.scr on the way to point at valid kernel. I think Fedora might boot whether the packages are compiled for armV7. The key to make the OS is the u-boot and the specification on the dtb.
Even extlinux.conf is applicable for the chance.

So with this formula, the kernel will be a fully modular one, that permits module insertion at run time.
It it worth to say that is just experimental, so it is easy to stumble on some malfunctioning.

There could be a couple of issue to handle, but I lack of knowledge about the TBS hardware and software, to be up to arrange fixes.

All are invited to improve the project. That project is not just to have Archlinux installed, but I hope to widen the capabilities to boot for almost all distros, which are compiled for ARM suitable for Tinker Board and Tinker Board S.
[-] The following 1 user Likes Im4Tinker's post:
  • Quantum
Reply
#5
I've read all the thread and copied my Fed filesystem into Tinkerian's partition 2 (after formatting). I modified /boot/extlinux/extlinux.conf to point to a newer kernel, on the theory that it would use the kernel modules in the new filesystem, but that didn't boot. So I modified it back to zImage and then it did boot.

It failed midway though because I needed to make adjustments to fstab, so I fixed those and then it booted all the way. I'm assuming the modules for zImage are actually in rk3288-miniarm.dtb -- otherwise a 4.4 kernel could not use 4.17 modules.

Networking was unhappy with me assigning a HWADDRS so I commented that out and then got eth0. But wlan0 is nowhere to be found and iwconfig finds no device with wireless extensions.

# lspci presents me with:
pcilib: Cannot open /proc/bus/pci
lspci: Cannot find any working access method.
Reply
#6
Oh man, I've run Linux exclusively for 22 years and never have heard of u-boot or SPL. And I have to patch and compile them with experimental code? Why has Asus decided to half-ass it this way? It looks like a whole 'nother can of worms I have to learn.

I can't find to what I am supposed to apply these patches, to the u-boot source (wherever it is) or to the kernel, or to both.

TBH I have too many problems already. Maybe I have to return this Tinker Board. Armbian sux.
Reply
#7
(09-01-2018, 04:49 AM)Quantum Wrote: Oh man, I've run Linux exclusively for 22 years and never have heard of u-boot or SPL.  And I have to patch and compile them with experimental code?  Why has Asus decided to half-ass it this way?  It looks like a whole 'nother can of worms I have to learn.

I can't find to what I am supposed to apply these patches, to the u-boot source (wherever it is) or to the kernel, or to both.

TBH I have too many problems already.  Maybe I have to return this Tinker Board.  Armbian sux.

Things in ARM world are different than in boring and simple x86 world (or simple Raspberry Pi which is technically Videocore SoC with ARM cores). Here each chip family has virtually its own architecture. Almost. Each chip fancies his own u-boot, which is standard bootloader in the embedded world (we can simplify by saying this is BIOS + grub), and kernel, the own way of booting, the own way of using HW video acceleration etc. Some hardware might boot only on u-boot that is date back to 2014, 2012, ... since nobody ported it to the mainline. The same goes for the kernel. You have chip maker (Rockchip or hired 3rd party) who makes basic support and then board makers (ASUS or 3rd party ODM) work on their own kernel ... if they have resources for that. And they don't cooperate. Then you have a community, mainstream distros and various companies who work on the common mainstream Linux kernel ... which is a gigantic project from one man perspective. Pushing towards one ARM kernel, which is IMO years away.

Armbian is a player in this community which tries to set unique way of booting and operating, merge kernels at least on-chip base, use same kernel config, add same 3rd party drivers, fix as much bugs as possible while doing this, provide as many as possible features that are known to work in x86 world, adjust userspace for flash media and low memory situations, ... provide end-user support, documentation, build script, ready-made images. Free of charge. Mainstream distributions are years begin and will probably never level up this far. If Armbian sux for you, other experience will be only much worse. If you want to recompile whole Armbian, there is only one command ... which works with 99% certainty - we recompile it every day and ATM we are working on a major update, which means testing, testing and testing. It is also a good place to learn how a system is put together. From sources.

I personally never exclusively used Linux in my life but I used a few other more obscure Unix systems before Linus decided to start Linux project.

Quote:# lspci presents me with:
pcilib: Cannot open /proc/bus/pci
lspci: Cannot find any working access method.

Correct. There is no PCI bus on this hardware.
Armbian. Lightweight Debian Stretch or Ubuntu Bionic for Tinker Board.
Reply
#8
(08-31-2018, 05:18 PM)Quantum Wrote: I modified /boot/extlinux/extlinux.conf to point to a newer kernel,
I deeply doubt it will work. Well, I still doubt because I couldn't see anything on the ttyS2 during boot time. Probably there's no output correctly defined with linaro setup.

You may have FedArm working if you leave the first partition alone. The you should copy from TinkerOS-2.7 the /usr/lib/modules/4.4.103+ directory to the new installation and run depmod -a after you have booted the new installation. Or even better if you can start linaro and then chroot on the new installation to give that command. For the wifi, it should work in that way, with that kernel module.

The only drawback, you cannot update the kernel, which will be possible only with a compatible one from linaro and then update the few modules that are related to that kernel (which has most of the drivers compiled in) .

In this thread I uploaded a new u-boot and the direction to run Archlinux. It might load a different kernel, just configure the boot.scr to point to the kernel, or rename the one to be launched.
Today I update to the newest kernel Tongue Arch Linux 4.18.5-1-ARCH (ttyS2). I haven't try deeply, but I hope there's some little improvement.

(09-01-2018, 09:21 AM)igorpec Wrote: You have chip maker (Rockchip or hired 3rd party) who makes basic support and then board makers (ASUS or 3rd party ODM) work on their own kernel ... if they have resources for that. And they don't cooperate.

That's why there are at least three different device-tree files, which none makes the right job.
Reply
#9
Igor, thanks for the good overview. I understand this is free but I've standardized on Fedora/CentOS and have abandoned Debian for good reasons. (Failure of many advanced projects like Xen, etc) And I have many other non-Linux issues to deal with, without a whole new group of problems.

Im4, I'll try to understand your work. Yes Fed28 did boot when I didn't mess with part 1, although I didn't have wifi. Putting the 4.4 modules in part 2 makes sense, I'll do that if I can't make sense of your 4.18 work.
Reply
#10
(09-01-2018, 04:22 PM)Quantum Wrote: I'll do that if I can't make sense of your 4.18 work.

Wait a minute ! Smile
Those are two different options.

  • Use linaro kernel with its modules.  Therefore partition 1 untouched and kernel modules copied onto rootfs (part. 2).
  • Use my arrangement and try to implant FedArm into rootfs. Which has a different partition layout. May or may not need the vfat partition. Anyway the searching path is very same :
         > eMMC
         > SDcard
         > USB media
         > ethernet link and further directory containing the kernel and other stuffs used during boot.      But I disabled it, because seldom used.
       Along that searching it is included the extlinux.conf. I still have doubt and it is preferred to use    boot.scrWorth to say that FedArm should be armV7 compiled. So I don't have clear about the RPI3+ architecture, which you done for FedArm in there.
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)