PiotrO

Hi, I'm trying to get working sources compiled mainline 5.0.5 on beelink a1 rk3328. Kernel boots fine but I have following issue with eth (see attached png). Kernel config is like this: https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-5.0/files/linux-5.0-arm64-armv8.config Can somebody hint me: is this issue of 5.0.5 mainline or rather something is missing in kernel config or i.e. lacking of required kernel patch?

By accident I discover that issue events_freezable mmc_rescan is 4.19 GA regression compared to 4.19-rc4 as I don't have this in 4.19-rc4. Need to look at kernel sources. Any pointers to narrow such sources inspection?

I'm building my own kernel by patching mainline 4.19.0 Probably diff on my kernel vs. balbes150 will give hint - but maybe balbes150 has quick idea here?

Guys, Finally I have working (and quite understand) booting on my s905w with my full control on software used/configured. My system is working enough to start exploring GLES (via ARM mail blobs) and hw video decode (v4l2 m2m). Huge thx for Your really helpful support! Just quick Q: Has anybody have this in kernel log (in every 120sec)? [ 242.654622] INFO: task kworker/2:1:35 blocked for more than 120 seconds. [ 242.655686] Not tainted 4.19.0 #1 [ 242.659570] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 242.667272] kworker/2:1 D 0 35 2 0x00000028 [ 242.672714] Workqueue: events_freezable mmc_rescan [ 242.677434] Call trace: [ 242.679908] __switch_to+0x94/0xd8 [ 242.683224] __schedule+0x1e4/0x620 [ 242.686677] schedule+0x38/0xa0 [ 242.689761] schedule_timeout+0x1f4/0x378 [ 242.693761] wait_for_common+0xb8/0x170 [ 242.697537] wait_for_completion+0x14/0x20 [ 242.701635] mmc_wait_for_req_done+0x28/0x170 [ 242.705950] mmc_wait_for_req+0x80/0xf0 [ 242.709705] mmc_send_tuning+0x120/0x1d8 [ 242.713580] meson_mmc_execute_tuning+0x68/0x228 [ 242.718194] mmc_execute_tuning+0x60/0xa0 [ 242.722120] mmc_init_card+0x8c4/0x19d0 [ 242.725922] mmc_attach_mmc+0xc0/0x180 [ 242.729658] mmc_rescan+0x300/0x3d8 [ 242.733075] process_one_work+0x1e8/0x340 [ 242.737035] worker_thread+0x40/0x460 [ 242.740700] kthread+0x128/0x130 [ 242.743854] ret_from_fork+0x10/0x1c I don't have this with balbes150 kernel - so there must be something balbes150 add to his kernel and I'm missing....

Guys, I think we need to distiguish booting from sd and _unattended_ booting from sd. In case of my hw (tx3-mini) I think unattended boot from sd is NOT possible without erasing[modifying] eMMC bootloader. I think so as IPL by default is passing control to eMMC. So if we want unattended boot from SD - we MUST: 1\ change eMMC content 2\ modify IPL As IPL is in ROM (I think) - only option 1\ is choice. Reasonably written IPL should have fall-back to SD[USB] if SPL from eMMC fails (i.e. for case when flash ageing leading to data rot). In such case IPL should offer recovery by booting from SD and refresh eMMC SPL. So I agree with initial @jock answer as IMHO his intention was to describe what needs t be done to have tv-box _unattended_ boot from sd

Thx for Your replay. Is there somewhere place where we can see mods/patches You applied to Your kernel vs. mainline? It is good practice to publish code changes as only by this community have nice software with quick improvements achieved by collaboration and learning from code changes... BTW: I managed to have working system also for Elyotna kernel (https://github.com/Elyotna/linux). Difference is lack of any alsa dev while I have it with Your kernel. It will be good to see what You changed in code to get alsa in Your kernel. br

Fantastic!. It boots with mkimage procedure like on wiki. I'm wonder why Armbian_5.64_Aml-s9xxx_Debian_stretch_default_4.19.0-rc7_20181019 sd image: -has booti instead of bootm and boots OK -I have to change booti to bootm to have working boot on kernel used to build this Armbian_5.64_Aml-s9xxx_Debian_stretch_default_4.19.0-rc7_20181019 Also may also You learn me pls: -what makimage command is doing? -what 0x1080000 address in mkimage means? -why u-boot script needs to declare kernel_addr as "0x11000000"? thx so much for meaningful help here! Next I'll try Elyotna kernel (with v4l2 m2m), AmLogic mainline (khilman branch) and maybe 4.20 mainline + patches from armbian git. Have You any experience with those kernels? Any pointers?

Thx so much for this info balbes150! One Q: mkimage command uses address 0x1080000 while in armbian scripts I see: cat s905_autoscript.cmd setenv env_addr "0x10400000" setenv kernel_addr "0x11000000" setenv initrd_addr "0x13000000" setenv boot_start booti ${kernel_addr} ${initrd_addr} ${dtb_mem_addr} Which one is correct one?

Ok, I installed and tried to build multiple configurations to get kernel having "....s9xxx...." in filename. No go. grep on build system shows no 's9xxx' string - so with current armbian git building package I'm using as reference is not possible (I think so). Have You idea how I can generate something close as possible to: Armbian_5.64_Aml-s9xxx_Debian_stretch_default_4.19.0-rc7_20181019

oh - honestly speaking multiple hours needed to learn how to build full armbian just to learn from where config-4.19.0-rc7-aml-s9xxx kernel sources are pulled, how they are patched and how armbian creates vmlinuz-4.19.0-rc7-aml-s9xxx image is a bit waste of time for me. Simply I want to spent this time to play rather with mali 3D, hw accelerator, etc (mesa-lima; v4l2-m2m; etc). I'm referring to vmlinuz-4.19.0-rc7-aml-s9xxx as this kernel image is practically single component from armbian I need to get working full my system. Can somebody, fluent in armbian, provide me info: -what exact kernel sources were used to build Armbian_5.64_Aml-s9xxx_Debian_stretch_default_4.19.0-rc7_20181019 -how exactly vmlinuz-4.19.0-rc7-aml-s9xxx image is build by armbian build system? I know asking above consumes time - but for fluent armbian developer answering above is matter of minutes while for me it is rather hours to learn, build, reverse engineer etc.... thx in advance!

Fantastic as we are now the same page now :-) Thx so much for help!. I've done edit in 905_autoscript (booti 2nd param is set to '-') to ask booting without initrd. Also in uEnv.ini I declared /dev/mmcblk0p2 as my rootfs because we have no initrd so it is very minimal system. Put my rootfs on 2nd part of SD card I can boot and have practically all working!!! But currently it only works with kernel image from armbian :-( Using myself compiled kernel from linux-amlogic git at 4.19-rc7 level with config taken form armbian SD card boot partition (config-4.19.0-rc7-aml-s9xxx) file - boot process just hangs. So something wrong is with my kernel image preparation (or compile). My procedure of kernel building works Ok for x86, armv7 (tested on rpi2) and arrch64 (tested on rpi3) So armbian does something differently than me with kernel image.... So Q is: are there any special steeps done in armbian with kernel image after kernel compilation? I mean i.e. things like suggested here: http://linux-meson.com/doku.php for 64-bit SoCs (GXBB / S905 or newer)? pls advice

Forgive me but - I'm a bit confused... You wrote: aml_autoscript content: defenv setenv bootcmd "run start_autoscript; run storeboot;" setenv start_autoscript "if usb start ; then run start_usb_autoscript; fi; if mmcinfo; then run start_mmc_autoscript; fi; run start_emmc_autoscript;" setenv start_emmc_autoscript "if fatload mmc 1 1020000 emmc_autoscript; then autoscr 1020000; fi;" setenv start_mmc_autoscript "if fatload mmc 0 1020000 s905_autoscript; then autoscr 1020000; fi;" setenv start_usb_autoscript "if fatload usb 0 1020000 s905_autoscript; then autoscr 1020000; fi; if fatload usb 1 1020000 s905_autoscript; then autoscr 1020000; fi; if fatload usb 2 1020000 s905_autoscript; then autoscr 1020000; fi; if fatload usb 3 1020000 s905_autoscript; then autoscr 1020000; fi;" setenv upgrade_step "2" saveenv sleep 1 reboot this looks me strange as something what can boot linux. No any "booti" command, but "reboot" command! How such script can boot linux? on the other hand I see in s905_autoscript I see: setenv env_addr "0x10400000" setenv kernel_addr "0x11000000" setenv initrd_addr "0x13000000" setenv boot_start booti ${kernel_addr} ${initrd_addr} ${dtb_mem_addr} if fatload mmc 0 ${kernel_addr} zImage; then if fatload mmc 0 ${initrd_addr} uInitrd; then if fatload mmc 0 ${env_addr} uEnv.ini; then env import -t ${env_addr} ${filesize};fi; if fatload mmc 0 ${dtb_mem_addr} ${dtb_name}; then run boot_start; else store dtb read ${dtb_mem_addr}; run boot_start;fi;fi;fi; if fatload usb 0 ${kernel_addr} zImage; then if fatload usb 0 ${initrd_addr} uInitrd; then if fatload usb 0 ${env_addr} uEnv.ini; then env import -t ${env_addr} ${filesize};fi; if fatload usb 0 ${dtb_mem_addr} ${dtb_name}; then run boot_start; else store dtb read ${dtb_mem_addr}; run boot_start;fi;fi;fi; if fatload usb 1 ${kernel_addr} zImage; then if fatload usb 1 ${initrd_addr} uInitrd; then if fatload usb 1 ${env_addr} uEnv.ini; then env import -t ${env_addr} ${filesize};fi; if fatload usb 1 ${dtb_mem_addr} ${dtb_name}; then run boot_start; else store dtb read ${dtb_mem_addr}; run boot_start;fi;fi;fi; if fatload usb 2 ${kernel_addr} zImage; then if fatload usb 2 ${initrd_addr} uInitrd; then if fatload usb 2 ${env_addr} uEnv.ini; then env import -t ${env_addr} ${filesize};fi; if fatload usb 2 ${dtb_mem_addr} ${dtb_name}; then run boot_start; else store dtb read ${dtb_mem_addr}; run boot_start;fi;fi;fi; if fatload usb 3 ${kernel_addr} zImage; then if fatload usb 3 ${initrd_addr} uInitrd; then if fatload usb 3 ${env_addr} uEnv.ini; then env import -t ${env_addr} ${filesize};fi; if fatload usb 3 ${dtb_mem_addr} ${dtb_name}; then run boot_start; else store dtb read ${dtb_mem_addr}; run boot_start;fi;fi;fi; 'boot_start' has here "booti" IMHO this script can boot linux contrary to aml_autoscript... I think in Your description You swapped names of: aml_autoscript with s905_autoscript and vice versa (probably just typo) pls confirm

Yes. I have armbian running on tx3. I was trying to play with scripts in armbian boot partition. Without success.... As boot loader is enabling hdmi quite late on boot - I'm blind to see where issue is as boot hangs on phase with not yet enabled hdmi. (sure I can solder tty console and see where boot sequence fails - but first i decided to ask armbian ppl as armbian boots OK on tx3....) 1.first thing I want to understand: is successfully booted armbian on tx3 hw booting via: a\ sd card u-boot, or b\ emmc amlogic u-boot flashed and used by factory flashed android? If 1.a is true, then where u-boot is stored on SD card? a\ is it embedded in first sectors of SD card (via dd if=... of=.... bs=1 count=444 etc) b\ it is file on sd card /boot partition if 1.a is true: -how should I embeed it on sd card? if 1.b is true: -which file it is? -what boot script it uses? 2. on sd card I see multiple u-boot like scripts: which one is used by boot loader on tx3 when tx3 is booting armbian from sd card? a\ emmc_autoscript b\ s905_autoscript c\ aml_autoscript 3. What is uEnv.ini for? (is this script for amlogic u-boot?) Generally: method You suggesting for replacing armbian kernel image to mine was my first thought. But armbian uses also initrd. I'm not. So I need somehow reflect this fact - but I don't know how... btw: it is nice that You are trying help me here!

I'm not sure but You probably mixing Broadcom Video Core 4 (VC4) with SoC. 2835/2837 are SoCs - not graphic chips. Mentioned by you graphic chip is _part_ of 2835 not itself. CPU in 2835 is ARM11J6JZF-S (ARM11 Family), 32bit RISC Rest of things packed in 2835 SoC: BCM2835-ARM-Peripherals.pdf If You are interested for more details - here You go: 2835 details

argh - I wasn't clear enough :-( I don't want to build armbian. I already have my OS (https://github.com/warpme/minimyth2). MiniMyth2 already supporting x86 arch with 1560 out-of-box supported gfx cards as zero-touch provisioning appliance via network boot. It also fully supports armv7 and arch64. Both arm architectures are already working well on broadcom 2835/2837 (rpi2/rpi3) For ARM builds, I managed boot with mainline u-boot/kernel. It was quite easy for me as rpi has quite nicely designed u-boot support as 2-stage boot loader. For s905 things are not looking so nicely (at least for me). Thats why instead of time-consuming reverse engineering how armbian does this - I decided just to ask more clever ppl here :-p Lets look: for rpi I'm using following u-boot script: part uuid ${devtype} ${devnum}:2 uuid setenv bootargs cma=256MB console=ttyS1,115200 console=tty0 root=PARTUUID=${uuid} rw rootwait smsc95xx.macaddr="${usbethaddr}" if load ${devtype} ${devnum}:${bootpart} ${kernel_addr_r} /Image; then if load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} /dtbs/${fdtfile}; then if load ${devtype} ${devnum}:${bootpart} ${ramdisk_addr_r} /initramfs-linux.img; then booti ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}; else booti ${kernel_addr_r} - ${fdt_addr_r}; fi; fi; fi It allows me to boot fully working rpi3 with mainline u-boot/kernel. MiniMyth2 is NOT using any initrd. My cross-build system producing: kernel image, dtbs files, rpi configured/compiled u-boot and archive of rootfs. I'm preparing SD card in following way: pat1: FAT part2: ext4 On part1 I'm putting: kernel Image; dtb files; u-boot (as 2nd-stage boot loader). 1st-stage boot loader files are on this part and are taken from rpi git. On par2 I'm unpacking all rootfs files. All this works very well for rpi. So my Q is: How I should organise this for s905? (hw I have is tx3-mini) thx in advance!