Guillaume75
Posts: 3
Joined: Sun May 15, 2016 7:36 pm

Re: Entering aarch64 execution state

Sun May 15, 2016 8:36 pm

Hi,

Where is config.txt, I cannot figure out where it is?

Guillaume

dwelch67
Posts: 944
Joined: Sat May 26, 2012 5:32 pm

Re: Entering aarch64 execution state

Sun May 15, 2016 11:23 pm

you create it, same directory as kernel(7).img and start.elf and such. root directory of the sd card.

Hallo32
Posts: 8
Joined: Thu May 05, 2016 6:34 pm

Re: Entering aarch64 execution state

Sun May 15, 2016 11:29 pm

Guillaume75 wrote:Hi,

Where is config.txt, I cannot figure out where it is?

Guillaume
The boot partition is not mounted by default. You may just mount it first.

Guillaume75
Posts: 3
Joined: Sun May 15, 2016 7:36 pm

Re: Entering aarch64 execution state

Mon May 16, 2016 1:06 pm

Thank you!

DazzF
Posts: 22
Joined: Sun Aug 19, 2012 5:32 pm

Re: Entering aarch64 execution state

Sun May 22, 2016 8:52 pm

Hi,

Any progress on this, would like to know if we can compile a 64bit Kernel?

Thanks

fsck
Posts: 26
Joined: Mon Feb 23, 2015 4:49 pm

Re: Entering aarch64 execution state

Sun May 22, 2016 10:18 pm

DazzF wrote:Hi,

Any progress on this, would like to know if we can compile a 64bit Kernel?

Thanks
Uh, that's already done. Albeit without 3d graphics support. There's an image available. Did you read the thread?

User avatar
bstrobl
Posts: 95
Joined: Wed Jun 04, 2014 8:31 pm
Location: Germany

Re: Entering aarch64 execution state

Mon May 23, 2016 2:00 pm

Seems like the Cortex A32 cores would have made more sense for the Pi 3, since ditching the 64 bit instructions alone gives a 10% improvement in efficiency for normal 32 bit operations.

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5162
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Entering aarch64 execution state

Mon May 23, 2016 2:38 pm

bstrobl wrote:Seems like the Cortex A32 cores would have made more sense for the Pi 3, since ditching the 64 bit instructions alone gives a 10% improvement in efficiency for normal 32 bit operations.
Seeing as the A32 processor was only announced a couple of months ago (about the same time as Pi3 was released) it wasn't an option.
There will always be new processors that have performance/power/size/cost advantages over existing processors.
Also be aware that work on Pi3 started long long ago.

User avatar
bstrobl
Posts: 95
Joined: Wed Jun 04, 2014 8:31 pm
Location: Germany

Re: Entering aarch64 execution state

Mon May 23, 2016 2:57 pm

dom wrote:
bstrobl wrote:Seems like the Cortex A32 cores would have made more sense for the Pi 3, since ditching the 64 bit instructions alone gives a 10% improvement in efficiency for normal 32 bit operations.
Seeing as the A32 processor was only announced a couple of months ago (about the same time as Pi3 was released) it wasn't an option.
There will always be new processors that have performance/power/size/cost advantages over existing processors.
Also be aware that work on Pi3 started long long ago.
Yes of course, although I am a bit surprised by the quick succession of the Pi 2 by the Pi 3 given the large development budget it usually takes to release a new SoC. Would have expected a much longer shelf life for products containing the 2836. The Cortex A53 also seems to have only increased performance somewhat linearly with power draw as compared to the A7, leading to much higher thermal output with a thermal sensor that is on the far side of the die.

Well, if the whole overheating problem can be solved with a bcm2838/2839 and newer arm cores then I'll be a happy camper :).

User avatar
bstrobl
Posts: 95
Joined: Wed Jun 04, 2014 8:31 pm
Location: Germany

Re: Entering aarch64 execution state

Mon May 23, 2016 3:43 pm

Actually just went back and checked the documentation on the Cortex A32, and am now beginning to suspect you guys might use it for your next chip :lol:

-10% more efficient than A35
-25% more efficient than A7
-A35 is 25% more efficient than A53
-Suggested use of A32 is in wearables and SBCs
-VC4 is anyway limited to 1GB RAM, might as well squeeze out as much "32-bitness" as possible
-40nm layout plans for TSMC are explicitly mentioned by arm
-Full backwards compatibility with armv6/armv7

It would remove the 64-bit capability though, but as Eben has already said, the A53s were chosen for their excellent 32-bit performance.

Hallo32
Posts: 8
Joined: Thu May 05, 2016 6:34 pm

Re: Entering aarch64 execution state

Tue May 24, 2016 4:27 am

@dom

Is there a timetable for porting the foundation kernel stuff to the mainline kernel?
Will it be possible to compile this stuff also for the Aarch64 architecture or will it be limited to 32bit because of some limitations of the source code?

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5162
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Entering aarch64 execution state

Tue May 24, 2016 11:27 am

Hallo32 wrote: Is there a timetable for porting the foundation kernel stuff to the mainline kernel?
Will it be possible to compile this stuff also for the Aarch64 architecture or will it be limited to 32bit because of some limitations of the source code?
If you are interested in upstreaming you should subscribe to the mailing list:
http://blog.gmane.org/gmane.linux.kernel.rpi

DazzF
Posts: 22
Joined: Sun Aug 19, 2012 5:32 pm

Re: Entering aarch64 execution state

Thu May 26, 2016 11:43 am

Got Ubuntu 14.04.4 LTS Core up and running with this Kernel, looks stable, will start adding modules and see how I get on...

Edit : Now got a 16.4 image running, Ethernet, USB working, will backup and then play with WiFi and a desktop

Edit : Now got a desktop up and running, not had any joy with WiFi yet, but will keep playing. Memory use looks good, I thought 64bit would use a lot more, but it only appears to use a bit.

Thank you everyone for the fantastic effort that went into this...

flag26838
Posts: 13
Joined: Wed Mar 02, 2016 12:14 pm

Re: Entering aarch64 execution state

Fri May 27, 2016 3:07 pm

Is there a repository containing all the kernel patches need to build an aarch64 kernel?

marcus_c
Posts: 11
Joined: Sun Mar 13, 2016 12:15 am

Re: Entering aarch64 execution state

Mon May 30, 2016 12:07 pm

Is there a repository containing all the kernel patches need to build an aarch64 kernel?
You can have GitHub create a patchset for you by accessing the following URL:
https://github.com/zeldin/linux/compare ... rpi3.patch

flag26838
Posts: 13
Joined: Wed Mar 02, 2016 12:14 pm

Re: Entering aarch64 execution state

Tue May 31, 2016 9:37 am

Except that this branch hangs during boot, just before mounting rootfs:

U-Boot 2016.03-00640-gc805f24 (May 30 2016 - 15:53:52 +0200)

DRAM: 944 MiB
RPI 3 Model B (0xa02082)
boot regs: 0x00000000 0x00000000 0x00000000 0x00000000
MMC: bcm2835_sdhci: 0
reading uboot.env

** Unable to read "uboot.env" from mmc0:1 **
Using default environment

In: serial
Out: lcd
Err: lcd
Net: Net Initialization Skipped
No ethernet found.
starting USB...
USB0: Core Release: 2.80a
scanning bus 0 for devices... 3 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
scanning usb for ethernet devices... 1 Ethernet Device(s) found
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr.uimg
reading /boot.scr.uimg
285 bytes read in 10 ms (27.3 KiB/s)
## Executing script at 02000000
reading bcm2837-rpi-3-b.dtb
5736 bytes read in 30 ms (186.5 KiB/s)
reading image
8326728 bytes read in 709 ms (11.2 MiB/s)
## Flattened Device Tree blob at 00000100
Booting using the fdt blob at 0x000100
reserving fdt memory region: addr=0 size=1000
Loading Device Tree to 000000003ab30000, end 000000003ab34667 ... OK

Starting kernel ...

Booting Linux on physical CPU 0x0
Linux version 4.5.0+ ([email protected]) (gcc version 5.3.1 20160413 (Ubuntu/Linaro 5.3.1-14ubuntu2) ) #2 SMP PREEMPT Tue May 31 11:12:06 CEST 2016
Boot CPU: AArch64 Processor [410fd034]
cma: Reserved 16 MiB at 0x0000000039800000
PERCPU: Embedded 20 pages/cpu @ffffffc03af9d000 s41368 r8192 d32360 u81920
Detected VIPT I-cache on CPU0
CPU features: enabling workaround for ARM erratum 845719
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 237888
Kernel command line: console=ttyS0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait rw
log_buf_len individual max cpu contribution: 4096 bytes
log_buf_len total cpu_extra contributions: 12288 bytes
log_buf_len min size: 16384 bytes
log_buf_len: 32768 bytes
early log buf free: 15128(92%)
PID hash table entries: 4096 (order: 3, 32768 bytes)
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
software IO TLB [mem 0x34a00000-0x38a00000] (64MB) mapped at [ffffffc034a00000-ffffffc0389fffff]
Memory: 857560K/966656K available (5440K kernel code, 371K rwdata, 2004K rodata, 312K init, 211K bss, 92712K reserved, 16384K cma-reserved)
Virtual kernel memory layout:
vmalloc : 0xffffff8000000000 - 0xffffffbdbfff0000 ( 246 GB)
vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000 ( 8 GB maximum)
0xffffffbdc0000000 - 0xffffffbdc0ec0000 ( 14 MB actual)
fixed : 0xffffffbffa7fd000 - 0xffffffbffac00000 ( 4108 KB)
PCI I/O : 0xffffffbffae00000 - 0xffffffbffbe00000 ( 16 MB)
modules : 0xffffffbffc000000 - 0xffffffc000000000 ( 64 MB)
memory : 0xffffffc000000000 - 0xffffffc03b000000 ( 944 MB)
.init : 0xffffffc0007c6000 - 0xffffffc000814000 ( 312 KB)
.text : 0xffffffc000080000 - 0xffffffc0007c5b74 ( 7447 KB)
.data : 0xffffffc000814000 - 0xffffffc000870e48 ( 372 KB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
Preemptible hierarchical RCU implementation.
Build-time adjustment of leaf fanout to 64.
RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=4.
RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=4
NR_IRQS:64 nr_irqs:64 0
sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 2147483647500ns
clocksource: timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275 ns
bcm2835: system timer (irq = 35)
Architected cp15 timer(s) running at 19.20MHz (phys).
clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns
Console: colour dummy device 80x25
Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=76800)
pid_max: default: 32768 minimum: 301
Security Framework initialized
Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)
Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes)
ASID allocator initialised with 65536 entries
Detected VIPT I-cache on CPU1
CPU1: Booted secondary processor [410fd034]
Detected VIPT I-cache on CPU2
CPU2: Booted secondary processor [410fd034]
CPU3: failed to come online
Brought up 3 CPUs
SMP: Total of 3 processors activated.
CPU: All CPU(s) started at EL2
alternatives: patching kernel code
devtmpfs: initialized
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
cpuidle: using governor ladder
cpuidle: using governor menu
vdso: 2 pages (1 code @ ffffffc000819000, 1 data @ ffffffc000818000)
hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
DMA: preallocated 256 KiB pool for atomic allocations
Serial: AMBA PL011 UART driver
HugeTLB registered 2 MB page size, pre-allocated 0 pages
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
clocksource: Switched to clocksource arch_sys_counter
VFS: Disk quotas dquot_6.6.0
VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
FS-Cache: Loaded
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 5, 131072 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
hw perfevents: enabled with armv8_pmuv3 PMU driver, 7 counters available
kvm [1]: error: no compatible GIC node found
kvm [1]: timer IRQ4
kvm [1]: 8-bit VMID
kvm [1]: Hyp mode initialized successfully
futex hash table entries: 1024 (order: 5, 131072 bytes)
audit: initializing netlink subsys (disabled)
audit: type=2000 audit(1.183:1): initialized
FS-Cache: Netfs 'nfs' registered for caching
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
fuse init (API version 7.24)
9p: Installing v9fs 9p2000 file system support
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
console [ttyS0] disabled
3f215040.uart: ttyS0 at MMIO 0x3f215040 (irq = 61, base_baud = 31250000) is a 16550
console [ttyS0] enabled
Unable to detect cache hierarchy from DT for CPU 0
loop: module loaded
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <[email protected]>
usbcore: registered new interface driver smsc95xx
3f980000.usb supply vusb_d not found, using dummy regulator
3f980000.usb supply vusb_a not found, using dummy regulator
dwc2 3f980000.usb: Configuration mismatch. dr_mode forced to host
dwc2 3f980000.usb: DWC OTG Controller
dwc2 3f980000.usb: new USB bus registered, assigned bus number 1
dwc2 3f980000.usb: irq 41, io mem 0x00000000
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ehci-platform: EHCI generic platform driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci-pci: OHCI PCI platform driver
ohci-platform: OHCI generic platform driver
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
ledtrig-cpu: registered to indicate activity on CPUs
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
bcm2835-mbox 3f00b880.mailbox: mailbox enabled
NET: Registered protocol family 17
9pnet: Installing 9P2000 support
Key type dns_resolver registered
Registered cp15_barrier emulation handler
Registered setend emulation handler
registered taskstats version 1
3f201000.uart: ttyAMA0 at MMIO 0x3f201000 (irq = 72, base_baud = 0) is a PL011 rev2
mmc0: SDHCI controller on 3f300000.sdhci [3f300000.sdhci] using PIO
raspberrypi-firmware soc:firmware: Attached to firmware from 2016-03-24 12:37
Console: switching to colour frame buffer device 100x30
hctosys: unable to open rtc device (rtc0)
... <- hangs here

I've used this Debian image as a starting point[*] and i've noticed that the kernel / dtb that came with this image is significantly larger than the one produced by zeldin's tree.

Moreover, substituting the armstubs / u-boot that came in this Debian image with one produced by upstream trees, doesn't work either, since i get a solid hang on boot before the serial has any chance to spit out any character.

I guess some investigation is needed.

1: viewtopic.php?p=952679#p952679

marcus_c
Posts: 11
Joined: Sun Mar 13, 2016 12:15 am

Re: Entering aarch64 execution state

Tue May 31, 2016 4:01 pm

CPU3: failed to come online
Brought up 3 CPUs
SMP: Total of 3 processors activated.
That doesn't seem right. Are you using swarren's uboot with the stub prepended to it?

flag26838
Posts: 13
Joined: Wed Mar 02, 2016 12:14 pm

Re: Entering aarch64 execution state

Wed Jun 01, 2016 9:08 am

marcus_c wrote:
CPU3: failed to come online
Brought up 3 CPUs
SMP: Total of 3 processors activated.
That doesn't seem right. Are you using swarren's uboot with the stub prepended to it?
Nice catch, i didn't notice that.

No, i can't use latest swarren u-boot (or rather, u-boot master branch), or armstubs since my boards hangs at boot.

These are the steps that i take to build a working armstubs / u-boot:

raspberry-firmware @ 1.20160506 -- copy all /boot *.elf, *.bin, *.dat, etc files to the raspi3 vfat dir
raspberry-tools @ 9d4650eb910a87146362d3901f379e6afb7786bd -- in the armstubs dir:

$ echo $ARCH
arm64
$ echo $CROSS_COMPILE
aarch64-linux-gnu-
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.3.1-14ubuntu2.1' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2.1)
$ make
$ ls -la armstub8.bin
-rw-rw-r-- 1 flag flag 256 giu 1 10:52 armstub8.bin
$ dd if=/dev/zero of=padding bs=256 count=127
$ cat armstub8.bin padding > armstub8-padded.bin
$ ls -la armstub8-padded.bin
-rw-rw-r-- 1 flag flag 32768 giu 1 10:54 armstub8-padded.bin

u-boot @ c805f24f06121afbd27dce0c741ec635493d9495:

$ make rpi_3_defconfig
$ make
$ cat ../raspberry-tools/armstubs/armstub8-padded.bin u-boot.bin > u-boot-stubbed.bin

$ cat config.txt
enable_uart=1
arm_control=0x200
kernel_old=1
kernel=u-boot-stubbed.bin
disable_commandline_tags=1

# set display mode to 1920x1080
hdmi_group=2
hdmi_mode=82

the commits were taken from this message [*], and they give me a somehow working setup (the one i'm using at the moment, and the one with 3 only cpus working as you have spotted).
While if use a more recent version of armstubs (648a6eeb1e3c2b40af4eb34d88941ee0edeb3e9a) and u-boot (v2016.05), and i repeat the steps above, i get no output on console - solid hangs at boot, without a single char being spitted out.

I'm starting to wonder if that is something we should report to swarren.

*: viewtopic.php?p=950688#p950688

_BenDover_
Posts: 4
Joined: Fri Jul 17, 2015 5:48 pm

Re: Entering aarch64 execution state

Sat Jun 18, 2016 8:21 pm

Hi guys,

Can we get some sort of step-by-step tutorial on how to get it all together to run the 64-bit kernel on Rasp 3? Or at least where can we get all the pieces?

This will spare me from searching through all pages from this topic.

Thanks a lot!

LE: No need, I got it!

LLE: As @flag26838 was saying in the above comment, building everything from scratch gives 0 output on serial console. One thing I noticed was that when I'm building the armstub, the resulted file is armstub8-32.bin . That 32 at the end is asking some questions...

Some things I tried so far:

1. everything built from scratch = 0 output on serial console
2. keep u-boot from that sd image some user posted on an older page = console works, but hangs when mounting the rootfs as stated above, so something is wrong with the resulted u-boot
3. rebuild kernel with the running config from the working image = same as above, hangs when mounting
4. at this point neither the original image, nor the fresh one doesn't work anymore ( I have no idea why, it has no damn sense, but I'm too tired right now to try anything else)

dwelch67
Posts: 944
Joined: Sat May 26, 2012 5:32 pm

Re: Entering aarch64 execution state

Sun Jun 19, 2016 7:51 pm

this is a bare metal forum, for discussions where there is no operating system. No kernel...

_BenDover_
Posts: 4
Joined: Fri Jul 17, 2015 5:48 pm

Re: Entering aarch64 execution state

Mon Jun 20, 2016 6:20 pm

I appreciate your reply, but if you follow the topic, you can see what I'm talking about. :D

LE: I got it working. The changes for x64 are now in u-boot mainline, and with the latest firmware you don't need the stubbed u-boot anymore.

samtrp
Posts: 1
Joined: Sun Sep 30, 2018 2:22 pm

Re: Entering aarch64 execution state

Sun Sep 30, 2018 2:27 pm

Hi peeps!

I know this is an old thread, but I was looking for any updates.
I'll start with the method mentioned in the last comment, and also looking for any updated methods so far.

I tried SUSE Enterprise Linux arm 64, but the 7" touchscreen doesn't work on it, and the performance is bad.
Hence I've tried to compile the kernel manually, and I was stuck at U-boot for a while.

Restarting work, and will update how it goes!

Return to “Bare metal, Assembly language”