similar to: Syslinux Aarch64 porting

Hi, Is there any information available on porting Syslinux to 64bit ARM? Specifically, I have a Cavium ThunderX board (Gigabyte R120-T30) which boots using UEFI - b2b.gigabyte.com/products/product-page.aspx?pid=5864#ov I'd be very interested in getting this to work, as currently the only option for booting on this platform is Grub 2 or EFI Stub. If anyone can point me in the right

Michael Davies wrote: >Is there any information available on porting Syslinux to 64bit ARM? > >Specifically, I have a Cavium ThunderX board (Gigabyte R120-T30) which >boots using UEFI - b2b.gigabyte.com/products/product-page.aspx?pid=5864#ov > >I'd be very interested in getting this to work, as currently the only >option for booting on this platform is Grub 2 or EFI

Hi Steve, I don't know if syslinux is x86-only by design, or just by circumstance. Simply put, I like syslinux because it's simple and it works. I know that once I get it working, I can just edit a config file and put kernels/initrds in the right place. Grub2 is trash[1], and UEFI is awkward and uncomfortable to actually use - in that I have to currently have my kernel and initrd on

Hello, It looks like xen 4.1.2* has some problems with solaris 11 iso images too (s. further below log messages) hvm-solaris11.born2b3.net.cfg # --- kernel = ''/usr/lib64/xen-default/boot/hvmloader'' builder = ''hvm'' device_model= ''/usr/lib64/xen-4.1/bin/qemu-dm'' name = ''solaris11hvm.born2b3.net'' acpi =

To give you a proper answer, I'd need to know if you're looking for 64bit arm (aarch64/arm64) support or 32bit armhfp support. Assuming 64bit, we support Applied Micro's X-Gene family of processors, Cavium's ThunderX, as well as Qualcomm's QDF 24xx line. We maintain support for the AMD Seattle SoC as well, but that doesn't appear to be getting updates that I know of. We

I am pleased to announce the general availability of CentOS Linux 7 (1611) for AArch64/ARM64 machines. == Changes The kernel has been rebased from 4.2.0 to 4.5.0, and includes several patches recently merged into the upstream. The kernel patches and modifications can be found at https://git.centos.org/summary/sig-altarch!kernel.git in the sig-altarch7-aarch64 branch. == Download You can

Send CentOS-announce mailing list submissions to centos-announce at centos.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request at centos.org You can reach the person managing the list at centos-announce-owner at centos.org When

When I pass an empty string for cpu and features to createTargetMachine, and then use LLVMGetTargetMachineCPU() and LLVMGetTargetMachineFeatureString() to get the strings back, they are still empty. Is there a way to have llvm compute the effective cpu/features string, and provide it so that I can inspect it? I'm trying to figure out how the cpu/features string that I am explicitly passing,

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 FreeBSD Project Quarterly Status Report - 3rd Quarter 2016 As focused as we are on the present and what is happening now, it is sometimes useful to take a fresh look at where we have come from, and where we are going. This quarter, we had our newest doc committer working to trace through the tangled history of many utilities, and we

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 FreeBSD Project Quarterly Status Report - 3rd Quarter 2016 As focused as we are on the present and what is happening now, it is sometimes useful to take a fresh look at where we have come from, and where we are going. This quarter, we had our newest doc committer working to trace through the tangled history of many utilities, and we

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost head: 96bcd04462b99e2c80e09f6537770a0ca6b288d0 commit: 96bcd04462b99e2c80e09f6537770a0ca6b288d0 [20/20] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT config: ia64-allmodconfig (attached as .config) compiler: ia64-linux-gcc (GCC) 7.2.0 reproduce: wget

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost head: 96bcd04462b99e2c80e09f6537770a0ca6b288d0 commit: 96bcd04462b99e2c80e09f6537770a0ca6b288d0 [20/20] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT config: ia64-allmodconfig (attached as .config) compiler: ia64-linux-gcc (GCC) 7.2.0 reproduce: wget

In trying to package up LLVM for Debian, it appears that x86_64 is no longer a supported architecture -- so, my first question is, is that correct? Best I can tell, the only thing that's supposed to work for x86_64 is the C backend. For Debian, I need to build everything from scratch. When trying to build llvm-gcc4 from source, though, I get part way through the build and am told that

Hello, I would like to know which ARM processors does CentOS support? Does it support Freescale/NXP? Thanks and regards Jay

[mod: Forwarded by Jeff Uphoff. I tried to mangle the headers that it appears as the original post: with an invalid return address. -- REW] A few months back, a very alpha version of bliss got posted. That shouldn''t have happened, but, it was pretty much ignored so I didn''t worry about it. But now it seems there''s a bit of a fuss about this. I''ll post the

The saga continues. I've been tracking the interface changes and merging them with the refactoring work I'm doing. I got as far as building stage3 of llvm-gcc but the object files from stage2 and stage3 differ: warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs (Are the above two ok?) The list below is clearly bad. I think it's every object file in the

Nearly any program that writes to standard output can benefit from this sort of fix. Without it, running e.g., ./guestfish --version > /dev/full would exit successfully, even though it got ENOSPC when writing to the full device. That means regular output redirected to a file on a full partition may also fail to be written, and the error ignored. Before: $ guestfish --version >

On Apr 27, 2007, at 3:50 PM, David Greene wrote: > The saga continues. > > I've been tracking the interface changes and merging them with > the refactoring work I'm doing. I got as far as building stage3 > of llvm-gcc but the object files from stage2 and stage3 differ: > > > warning: ./cc1-checksum.o differs > warning: ./cc1plus-checksum.o differs > >

I recently got a tegra TK1 and was curious how fast it was compared to my previous arm "build machine": the original arm Samsung chromebook. I timed running ninja to build just llvm in Release+Asserts using clang as the host compiler. chromebook: real 84m30.939s user 163m50.145s sys 4m0.100s TK1: real 34m7.376s user 132m44.417s sys 3m3.543s A really nice

I guess that in this case, what I would like to know is a reasonable upper bound of the cache line size on the target architecture. Something that I can align my data structures on at compile time so as to minimize the odds of false sharing. Think std::hardware_destructive_interference_size in C++17. Le 11/03/2017 à 13:16, Bruce Hoult a écrit : > There's no way to know, until you run