Slackware - ARMThis forum is for the discussion of Slackware ARM.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
assemble a DTC package fixed cross-compilation issue for x86_64
Here are my updates:
* I removed my home-built vanilla dtc, and built it via your SlackBuild script
At this point I decided to keep my local modifications, and clone your most recent changes to a different directory, and work with it there. So my actions are now running on two parallel tracks.
In the directory with my local changes, and an older version of your git repo:
==============================================================================
* after installing your dtc version, and fixing the absolute path I used in dtc-version.sh, u-boot compiled successfully.
* after that the pinebook-pro kernel started compiling, which eventually failed due to the command mkimage (form u-boot-tools) missing
* after building u-boot-tools with your SlackBuild script, the kernel image was built successfully too
* finally the build failed when trying to patch u-boot-pinebook_pro, as the patches failed to apply
Code:
OBJCOPY lib/efi_loader/helloworld.efi
LD lib/built-in.o
LD u-boot
OBJCOPY u-boot-nodtb.bin
start=$(aarch64-linux-gnu-nm u-boot | grep __rel_dyn_start | cut -f 1 -d ' '); end=$(aarch64-linux-gnu-nm u-boot | grep __rel_dyn_end | cut -f 1 -d ' '); tools/relocate-rela u-boot-nodtb.bin 0x00200000 $start $end
make[2]: 'arch/arm/dts/rk3399-pinebook-pro.dtb' is up to date.
MKIMAGE u-boot.itb
u-boot.its:8.11-15.5: Warning (unit_address_vs_reg): /images/uboot@1: node has a unit name, but no reg property
u-boot.its:16.9-24.5: Warning (unit_address_vs_reg): /images/atf@1: node has a unit name, but no reg property
u-boot.its:25.9-32.5: Warning (unit_address_vs_reg): /images/atf@2: node has a unit name, but no reg property
u-boot.its:33.9-40.5: Warning (unit_address_vs_reg): /images/atf@3: node has a unit name, but no reg property
u-boot.its:41.9-46.5: Warning (unit_address_vs_reg): /images/fdt@1: node has a unit name, but no reg property
u-boot.its:51.12-56.5: Warning (unit_address_vs_reg): /configurations/config@1: node has a unit name, but no reg property
~/slackbuild/slackware_arm_build_kit/build/source/u-boot-pinebook_pro ~/slackbuild/slackware_arm_build_kit/build/source/u-boot-pinebook_pro
Image Type: Rockchip RK33 (SD/MMC) boot image
Data Size: 116736 bytes
1617+1 records in
1617+1 records out
827928 bytes (828 kB, 809 KiB) copied, 0.00369337 s, 224 MB/s
~/slackbuild/slackware_arm_build_kit/build/source/u-boot-pinebook_pro
~/slackbuild/slackware_arm_build_kit/build/source/linux-rk3399-next-pinebook_pro ~/slackbuild/slackware_arm_build_kit/build/source/u-boot-pinebook_pro
Reversed (or previously applied) patch detected! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file Documentation/admin-guide/kernel-parameters.txt.rej
Reversed (or previously applied) patch detected! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file Documentation/devicetree/bindings/usb/rockchip,dwc3.txt.rej
Reversed (or previously applied) patch detected! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file arch/arm64/Makefile.rej
Reversed (or previously applied) patch detected! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi.rej
Reversed (or previously applied) patch detected! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file arch/arm64/boot/dts/rockchip/Makefile.rej
Reversed (or previously applied) patch detected! Skipping patch.
15 out of 15 hunks ignored -- saving rejects to file arch/arm64/boot/dts/rockchip/rk3328-rock64.dts.rej
Reversed (or previously applied) patch detected! Skipping patch.
4 out of 4 hunks ignored -- saving rejects to file arch/arm64/boot/dts/rockchip/rk3328.dtsi.rej
Reversed (or previously applied) patch detected! Skipping patch.
16 out of 16 hunks ignored -- saving rejects to file arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts.rej
Reversed (or previously applied) patch detected! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file arch/arm64/boot/dts/rockchip/rk3399.dtsi.rej
Reversed (or previously applied) patch detected! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file arch/arm64/configs/defconfig.rej
Reversed (or previously applied) patch detected! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/cpufreq/cpufreq-dt-platdev.c.rej
Reversed (or previously applied) patch detected! Skipping patch.
3 out of 3 hunks ignored -- saving rejects to file drivers/mmc/core/mmc.c.rej
Reversed (or previously applied) patch detected! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/net/ethernet/stmicro/stmmac/stmmac_main.c.rej
Reversed (or previously applied) patch detected! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c.rej
Reversed (or previously applied) patch detected! Skipping patch.
3 out of 3 hunks ignored -- saving rejects to file drivers/net/phy/realtek.c.rej
Reversed (or previously applied) patch detected! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/of/Kconfig.rej
Reversed (or previously applied) patch detected! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/of/Makefile.rej
Reversed (or previously applied) patch detected! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/usb/storage/uas-detect.h.rej
Reversed (or previously applied) patch detected! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/usb/storage/unusual_uas.h.rej
Reversed (or previously applied) patch detected! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file include/linux/stmmac.h.rej
In the directory with your most recent changes:
===============================================
* Without any changes, your most recent vanilla build environment failed again at
Code:
|info| compiling u-boot-tools next-dev::
* Again the problem was that the environment was trying to compile the u-boot code with the native x86_64 compiler
* I yet again had to patch slackware_arm_build_kit/build/source/u-boot-tools/Makefile with
Code:
+CROSS_COMPILE = $(CROSS)
* But this worked, as the CROSS variable was now set up correctly
* So I got one step further, but this time the patching step of u-boot-tools failed like this:
* Without any changes, your most recent vanilla build environment failed again at
Code:
|info| compiling u-boot-tools next-dev::
* Again the problem was that the environment was trying to compile the u-boot code with the native x86_64 compiler
* I yet again had to patch slackware_arm_build_kit/build/source/u-boot-tools/Makefile with
u-boot-tools should be assembled exactly as the host system in which u-boot components are combined.
So, even though I managed to move a few steps forward, I'm stuck yet again.
regarding an error with patches, for some reason your source files are not reset to their original state.
just select clean from the menu (everything in build / {output, pkg, source} will be cleared)
regarding an error with patches, for some reason your source files are not reset to their original state.
just select clean from the menu (everything in build / {output, pkg, source} will be cleared)
I prefer not to clean my environment, because my local fixes/changes are lost when the environment is reset.
Either way, I did a clean and download run with build.sh, and then re-applied my fixes, but the build failed again at the same place like before: the patches to u-boot-tools did not apply:
Code:
HOSTLD tools/mkenvimage
HOSTLD tools/dumpimage
HOSTLD tools/mkimage
HOSTLD tools/fdtgrep
~/slackbuild/slackware_arm_build_kit-new/build/source/arm-trusted-firmware ~/slackbuild/slackware_arm_build_kit-new/build/source/u-boot-tools
Reversed (or previously applied) patch detected! Skipping patch.
3 out of 3 hunks ignored -- saving rejects to file plat/rockchip/common/params_setup.c.rej
On my own branch, I also did a make clean/download run, and then re-added my own modifications, and now it got past bulding the kernel image, but it now kind of seems stuck at
No disk activity, no measurable CPU usage. It just sits there...
Code:
user 25853 0.0 0.2 9760 5792 ? Ss Feb14 0:02 SCREEN
user 28171 0.0 0.1 7672 3920 pts/3 Ss Feb14 0:00 \_ /bin/bash
user 25936 0.0 0.2 8260 4480 pts/3 S+ Feb14 0:00 \_ /bin/bash ./build.sh
user 23688 0.0 0.2 13604 4260 pts/3 S+ Feb14 0:00 \_ make prepare
user 23968 0.0 0.1 12564 3364 pts/3 S+ Feb14 0:00 \_ make -f ./Makefile syncconfig
user 24127 0.0 0.2 13212 4068 pts/3 S+ Feb14 0:00 \_ make -f ./scripts/Makefile.build obj=scripts/kconfig syncconfig
user 24188 0.0 1.4 29488 28504 pts/3 S+ Feb14 0:00 \_ scripts/kconfig/conf --syncconfig Kconfig
When I ran strace on its PID, it was waiting in a "read(0," call.
I believe that it was waiting for user input, but its STDOUT was captured by the build script, and I did not get to read it. Maybe it was asking me a question like "make oldconfig" does...
BTW, is there a way to make the build process more verbose? Like "make V=99" in case of openwrt? I would welcome the possibility to see what is happening.
Luckily I could find out from the build log what was happening:
So it was asking me questions about the kernel configuration, but I couldn't answer anything as I was not seeing that there was a question...
After pressing CTRL+d the compilation resumed, and finally failed with:
Well, I tried again couple of times. As it seems, I have to open another terminal session and "tail -f" the build.log file to see the questions.
What I see in it is the following:
Code:
Image Name:
Created: Sat Feb 15 06:55:38 2020
Image Type: ARM Linux Script (uncompressed)
Data Size: 1290 Bytes = 1.26 KiB = 0.00 MiB
Load Address: 00000000
Entry Point: 00000000
Contents:
Image 0: 1282 Bytes = 1.25 KiB = 0.00 MiB
CLEAN certs
CLEAN drivers/firmware/efi/libstub
CLEAN drivers/scsi
CLEAN drivers/tty/vt
CLEAN drivers/video/logo
CLEAN kernel
CLEAN lib/raid6
CLEAN lib
CLEAN net/bpfilter
CLEAN net/wireless
CLEAN usr/include
CLEAN usr
CLEAN modules.builtin.modinfo
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/confdata.o
HOSTCC scripts/kconfig/expr.o
LEX scripts/kconfig/lexer.lex.c
YACC scripts/kconfig/parser.tab.[ch]
HOSTCC scripts/kconfig/lexer.lex.o
HOSTCC scripts/kconfig/parser.tab.o
HOSTCC scripts/kconfig/preprocess.o
HOSTCC scripts/kconfig/symbol.o
HOSTCC scripts/kconfig/util.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --syncconfig Kconfig
*
* Restart config...
*
*
* General setup
*
Compile also drivers which will not load (COMPILE_TEST) [N/y/?] n
Local version - append to kernel release (LOCALVERSION) []
Automatically append version information to the version string (LOCALVERSION_AUTO) [N/y/?] n
Build ID Salt (BUILD_SALT) []
Kernel compression mode
> 1. Gzip (KERNEL_GZIP) (NEW)
2. Bzip2 (KERNEL_BZIP2) (NEW)
3. LZMA (KERNEL_LZMA) (NEW)
4. XZ (KERNEL_XZ) (NEW)
5. LZO (KERNEL_LZO) (NEW)
6. LZ4 (KERNEL_LZ4) (NEW)
choice[1-6?]:
Based on the questions, it seems as if I would be going through an x86_64 (not aarch64!) kernel "oldconfig" with some existing/partial configuration already in place.
I again went ahead and pressed Ctrl+d to go with the defaults. (Hopefully it won't be used anywhere.) But again is this really a necessary step?
Also, do you have any plans about a verbose mode perhaps?
Quote:
Originally Posted by sndwvs
fixed
Thanks!
Quote:
Originally Posted by sndwvs
build.sh should be run from root or sudo
Okay, this was again something I did not know about.
As for my latest attempts:
* on my own branch, I managed compile and build the installer image, however the build of the XFCE image failed:
After investigating a bit, it seems that for some reason this Makefile is not getting the right CC variable at this point.
I edited build/source/linux-rk3399-next-pinebook_pro/arch/arm64/Makefile to include the following line at the beginning:
So it it clearly visible that at some point the CC variable loses its cross-compilation prefix, and exactly the same time the toolchain also changes at from 5.5.0 to 7.2.1 for some reason.
The first time it changes from 5.5.0 to 7.2.1 is right here:
I re-tried creating the xfce image on the branch with my local changes. This time it failed at the ffmpeg package:
Code:
empty download package l/ffmpeg
In the meantime I managed to compile the base image with your latest git repo state, I just needed to modify:
- the Makefile of u-boot-tools
- the dtc-version script of u-boot-pinebook_pro
And I still have to determine what was the crucial change I did to
- build_packages.sh
- compilation.sh
that made all the difference.
I will get back to you tomorrow with the list of my changes.
Last edited by wowbaggerHU; 02-20-2020 at 12:11 PM.
Upon further investigation I found that this happened when build.sh tried downloading the 'extra' packages, because when the URL was set in configuration.sh the ARCH variable contained x86_64, and that is a non-existent URL.
The ARCH variable is used in a slightly funny way here. When I start build.sh, I have to set it to x86_64 for the cross compiling to work, but then, when the slarm64 packages are downloaded, the packages are saved into the $ARCH directory, which in fact should be aarch64. This is confusing.
And ARCH is used in configuration.sh similarly funnily when creating the extra URL.
I don't know how it could be done right, that would work across all platforms. The best I can do is to work around things, and show you the diffs.
So during the weekend I managed to build an xfce-based image too.
The patches necessary are available here: https://gitlab.com/snippets/1944229
They have to be applied on top of commit 239f92df0ed2619d3beb6d92d48d8659e0385c57 of the main slackware_arm_build_kit project.
The kernel doesn't need the old gcc version to compile successfully. It works fine with the new one.
I have also tried using the images built by the script, but unfortunately neither of my xfce image, nor the base image slarm64-current-aarch64-base-rootfs-20200118-5.5.2-pinebook_pro-build-20200207.img.xz from http://dl.fail.pp.ua/slackware/images/pinebook_pro/ does work
I put in the micro SD card, and start the machine but nothing happens, and the screen stays dark too. When I remove the SD card, it will happily boot the installed OS in the following reboot.
It would be interesting to understand at what stage everything stops, while it looks like u-boot, or maybe earlier.
Yes, I absolutely agree. However, at the moment I don't have a serial cable that I could use.
I have already ordered one, but it will take a few weeks to arrive. I will keep you updated with any news as things happen.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
