Jump to content

s905w boot process?


PiotrO

Recommended Posts

Dears,

 

Can somebody help me to learn how boot process ongoing on s905w (i.e. tx3-mini)?

 

I want to add support for s905 in my project (basically it is build from scratch just enough os for mythtv).

My target is to use as much as possible mainline kernel/u-boot/v4l2-m2m etc.

So how should I organise sw/scripts to allow booting mainline kernel on s905w?

 

thx in advance!

 

   

Link to comment
Share on other sites

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!

 

Link to comment
Share on other sites

25 minutes ago, PiotrO said:

broadcom 2835/2837 (rpi2/rpi3)

is not ARM. This is a Broadcom Graphic Chip that starts and controls ARM cores.  So, expect some differences - when you enter the realARMworld.

 

Link to comment
Share on other sites

3 hours ago, Tido said:

is not ARM. This is a Broadcom Graphic Chip that starts and controls ARM cores.  So, expect some differences - when you enter the realARMworld.

 

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

Link to comment
Share on other sites

Did you boot armbian on tx3? It is simple, just download image and look at a scripts. Or just replace kernel with your kernel image and edit line where is rootfs (in file uenv.ini for old builds, not sure for mainline).
Supereasy, just try and it will boot. If kernel supports cpus ;)

7 hours ago, PiotrO said:
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.
 

part uuid ${devtype} ${devnum}:2 uuidsetenv 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
 


 
So my Q is:
How I should organise this for s905?
(hw I have is tx3-mini)     
 
thx in advance!
 

 


Sent from my Redmi Note 4 using Tapatalk
 

 

Edited by Tido
shortened quote
Link to comment
Share on other sites

3 minutes ago, zogu said:

Did you boot armbian on tx3? It is simple, just download image and look at a scripts. Or just replace kernel with your kernel image and edit line where is rootfs (in file uenv.ini for old builds, not sure for mainline).
Supereasy, just try and it will boot. If kernel supports cpus

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!

 

Link to comment
Share on other sites

12 hours ago, PiotrO said:

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:

 

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...

 

As far as I know, you're running a customized armbian which does the boot in a different way due to the fact that tvbox have u-boot in their eMMC: the SoC first checks the eMMC and, if it finds a valid boot loader, starts from there. The best way to force the SoC to boot from an sdcard is to zero-fill the first sectors of the eMMC: the SoC is not able to find a valid bootloader on eMMC and will then try to boot from sdcard. I don't know the usage of the scripts you mentioned at point 2 because they are not part of armbian.

 

The boot process on amlogic boards begins loading a binary beginning at the second sector of the eMMC/sdcard. The binary is an assembling of amlogic blobs (clock and ram initialization) and u-boot.

In your actual condition, u-boot scripts on eMMC have been modified (via u-boot environment variables) to first check the SDcard for a valid kernel + initramfs + device tree combination. In summary what happens on your tv box is this:

  1. You turn on the board
  2. The SoC checks for a bootloader on eMMC, finds it and boots from eMMC
  3. Amlogic binary blobs are read from eMMC. They initialize the clock, ram and other low level things.
  4. The legacy amlogic u-boot is started from eMMC
  5. U-boot initializes its own things (USB, SDcard, etc...) and reads the "environment" variables from a sector of the eMMC. The boot scripts are part of the environment variables: once they are altered in the right way, they first check the SDcard for a boot descriptor
  6. U-boot finds the descriptor on the ext4 partition of the sdcard (it looks for uEnv.ini or extlinux.conf somewhere in /boot directory of the first partition)
  7. U-boot loads the kernel + initramfs + device tree pointed by the descriptor in RAM and transfer control to the kernel

If you zero-fill your eMMC, the process changes from step 2 onwards: after a failed attempt to start a bootloader from the eMMC, the SoC queries the sdcard and boots from there.

The boot process of amlogic is a bit involved due to the binary blobs which, as far as I know, must be built using the amlogic legacy u-boot source code and tuned for your specific hardware (ddr frequency and size, mostly) and debugging without a serial attached to the board can be really hard. Once you get the binary blobs, you can use them to build a pure vanilla armbian which boots mainline u-boot from sdcard

Edited by Tido
shortened quote, unnecessary long on mobile devices
Link to comment
Share on other sites

Bootloader is in internal memory, there is no bootloader on sdcard. S905_scriptwhatever is used only to change environment and it is used once, before first boot.
Aml_autoscript boots linux. You have separate lines for sdcard, usb and maybe something else. This file you have to edit to remove initrd. Also this file calls uenv.ini where is boot command similar to grub or lilo boot commands.
After editing aml_autoscript you must covert it using
mkimage -A arm64 -T script -O linux -d name.txt name.scr

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!
 


Sent from my Redmi Note 4 using Tapatalk

Link to comment
Share on other sites

Forgive me but - I'm a bit confused...

 

You wrote:

Цитата

Aml_autoscript boots linux. You have separate lines for sdcard, usb and maybe something else. This file you have to edit to remove initrd. Also this file calls uenv.ini where is boot command similar to grub or lilo boot commands.

 

aml_autoscript content:

 

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:

 

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

 

Link to comment
Share on other sites

On 11/10/2018 at 2:05 PM, zogu said:

Yes, yes i swap, i'm typing from my phone i will not have box nor pc till Tuesday :)

Sent from my Redmi Note 4 using Tapatalk
 

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

 

   

 

 

Link to comment
Share on other sites

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!

 

Link to comment
Share on other sites

In build script you can choose to compile only kernel.
Only time consuming thing is to wait until scripts download 6 different toolchain. If you have fast internet it is not a problem. Build script is adopted for ubuntu, but in general.sh is written how to override this.

Sent from my Redmi Note 4 using Tapatalk

Link to comment
Share on other sites

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

Link to comment
Share on other sites

30 minutes ago, PiotrO said:

Which one is correct one? 

Both addresses are correct. But each is used for its task (function).

 

On 11/10/2018 at 3:36 AM, jock said:

The best way to force the SoC to boot from an sdcard is to zero-fill the first sectors of the eMMC: the SoC is not able to find a valid bootloader on eMMC and will then try to boot from sdcard. I don't know the usage of the scripts you mentioned at point 2 because they are not part of armbian.

1. It is very bad advice - to destroy regular u-boot on TV box. You run the risk of getting a brick that will have to be restored. If the user is lucky and has the necessary firmware files for recovery, cable, software and skills for this, he will be able to recover.

2. Since when are scripts not part of Armbian ?

 

On 11/10/2018 at 3:36 AM, jock said:

Once you get the binary blobs, you can use them to build a pure vanilla armbian which boots mainline u-boot from sdcard 

I really want to look at the source code (build environment) "pure vanilla Armbian" for TV boxes.

Link to comment
Share on other sites

9 hours ago, balbes150 said:

Both addresses are correct. But each is used for its task (function).

 

 

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?

 

Link to comment
Share on other sites

11 hours ago, balbes150 said:

1. It is very bad advice - to destroy regular u-boot on TV box. You run the risk of getting a brick that will have to be restored. If the user is lucky and has the necessary firmware files for recovery, cable, software and skills for this, he will be able to recover.

2. Since when are scripts not part of Armbian ?

1. Never said the user has to erase the regular u-boot on TV box. Just said that the best way (the only way, AFAIK) to boot u-boot (the "bootloader") from sdcard is to erase the first sectors of the eMMC. If you have another method, please post it because I'm very interested.

2. Read better.

 

11 hours ago, balbes150 said:

I really want to look at the source code (build environment) "pure vanilla Armbian" for TV boxes.

You can: https://github.com/paolosabatino/armbian-build/tree/mxq-s905-v20

Link to comment
Share on other sites

Erasing bootloader on amlogic destroy board, this is for rockchip, not for amlogic.
Maybe i'm wrong.

On topic, great it boots finally. I think that balbes150 kernel has full v4l2 m2m support, it is definitely best kernel for tv boxes because it support so many devices.

Sent from my Redmi Note 4 using Tapatalk
 

Link to comment
Share on other sites

6 hours ago, balbes150 said:

Because I use in my source code two small patches that fix this problem and allow you to run the kernel without processing the utility "mkimage" on all TV boxes with a regular u-boot.

 

All kernel versions from my builds have a fix and can work with the "booti"command.

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

 

 

Link to comment
Share on other sites

3 hours ago, balbes150 said:

It's funny. From the beginning you declared your GIT "pure vanilla Armbian" for TV boxes, and after you were informed about errors in it, you hurried to change it and ask a question,"what errors". But did not answer an important (for users) question, how do you propose to run your version of the images on TV boxes ..... :)

 

https://github.com/paolosabatino/armbian-build/commit/3299439630ed68461c791a2f2281684940f08910

I truly don't understand what you mean: that's a merge from master I made yesterday to update the project to latest armbian mainline bits. Keeping the repo aligned with mainline armbian, what's wrong with that?

About the usage instructions, just compile the armbian the normal way (there will be a new mxq-s905-v20 board to choose) and burn the output image onto an sdcard.

Again: to let the tvbox boot from the sdcard, eMMC must be erased.

Link to comment
Share on other sites

47 minutes ago, jock said:

Again: to let the tvbox boot from the sdcard, eMMC must be erased.

I booted so many times my 3 tv boxes from sdcard and never had to erase eMMC.  I'm still not sure even is it safe.

Even in pdf which you pointed, I can't  find where is written to have to erase flash, there are just few u-boot commands:

5. If there's some old data on the flash, you might wish to erase them all  (recommendation, but just for data)

# store init 3 (u-boot command)

# reset // now the system starts from sd card (u-boot command)

Maybe i have some special tv-boxes, i bought the cheapest one from Ali and GB.

 

Link to comment
Share on other sites

1 hour ago, zogu said:

I booted so many times my 3 tv boxes from sdcard and never had to erase eMMC.  I'm still not sure even is it safe.

Even in pdf which you pointed, I can't  find where is written to have to erase flash, there are just few u-boot commands:

5. If there's some old data on the flash, you might wish to erase them all  (recommendation, but just for data)

# store init 3 (u-boot command)

# reset // now the system starts from sd card (u-boot command)

Maybe i have some special tv-boxes, i bought the cheapest one from Ali and GB.

Well my box is pretty "standard" (mxq-s905-v20 says the signature on the PCB), and the above procedure works. It's not for the faint of heart, I agree.

Anyway, in your setup the binary amlogic blobs and u-boot are on eMMC and then the kernel is took from the SDCard.

For the full stack (binary amlogic blobs, u-boot, kernel) to boot from the SDCard you have to remove the bootloader from the eMMC. There is another trick which works with Rockchip SoCs: short the CLOCK pin to ground of the eMMC. Not sure if it works on amlogic SoCs too, but I guess they all follow the same pattern.

 

You may say: "why bothering with erasing eMMC and doing more work for the same...". Well, it's like treating the tv box as the same SBC boards out there rather than a "black box": removing as most blobs as possible to really make the hardware yours.

 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines