longsleep / build-pine64-image

Pine64 Linux build scripts, tools and instructions
MIT License
235 stars 126 forks source link

Custom build Hangs after "Started Update UTMP about System Runlevel Changes." #27

Closed adomenech73 closed 8 years ago

adomenech73 commented 8 years ago

I followed instructions to build BSP kernel image and kind of understood the process, but probably missed something because on boot it gets:

[ TIME ] Timed out waiting for device dev-ttyS0.device. [DEPEND] Dependency failed for Serial Getty on ttyS0.

And hangs, just after the title message, just five lines after

Can anyone give any advice?

Thanks

adomenech73 commented 8 years ago

I realised that it also happened to me, with running sdcards where I try to recreate the rootfs using make_rootfs.sh script

longsleep commented 8 years ago

No idea about that one. Please give some more details what you did.

adomenech73 commented 8 years ago

Yes of course. I mean that if I try to burn directly the downloaded released image on a sdcard like

xzcat xenial-pine64-bspkernel-20160716-1.img.xz|pv|sudo dd of=/dev/mmcblk0 bs=1M oflag=sync

and then boot the pine64 with this image, everything works, just fine. But I also tried to compile the kernel bsp image before making the image like

# Download general repo
git clone https://github.com/longsleep/build-pine64-image
cd build-pine64-image/
# Download linux kernel
git clone --depth 1 --branch pine64-hacks-1.2 --single-branch https://github.com/longsleep/linux-pine64.git linux-pine64
cd linux-pine64/
# configure
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- sun50iw1p1smp_linux_defconfig
# clean
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- LOCALVERSION= clean
# compile kernel
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- LOCALVERSION= Image
# compile modules
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- LOCALVERSION= modules

# compile mali drivers
cd modules/gpu/
 LICHEE_KDIR=$(pwd)/../.. ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- LICHEE_PLATFORM=Pine64 make build
cd ../..
# install busybox
git clone --depth 1 --branch 1_24_stable --single-branch git://git.busybox.net/busybox busybox
cd busybox/
## copy busybox config
cp ../kernel/pine64_config_busybox .config
## compile busybox
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j4 oldconfig
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j4
cd ../kernel

## ./install_kernel.sh -
# create initrd
./make_initrd.sh
# create kernel tarball 
./make_kernel_tarball.sh ./ ../linux-pine64/
# move results to build dir
 mkdir ../build
mv initrd.gz ../build/
mv linux-pine64-3.10.102-1.tar.xz ../build/
# Download u-boot
cd ../
git clone --depth 1 --branch pine64-hacks --single-branch https://github.com/longsleep/u-boot-pine64.git u-boot-pine64
## compile u-boot
cd u-boot-pine64/
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- sun50iw1p1_config
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
# download arm-trusted-firmware bsp
cd ..
git clone --branch allwinner-a64-bsp --single-branch https://github.com/longsleep/arm-trusted-firmware.git arm-trusted-firmware-pine64
# compile arm-trusted-firmware
cd arm-trusted-firmware-pine64/
make clean
make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- PLATFORM=sun50iw1p1 bl31

# compile sunxi pack tools
cd ..
git clone https://github.com/longsleep/sunxi-pack-tools.git sunxi-pack-tools
make -C sunxi-pack-tools

# package complete uboot
cd u-boot-postprocess/
./u-boot-postprocess.sh 

# copy dtb
cd ..
cp ./build/u-boot-with-dtb.bin simpleimage/
cd simpleimage/

# create image
./make_simpleimage.sh pine64_2048.img 2048 ../build/linux-pine64-3.10.102-2.tar.xz 

# record image on sdcard
cat ./pine64_2048.img|pv|sudo dd of=/dev/mmcblk0 bs=1M oflag=sync 
sudo sync

# mount and generate rootfs
sudo ./make_rootfs.sh /media/albert/rootfs/ ../linux-pine64/ xenial

cd ../kernel
# Install kernel modules
sudo ./install_kernel_modules.sh /media/albert/rootfs/ ../linux-pine64
# Install kernel 
cp ../build/initrd.gz ./
sudo ./install_kernel.sh /media/albert/BOOT/ ../linux-pine64

sudo sync

And try to boot with the resulting image, Initially the boot process seems to start fine, but during the the kernel modules loading. I get this error:

[ TIME ] Timed out waiting for device dev-ttyS0.device.
[DEPEND] Dependency failed for Serial Getty on ttyS0.

The whole system start up, hangs in that point.

It seems that it couldn't initialize ttyS0 device, but I've got no previous warnings or errors. I followed README indication to compile and probably I missed something obvious during the process.

Thanks for the attention and the project

adomenech73 commented 8 years ago

I repeated all the process, this time with mainline kernel and I've got exactly the same result. I'm using make gcc version:

gcc (Ubuntu 5.4.1-2ubuntu1~16.04) 5.4.1 20160904

as pointed in armhf, and I've checked CONFIG_FHANDLE it's set in .config as recommended on some posts to be related with systemd

I'm probably doing something wrong when I provision the card, after the image is burned on.

I'm using this sequence:

./make_rootfs.sh /media/albert/rootfs/ ../linux-a64/ xenial
./install_kernel_headers.sh /media/albert/rootfs/ ../linux-a64
./install_kernel_modules.sh /media/albert/rootfs/ ../linux-a64/
sync

Disconnect the sd card and boot pine with it.

Do I have to do any operation in order to prepare the filesystem after it's writed to the card? I've seen a second-phase script on rootfs partition, and I'm guessing

adomenech73 commented 8 years ago

I think that in this thread: Pine64 forum patrickhwood was talking about the same problem a time ago. I repeated the operation this time with a clean reinstalled laptop to be sure nothing in my config was messing arround.

I tried the solution he propose about creating a /etc/init/ttyS0.conf script, but always with same result.

[ FAIL ] A start job is running for dev-ttyS0.device  

Other thing that I observed is that when I umount the sd card the ttyS0 device doesn't exist on /dev

Can it be something wrong with uEnv.txt console line? or it has nothing related about? May I have to create /dev/ttyS0 with mknod in some way?

adomenech73 commented 8 years ago

I can say now, that it must be specific problem with newer kernels an xenial rootfs, (Systemd stuff probably) just re-provisioned with debian rootfs, and everything goes fine. Not exactly what I wanted, but fair enough for me