Device Tree OrangePiH5orangepi.dtb issue

[sv1eia]

The device tree binary in /boot/orangepi/OrangePiH5orangepi.dtb is supposed to provide devices initialization after u-boot. Yet, the changes done to it via dtc do not work at all although uboot reports it loads it successfully. No matter what new changes are been put to /boot/orangepi/OrangePiH5orangepi.dtb, the booted system does not take them into account.

Please provide the source of u-boot used for generating the uboot.bin file. Please create another repository with the u-boot as it has been configured to generate the uboot.bin that is used in the image generation.

[ThomasKaiser]

http://filez.zoobab.com/allwinner/h5/lichee/brandy/

[ThomasKaiser]

Better grab the whole BSP and in case you want to get rid of this BSP mess better start the same way as community did a year ago when dealing with A64 BSP: https://github.com/longsleep/u-boot-pine64/commits/pine64-hacks?after=8dWxGlqj05lUO7Nt1kOMLz%2BhQ9orMzQ%3D

After applying longsleep's changes to BSP u-boot sources dtc can be used for almost everything (a few exceptions like dvfs operating points will remain -- but currently DVFS isn't working at all)

[sv1eia]

Thanks, but I expect an answer from the repository's author/owner, what you say is known but not what I requested. "Please create another repository with the u-boot as it has been configured to generate the uboot.bin that is used in the image generation."

I hope Buddy could answer this.

[ThomasKaiser]

@sv1eia wish you good luck :)

BTW: When looking at random boot logs for PC 2 OS images it seems initrd.img might be worth a look too:

Loading orangepi orangepi/OrangePiH5orangepi.dtb from 44000000 ...
bootm initd_size:10a4e2 fdt_addr:44000000 ...
Using Device Tree in place at 44000000, end 44015dbf

[sv1eia]

@ThomasKaiser Thanks for the pointer. So, you imply that the ramdisk initrd.img actually contains the dtb to be executed?

@BuddyZhang1 , we do need a method to make these images usable, usable means to at least be able to modify the device initialization , the .dtb , so please help us on that.

Normally that should has to happen from the aforementioned /boot/orangepi/OrangePiH5orangepi.dtb file, yet as it seems that cannot be done since you might have something configured in u-boot or initrd or elsewhere that takes precedence over the proper file. Initrd.bin is also an 'external' file in your BSP, a binary blob, and its generation sources are also needed a it is shown by tkaiser.

@BuddyZhang1 Your help here is important.

[ThomasKaiser]

So, you imply that the ramdisk initrd.img actually contains the dtb to be executed?

At least it looks suspicious. And it can be checked (not by me, I sent my PC 2 sample to jemk who already did a great job regarding DRAM initialization in mainline u-boot).

To be honest: I don't plan to run this BSP stuff ever again on a H5 device since for my use cases mainline u-boot/kernel will be sufficient pretty soon. But if anyone wants to deal with this board now using Allwinner's outdated u-boot and kernel versions it still seems obvious to me that someone needs to clean up this BSP mess before (just like longsleep did when starting to deal with A64 almost one year ago).

And IMO fiddling around with dtc isn't the smartest way to deal with config changes. In Armbian we do a lot of such stuff from within boot script, see Pine64 legacy example. But of course the BSP mess has to be cleaned up first :)

[tkggithub]

I have had some "fun" (quite a number of days) with trying to get the uboot from the H5 SDK to work and I would also be interested in having a working version of it. I still think that getting the uboot from H5 SDK to work on OPI PC2 as is, requires an advanced degree in wishful thinking and at least an intermediate level in black magic. :) The second part will come in handy when attempting to load the monitor (BL31) at an address that it does not expect and stops because the .bss was not properly initialized.

During the last few days I have learned that you need to gather various bits of information and have it patched at various stages.

My initial problem was simple: How to restart the board after shutting down from Linux? It seems that the board does not really powers off, instead reboots to uboot with a special flag to tell it to enter standby. The board (as it is configured now) does not seem to look for the power key, instead it seem to look for a ir remote code that is not really mentioned. It also does not seem to enter standby even though the ir code should be handled by the arisc core ... This is what started it for me. Is it too much to ask to be able to restart the board using the power button? or at least specify which remote codes it expects. Yes I saw that the .dts specifies some codes in there but I don't know how exactly they are to be interpreted (they seem to be NEC extended codes). I tried to change some of them and still no luck.

Also not to mention that currently if I shutdown from Linux without manually issuing sync, the sd card can become corrupted and no longer boot without a reflash.

Now back to uboot. It would be great to have a working source even based on the H5 SDK.

Building the u-boot from the brandy folder will give you a raw version of the boot0 and main uboot binaries. Each of them will need to be patched. Ideally, this would work using a proper dragonboard target but it did not seem to work for me to generate a proper packed H5 target. The boot0 will need to be patched with a system_config file that gets compiled using "script". I have found one that almost did the job (I had to disable jtag on it and set debug mode to 257 or so to obtain a header similar to what the binary boot0.bin provides). Without this patching the boot0 loader will not have even the proper serial pins data and you will not see anything on your serial console (not to mention other dram params).

The same config file would normally be used to generate a dts but in my case I used the dts from the Linux OrangePi_H5SDK tree. This dts can be used to generate a dtb that should be appended to the generated uboot binaries using one of the update_ftd tools (I am quoting from memory, the name might be slightly different, but it is one of the utilities from the package that you can compile). You really need to use the tool, as if you just append the dtb to the uboot the offsets within the uboot image are still not updated and the loading the stage will fail. This uboot+dtb binary needs to be packed then to a firmware package together with an arisc binary and a bl31 (monitor) using yet another tool. The bl31 image can be compiled from the same brandy tree, look for the arm trusted firmware folder. However that bl31 image as I mentioned at the beginning is compiled assuming it goes to somewhere like 0x40000000 while the uboot configuration for boot0 loads it to something like 0x48000000. The problem with that is that although BL31 will start it will have the .bss data uninitialized (the .bss clearing code will clear a wrong area) and it will fail when a mmap array will be all 0xfffff..fffs instead of zeros. I have fixed this by telling the BL31 linker to use the 0x480... address however I think there are some hardcoded values when initializing the mmap tables and the monitor still hangs when attempting to use the messagebox infrastructure and I still not get to load the kernel yet.

The short story is that you need to append the dtb at least to the uboot image, and then also on the fat partition on your sdcard. You might also need to have some of those parameters backported to the script configuration so that the boot0 bootloader gets properly patched.

Hope this helps other poor souls having fun with this board. :)

[ThomasKaiser]

The board (as it is configured now) does not seem to look for the power key

With H3 BSP kernel it's just tweaking kernel config and defining the appropriate GPIO pin (PL03) there as one of the wakeup sources, see example. You might want to try that with PL04) on PC 2.

[sv1eia]

@BuddyZhang1 Seen your new commits on Dec/5 and tried them out. (commits up to Dec./5 ) Unfortunately again any changes to OrangePiH5orangepi.dtb are not reflected on the booted system. Still got the same problem. Hope you can solve it.

[BuddyZhang1]

@sv1eia Now , I'm porting new uboot into our H5SDK not legacy BSP uboot. Because some issue on uboot, I can't release it now, so pls wait some day.

Good Luck

[BuddyZhang1]

@ThomasKaiser There is a important patch of kernel entry on uboot, pls review this patch. https://github.com/OrangePiLibra/OrangePi_H5SDK/commit/1fa8e004136daa48cdffd64cd34731d6c37b4189

Good Luck

[ThomasKaiser]

@BuddyZhang1 I wish you good luck and won't review anything. It's completely up to you to try to fix the obvious things or not.

People expect legacy u-boot + kernel in a working state, so please address booting process (easy, look at longsleep's repo for A64), GbE (easy, community delivered methodology how you can tweak tx-rx/delay even without touching .dtb stuff) and DVFS issues before someone else is doing.

I don't know whether you remember but with H3 Orange Pi boards one third party was the first one who delivered somewhat polished OS images but he chose overclocking/overvolting issues which is something Orange Pis are still blamed for.

Personally I'm not interested in this legacy stuff at all. I wait until mainline u-boot and kernel are ready and then do the stuff I'm interested in (no display involved).

[BuddyZhang1]

@tkggithub Thanks for your advice! Now, I'm doing some work to port uboot onto OrangePi PC2, but not luck... System always has some bug on uboot. I have update source code of uboot onto OrangePi_H5SDK and create some scripts to compile uboot and boot0. I will do some try to make uboot and boot0 run my OrangePi PC2.

Good Luck

[tkggithub]

@ThomasKaiser Thank you for the advice, I'll give it a go as soon as I can understand how those values are used in the code! I have still yet to discover which dtb copies are used at each step. Including what the arisc is using.

@BuddyZhang1 Thank you for all the work you are doing. Much appreciated! I do understand that there is pressure to release a working u-boot and I understand you are working hard on it. I think the problem here is that somebody decided to use binaries in various places and they don't fully work. It is also not that obvious how to reconstruct them when things don't work properly. Sometimes little things help. How hard would it have been to print on the sheet of paper that came with the board the fact that without a proper image on the sdcard the board will look dead. No leds or serial console coming up. How about adding a small hello world to the small flash that would light up leds when powered and print on the serial console something like "this is a program running from flash, please use a proper image to see more ...". That would have saved a lot of frustation from people getting a board that looks absolutely dead on power on but it is actually perfectly fine. Also providing links to bad images (images that are from other boards) does not help much when people just load them and the board is still not working. I know that this part has been improved. :)

Just in case it helps, I spent some time yesterday and now I get in u-boot up to the point it tries to load various parts from the micro sd card. The probem that I was having was that the arisc binary was most likely broken and I am now using the one from your uboot binary. All the best and keep up the good work!

[ThomasKaiser]

BTW: http://linux-sunxi.org/ exists. H5 is nothing special.

[sv1eia]

@BuddyZhang1

Tested new commits up to 58af688

Same problem, .dtb changes are not reflected on the booted system.

Hope you could find a solution.

[ehoutsma]

When compiling and creating a new image, you get an image with a prebuild u-boot from the external directory. Probably because u-boot doesn't compile at the moment.

But when I look at the uboot_compile script there are some lines in it saying something like: # Merge uboot and dtb Which makes me suspect the u-boot has a DTB merged inside itself, ignoring a custom DTB? These tools aren't in supplied either.

[ThomasKaiser]

@ehoutsma all that has to be done is repeating what @longsleep did when he started with A64 back in January. See link to his u-boot repo above, read through Readme.md and scripts of his simpleimage repo. It's just a (diligent but) routine piece of work.

References:

• https://forum.armbian.com/index.php/topic/1762-new-oranges-with-h5-and-h2/page-4#entry21075
• https://forum.armbian.com/index.php/topic/2869-armbian-for-orangepi-pc2-allwinner-h5/page-2#entry21012

And even after cleaning up the BSP mess some stuff could only be adjusted in u-boot. Changing dvfs operating points with A64 legacy kernel for example required rebuilding u-boot and overwriting a few sectors with a freshly created blob: https://github.com/longsleep/build-pine64-image/tree/master/u-boot-postprocess#merge-u-boot-with-other-parts

[tkggithub]

@sv1eia

Tested new commits up to 58af688 Same problem, .dtb changes are not reflected on the booted system.

Could you please provide some more details of what parameters from the dtb file you expected to be changed and did not changed? It might be easier to track an individual parameter.

I have finally succeded to build and boot my own debug version of the u-boot (boot0 and main u-boot), and BL31 (monitor). The scp (arisc) is still the binary from the u-boot binary from @BuddyZhang1

Here is a boot log: http://pastebin.com/9gburXZD

You can see there are quite some more messages than normal as it has various debug bits turned on but also my own custom messages from tracking various issues.

The u-boot and BL31 sourcecode is based on the lichee H5SDK with few changes from the version commited by @BuddyZhang1. In particular the uboot scripts to load the initrd,dtb, and kernel. Also his uboot: kernel entry for bootm patch was needed. I would still make the arm call conditional on the presence of BL31 but so far I used it as in the patch.

I don't know if there is any dtb in the initrd image yet, but i'll have a look at it when I'll have a bit more time.

@BuddyZhang1 I saw from your uboot scripts that you use a merge_uboot tool to create the firmware image package. In my case I used: ./dragonsecboot -pack ${UBOOT_BUILD_ROOT}/../configs/default/boot_package.cfg where the boot_package.cfg is from the lichee H5 configs folder lichee/tools/pack/chips/sun50iw2p1/configs/default Probably merge_uboot works too (seems similar based on the lichee code), I'll try it at some point.

I tried to compile the u-boot you committed but so far I did not have success with it. Maybe I need a different cross compiler as the main issue was that some of the binaries like the nand lib were compiled with a different VFP convention than the rest of the code. Maybe the float abi needs to be forced to "hard".

Also another thing I noticed from the bootlog is that there are two unimplemented service calls in the monitor (look for 0xc000005c and 0xc000005d in the boot log that I provided). Any idea what they might be?

Obviously I can make my changes available but as @ThomasKaiser also said, the better way would be to get mainline support than the BSP way. :)

I'll investigate further my issue with the power button and the ir remote wake up from standby. I have a feeling that they are really hadled by the MIPS arisc core for which I only have the binaries. Hopefully I won't have to dissasemble it (I saw there is an ongoing project for AR100 from the H3) AR100

[ThomasKaiser]

but as @ThomasKaiser also said, the better way would be to get mainline support than the BSP way

That's not what I suggested. I just said look at how longsleep did it 11 months ago. His variant still uses various blobs and both legacy u-boot and kernel. But not in the braindead BSP fashion.

Solely relying on mainline stuff will work rather soon for my use cases (Ethernet+USB) but not for the stuff the average OPi PC 2 buyer is interested in. :)

[tkggithub]

@ThomasKaiser This is what I was referring to:

Personally I'm not interested in this legacy stuff at all. I wait until mainline u-boot and kernel are ready and then do the stuff I'm interested in (no display involved).

Sorry if this generated any confusion. I also agree that having a decent legacy u-boot that can be built from source is still progress.

On a progress related note, I have had a look at initrd.img and it seems to be very frugal. I don't have a problem with KISS as long as it works. :) The only things I could see in there are an arm64 busybox binary and the init script and few empty folders. `$ ls -R .: bin dev init proc sbin sys tmp

./bin: busybox

./dev:

./proc:

./sbin:

./sys:

./tmp: `

The busybox links are populated by the init script at runtime.

The messages that you saw:

Loading orangepi orangepi/OrangePiH5orangepi.dtb from 44000000 ... bootm initd_size:10a4e2 fdt_addr:44000000 ... Using Device Tree in place at 44000000, end 44015dbf

are generated from the u-boot script from include/configs/sun50iw2p1.h (the first two lines) and the code that checks the fdt (the last line) "boot_kernel=" \ "echo bootm kernel:${kernel_addr} initrd:${initrd_addr} ...;" \ "echo bootm initd_size:${initrd_size} fdt_addr:${fdt_addr} ...;" \ "bootm ${kernel_addr} ${initrd_addr}:${initrd_size} ${fdt_addr}\0" \ You could also see that also in the log I provided earlier at line 448: INSERT: table 7ff9f618, filled 22/293 rv 77ef2908 ==> name="boot_kernel" value="echo bootm kernel:${kernel_addr} initrd:${initrd_addr} ...;echo bootm initd_size:${initrd_size} fdt_addr:${fdt_addr} ...;bootm ${kernel_addr} ${initrd_addr}:${initrd_size} ${fdt_addr}"

The last line about using the device tree is a notification that the fdt has not been moved to another address by u-boot.

Therefore as far as I can see there seems to be no traces of a dtb or fdt in the initrd.img image. Probably the misspelled initd_size instead of initrd_size might have generated some confusion. From the lines I posted above it should be clear now that there is no initd involvement. :)

[sv1eia]

@BuddyZhang1 New test results Performed another clean git clone up to commit dcf55745

Image builded and tested, yet again whatever changes placed to /boot/orangepi/OrangePiH5orangepi.dtb via the dtc, still do not reflect on the booted system. So, device tree .dtb still needs fixing.

[ehoutsma]

I did some testing in the u-boot and there are 2 things going on. First, the DTB isn't loaded at all from the fat partition because the ; at the end of the echo is missing. Second, it requires the -c option added to the fdt addr. Then It loads the custom DTB and uses those settings.

This is what it should look like in the file: u-boot/include/configs/sun50iw2p1.h

        "load_dtb=" \
                "if test ${fdt_filename} = \"\"; then " \
                        "setenv fdt_filename ${fdt_filename_prefix}A64${fdt_filename_suffix}; " \
                "fi; " \
                "echo Loading orangepi ${fdt_filename} from ${fdt_addr} ...;" \
                "fatload mmc 0:1 ${fdt_addr} ${fdt_filename}; " \
                "fdt addr -c ${fdt_addr}; fdt resize\0" \

[ThomasKaiser]

https://github.com/longsleep/u-boot-pine64/commits/eec7d345cd11fe99d2db309a0025041821572e94/include/configs/sun50iw1p1.h

[sv1eia]

@ehoutsma

Tried again making also the changes @ehoutsma mention in file "u-boot/include/configs/sun50iw2p1.h". First I did a make clean in u-boot folder and then a delete to all the contents of output folder, after launched the build.sh. Initially performed a build uboot option and then the build release image, it finished ok. Write the produced image to SD and booted. At that point did dtc -I dtb -O dts -o OrangePiH5orangepi.dts /boot/orangepi/OrangePiH5orangepi.dtb nano OrangePiH5orangepi.dts <changed the line 2113 to "status = "disabled";"> <changed the line 2207 to "status = "disabled";"> <so there will be no more a codec device in aplay, just for testing dtb> sudo dtc -I dts -O dtb -o /boot/orangepi/OrangePiH5orangepi.dtb OrangePiH5orangepi.dts sudo sync;sudo reboot

Then after the reboot I checked the output of aplay and it was (the same as before the dtb modification)

---

orangepi@Orangepi: sudo aplay -l [sudo] password for orangepi: List of PLAYBACK Hardware Devices card 0: audiocodec [audiocodec], device 0: SUNXI-CODEC sun50iw2codec-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: sndhdmi [sndhdmi], device 0: SUNXI-HDMIAUDIO sndhdmi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 orangepi@Orangepi:~$

---

Unfortunately, the reply contains the "card 0: audiocodec [audiocodec], device 0: SUNXI-CODEC" which is the codec driver that we changed to disabled, it shouldnt be there now, but it is still there, so based on that simple test it looks to me that the modified dtb is not loaded.

@ehoutsma What test did you perform to say that now the changes on dtb are reflected into the booted system?

[sv1eia]

@BuddyZhang1 @ehoutsma

Seen just now the bootlog

---

Booting with defaults ... Loading orangepi orangepi/OrangePiH5A64.dtb from 44000000 ... reading orangepi/OrangePiH5A64.dtb Unable to read file orangepi/OrangePiH5A64.dtb Loading orangepi orangepi/uImage from 4007ffc0 ... reading orangepi/uImage 12200584 bytes read in 522 ms (22.3 MiB/s) reading initrd.img 1090786 bytes read in 49 ms (21.2 MiB/s) Loading orangepi initrd.img from 44300000 ... bootm kernel:4007ffc0 initrd:44300000 ... bootm initd_size:10a4e2 fdt_addr:44000000 ... Booting kernel from Legacy Image at 4007ffc0 ... Image Name: OrangePiH5 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 12200520 Bytes = 11.6 MiB Load Address: 40080000 Entry Point: 40080000 Verifying Checksum ... OK XIP Kernel Image ... OK reserving fdt memory region: addr=40020000 size=800 reserving fdt memory region: addr=48000000 size=1000000 reserving fdt memory region: addr=48100000 size=4000 reserving fdt memory region: addr=48104000 size=1000 reserving fdt memory region: addr=48105000 size=1000 Loading Ramdisk to 76d85000, end 76e8f4e2 ... OK Using Device Tree in place at 44000000, end 44015e1f

Starting kernel ...

---

In that is mentioned the dtb as "orangepi/OrangePiH5A64.dtb" whereas in the filesystem the dtb is "orangepi/OrangePiH5orangepi.dtb" @BuddyZhang1 that definitively needs to be fixed!

After seen that, did a copy of the OrangePiH5orangepi.dtb to OrangePiH5A64.dtb filename and rebooted. And, modified dtb indeed affected the booted system, now the codec device is not in the aplay list

---

orangepi@Orangepi: sudo aplay -l [sudo] password for orangepi: List of PLAYBACK Hardware Devices card 0: sndhdmi [sndhdmi], device 0: SUNXI-HDMIAUDIO sndhdmi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 orangepi@Orangepi:

---

[BuddyZhang1]

@sv1eia Nice Work!!!! I can get information from DT, it's my fault, I wrote an error dts name on /u-boot/include/configs/sun50iw2p1.h The correct DT name is OrangePiH5.dtb, but I wrote OrangePiH5A64.dtb..... Thanks for your help!! I have do some patch and push to github, pls sync.

Thank you! Nice Work! ^_^

[ehoutsma]

@BuddyZhang1 The patch still doesn't function, because you didn't change the boot script.

1: Leave out A64 between ${fdt_filename_prefix} and ${fdt_filename_suffix} to select the new filename (orangepi/OrangePiH5.dtb). 2: add an dotcomma ; after the line with the echo to make sure the DTB is loaded (Between ... and "), otherwise the line is just echoed and not run. 3: add "-c" after the addr to ensure the new fdt_addr is actually used in the kernel.

These 3 steps are necessary to get custom DTB working for the endusers.

        "load_dtb=" \
                "if test ${fdt_filename} = \"\"; then " \
                        "setenv fdt_filename ${fdt_filename_prefix}A64${fdt_filename_suffix}; " \
                "fi; " \
                "echo Loading orangepi ${fdt_filename} from ${fdt_addr} ...;" \
                "fatload mmc 0:1 ${fdt_addr} ${fdt_filename}; " \
                "fdt addr -c ${fdt_addr}; fdt resize\0" \

[sv1eia]

@BuddyZhang1 Buddy, the successful test was including locally what @ehoutsma mention above, you need to include his changes in file "u-boot/include/configs/sun50iw2p1.h".

[tkggithub]

@ehoutsma

And ... you might also want to add step 4: to change the actual filename on the fat partition used in scripts/build_image.sh which currently still reads OrangePiH5orangepi.dtb. :)

And you might also add step 5: REMOVE the call to pack from scripts/kernel_compile.sh (as I mentioned before in issue 11) so that the image will build properly from the first time:

92  # Update DTB with uboot 
93  echo -e "\e[1;31m Cover sys_config.fex to DTS \e[0m" 
94  cd $ROOT/scripts/pack/ 
95  ./pack 
96  cd - 

Again I mention that those lines have to be DELETED from there and NOT kept there ... The pack is called after building u-boot which is the better place to have it.

There are more things but at least with these changes the image should build properly when freshly checkout from github.

There are more things but let's not overload Buddy. :)

[boris80]

Hello guys,

In the /scripts/build_image.sh (line 64) - has anybody else noticed the typo: _cp -rfa $OUTPUT/OrangePiH5.dtb $OUTPUT/orangepi/ #OrangePiH5.dtb

-# Add boot support if there if [ -e "$OUTPUT/orangepi/uImage" -a -e "$OUTPUT/orangepi/OrangePiH5orangepi.dtb" ]; then_

The above if-statement is never true, dtb file should be named "OrangePiH5.dtb"?

Issue #24

After correcting the script file "build_image.sh" and running the build, this is what i get: Loading orangepi uEnv.txt from 40000000 ... reading uEnv.txt [mmc]: blkcnt should not be 0 114 bytes read in 2 ms (55.7 KiB/s) Loading boot environment ... reading boot.scr Unable to read file boot.scr Booting with defaults ... Loading orangepi orangepi/OrangePiH5.dtb from 44000000 ... reading orangepi/OrangePiH5.dtb 73231 bytes read in 8 ms (8.7 MiB/s) Loading orangepi orangepi/uImage from 4007ffc0 ... reading orangepi/uImage 12200584 bytes read in 528 ms (22 MiB/s) reading initrd.img 1090786 bytes read in 50 ms (20.8 MiB/s) Loading orangepi initrd.img from 44300000 ... bootm kernel:4007ffc0 initrd:44300000 ... bootm initd_size:10a4e2 fdt_addr:44000000 ... -## Booting kernel from Legacy Image at 4007ffc0 ... Image Name: OrangePiH5 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 12200520 Bytes = 11.6 MiB Load Address: 40080000 Entry Point: 40080000 Verifying Checksum ... OK XIP Kernel Image ... OK reserving fdt memory region: addr=40020000 size=800 reserving fdt memory region: addr=48000000 size=1000000 reserving fdt memory region: addr=48100000 size=4000 reserving fdt memory region: addr=48104000 size=1000 reserving fdt memory region: addr=48105000 size=1000 Loading Ramdisk to 76d85000, end 76e8f4e2 ... OK Using Device Tree in place at 44000000, end 44015e1f

Starting kernel ... .... [ 10.878011] systemd[1]: Detected architecture arm64. Welcome to Ubuntu 16.04.2 LTS!