christina_b

Unless you have build servers capable of rebuilding all Qt, WebKit etc. and performing an LTO link (which pulls in all build artifacts in form of bitcode archives/objects) in a reasonable amount of time (big reason buildlabs exist - it takes a long time), LTO is not likely to be suitable, it's an extremely expensive optimization that essentially defers all real compilation until the link step at which the linker calls back into libLLVM/libLTO and have them do all the heavy lifting.

At the very least you need a workstation grade machine to be able to do that kind of stuff on regular basis, you really can't expect everyone to have that. And there's a reason libLLVM.so is usually dynamically linked, it cuts a massive amount of time spent on builds, which is especially useful while developing and it's a middle ground between building all LLVM and Clang libraries as shared objects and having to wait for static linking of various LLVM modules into every LLVM toolchain binary (which tends to result in the toolchain being much much bigger). The build cache with shared libLLVM.so for Clang/LLVM/LLD builds is around 6-7GB (Asserts/Test builds). Statically linking LLVM modules blows that up to 20GB. God forbid you actually do a full debug build with full debug information with that.

That's a terrible argument against dynamic linking. That's not to say static linking is bad, in fact, recently it's been making a comeback for exactly that reason - LTO and next-generation optimizers. But saying LTO makes static linking viable for everyone including consumers is somewhat far fetched.

If he's who I think he is, I doubt his early background is that clean, despite him being a whitehat now. It is very much possible he is being held because of something related to that and not because of anything related to WannaCry. This was all before he even started running the MalwareTech blog, it's very much possible the FBI decided to look into his background or were already familiar with it prior to him arriving in or leaving the US.

That being said, it's possible that I'm mistaking him for someone else in which case I do apologize. I edited the post a bit, to clarify, the first paragraph to the best of my knowledge is certainly true, second one is based on my own speculation so take it with a grain of salt.

1). The first stage bootloader doesn't require signing.

2). The first stage bootloader starts in EL3 mode (ie. BootROM doesn't exit it like it did on some OMAP dev boards)

Most ARM cores start in secure supervisor mode, which can transition to secure monitor mode at will (secure monitor being a special version of secure supervisor). Most bootloaders including Allwinner's will exit secure mode by setting the NS bit in SCR and therefore enter user provided code in non-secure supervisor (or hypervisor mode) which would be called EL1 (or EL2 for hypervisor) on AArch64.

EL3 has nothing to do with ROM or Allwinner or anything else, it's an execution mode defined by ARM themselves, the core is reset in that mode.

(Secure mode is also known as TrustZone, if that term seems more familiar though TrustZone is usually "the whole package" including support from the CPU and the corresponding peripherals)

My favourite is probably NVIDIA Jetson TX1 where development boards do not have a key fused in them and have documented TrustZone peripherals, so you're free to run your own secure monitor.

Sadly while ARM on rPi does start in secure mode, it lacks any secure peripherals (AxPROT[1] is forced to high so even if ARM is in secure mode, it cannot make secure bus transactions) but it's mostly a matter of principle of being able to have ARM code run in EL3 for me.

The entire point of a development board is to be able to mess around with it, I'm not wasting my time on boards with locked down features.

Support from Broadcom is unlikely to fix it, the BCM283x family of SoCs are just a huge mess and in my opinion are either suited for really specific applications (TV boxes) or as "toys".

The ARM core itself is integrated very poorly almost as an afterthought, since it wasn't in the original design, the BCM283x family is just BCM27xx family VideoCore4 VPU+QPU combinations with an ARM core hacked (and I really do mean hacked) on top.

Actually that's open and mainlined now, there are DRM drivers for BCM285x family but they rely on mailbox interfaces for power and clock management.

Yes precisely, so we offer an alternative to those blobs that allows you to boot ARM without needing a closed-source firmware.

We actually have documented most vector instructions of VC4 and Julian's toolchain supports pretty much all documented ones, so the toolchain we have is pretty close to what Broadcom would have with their MetaWare compiler for VC4.

>The RPI3 is rated for 24GFLOPS

You mean the VPU, we also have QPU and ARM on the side.

>so many really weird abnormal subsystems

True that, lack of TZPCs, ARM AxPROT[1] being forced to high causing all ARM accesses to be insecure on AXI even in secure monitor mode (sadness), lack of a GIC. I could go on and on about what's wrong with BCM283x family but hey at least it's interesting.

>But I am sincerely impressed and it has been amazing work slowly wrangling this abomination into order.

Thank you ^^

You could run Linux on ARM using this but you would need to write some more drivers, otherwise you'd be limited to pretty much GPIO/serial/SDHOST PIO.

SDHOST is actually a fairly trivial interface to implement, I'm going to use it in my chainloader but I haven't had the time to look at it yet.

This won't help you with codecs, codecs are mostly code in the firmware that uses vector instructions of the VPU to accelerate the video decoding. If you want to use the codecs I would recommend paying for them instead of engaging in piracy.

The assembler/linker I'm using is not ideal, I want to get MC code emission working eventually. I saw that you mentioned limitations on ld/st, why not use lea for data?

For example:

  BB1_12:                                 # %sdram_clkman_update_end.exit2
	mov r0, 2114982312 # long
	ld r2, (r0)
	lea r0, .str8(pc) # PCrel load
	lea r1, __FUNCTION__.sdram_init_late(pc) # PCrel load
	bl xprintf

I think I'm on the right track but I don't have ARM working yet, most likely due to clock misconfiguration. Can probably fix it when I have more time.

Sidenote, I wish #raspberrypi-internals was more active :(

  - Setting up exception vectors and enabling exceptions
  - Reclocking VPU from PLLC
  - UART initialization
  - SDRAM initialization
  - Copying an ARM blinker stub to 0x0
  - ARM power domain initialization
  - PLLB initialization
  - Enabling passthrough mapping for ARM
  - ARM AXI interface initilaization

As far as the compiler goes, I think it works reasonably well, though I only tested it by compiling my own code with it, there may be things that cause it to error out (anything that involves the frame pointer like VLAs/some C++ features). Also code quality is not ideal since it still doesn't make use of conditional instructions (aside from conditional branches) and doesn't implement AnalyzeBranch to eliminate redundant branches.

I started cleaning up TableGen to turn multi-instruction asm prints into glue DAG in SelDAGtoDAG but I still have to do it for like 4 instructions, which is pretty much a requirement to have MC code emission.

https://github.com/hermanhermitage/videocoreiv

The VPU is basically a general purpose RISC processor with some fancy vector instructions on top. In fact, most of the firmware that runs on it is written in C.

Not publishing any of the firmware work yet since it can't boot ARM yet (but SDRAM init reliably works across all boards). Once I get ARM working to some extent, I'll probably clean the code up and publish it too.