Announcement

Collapse
No announcement yet.

The Arm SoC/Platform Changes Finally Sent In For Linux 5.3: Jetson Nano, New SoCs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by schmidtbag View Post
    If you think that sounds bad, I suspect RISC-V won't be much better. That may be open source, but the tweaks companies make to it don't have to be.
    Taking the example from ARM...
    I'm Afraid that it will be a lot worse then with ARM

    Comment


    • #22
      Originally posted by starshipeleven View Post
      Are you also aware that in most SoCs the initialization phase is 99% dealt with by a bootROM which is integrated in the SoC itself and can already initialize the system and load a payload (usually a bootloader to boot an OS) from any available storage medium connected?
      The SoC bootloader usually does nothing more than load the first page of selectable known storage device (nand, emmc or nor flash), verifies it's signature and starts that.
      That portion will probably set up some things and load the nexts loader which might just be uboot.
      Uboot's initialization must already know RAM to setup the RAM controllers, and to be able to load itself. Then it needs to know how to setup the storage controllers and other busses wherever the payload may be. uboot will set up the DTD (like ACPI, but more advanced, less bugs, but very very dynamic), load the kernel and start it.
      Starting with ARMv8 there were some bolt statements about bootloaders afaik, so now uboot also has to decompress any initramfs, because the kernel is incapable of unzipping the initramfs nor is it capable to unzip the kernel.
      So yeah, no, it really is outside the scope of any generic software developer. Every system has it's own very specific way of booting. The defacto bootloader is uboot.
      Anyway, what it boils down to: the loader in a SoC is in 99% of the cases comparable of jumping to FFFF0h in real mode to start the BIOS. Incapable of doing anything because there is no memory, no stack, nothing.
      What happens next used to be open, but is now 100% proprietary on any intel architecture. It's the same on ARM.
      Heh, I even have a dual stage redboot bootloader on one of my devices, and I think a saw ecos somewhere, but it might have been abused as operating system even.

      Comment


      • #23
        Originally posted by Ardje View Post
        The SoC bootloader usually does nothing more than load the first page of selectable known storage device (nand, emmc or nor flash), verifies it's signature and starts that.
        Afaik on most things I've seen it's more advanced than that, and it is initializing more or less everything on its own. Marvell and NXP hardware for example. Atheros, Allwinner and Rockchip hardware.
        For example on Marvell hardware starting from Kirkwood onwards (old ARMv5 single core) it's also able to talk over TTL serial and (slowly) load a bootloader over the serial using xmodem protocol (you use a tool called kwboot from a PC to send this bootloader over), and I've seen their uboot source, most init code is skipped and the uboot is just a bootloader.
        On Armada and more recent SoCs the BootROM can load the payload bootloader from USB, SPI chip, Sata or eMMC and you select that with pins you pull up/down.
        This is also true for old Atheros SoCs like the AR9331, and it allows you to do the same for deciding if USB is initialized as host/guest (and the Linux system can't swap this later). And also the RAM init is generic and you can freely swap RAM chips with bigger ones and they will be detected at the correct size and used, and again uboot code is skipping init of that.

        uboot will set up the DTD (like ACPI, but more advanced, less bugs, but very very dynamic), load the kernel and start it.
        I'm not sure what "set up the dtd" means here. It's either loading a dtb file and either appending it to the kernel (legacy dtb boot) or using a standard interface to pass it to the kernel, end of what it does.
        Last edited by starshipeleven; 30 July 2019, 03:51 AM.

        Comment


        • #24
          Originally posted by starshipeleven View Post
          I'm not sure what "set up the dtd" means here. It's either loading a dtb file and either appending it to the kernel (legacy dtb boot) or using a standard interface to pass it to the kernel, end of what it does.
          Well, uboot can dynamically alter the dtb, as uboot is in a position it knows a few things (same SoC, different model). And yes, it is setting up: you prepare the image at a board specific memory position, and hand over the pointer to the kernel. On ARMv8 everything needs to be decompressed by the bootloader as well, so you need a lot more of setting up, and the bootloader also needs to know the more esoteric compression algorithms. ARMv8 also doesn't allow concatted initramfs images AFAIK.
          Anyway: the Arm's I know probably load the first stage bootloader in cache, because you can't initialize a memory controller if you have no clue about how it is attached. My intel NAS "loads" redboot from nor flash (it's just runs it), then redboot needs to initialize the memory controller before it can do anything else. The setup it uses to run redboot from nor flash also prevents me from going full force and change redboot into accepting 1GB DIMM instead of 512GB DIMM. Because if I fuck that up, I need to use jtag to flash the rom loader.
          The rom based redboot loads the ram based redboot, which gives me tftp access if I need it. It in turn loads a stripped kernel from nor flash, which can finally access the sata bus and then that linux kernel can load the real operational linux kernel from disk and boot that using kexec. I can use the rom loader to download images using X-modem, but the point is: redboot initializes memory to be able to download to.
          Final point: generically a SoC doesn't know the memory that's connected to it, so it would be unable to initialize and use it, unless you have told it somehow using more flash, or if it is a vendor specific system (POP's), or if it has on board sram. And it's all SoC dependant. So there is a 99.9% chance that if you can download to memory it is by using a second stage bootloader like uboot's (pre) init that has already initialised memory. Or uboot is the third stage bootloader. On RPI the main CPU loads the second stage from microsd, which in turn initialises memory and then continues loading, and finally starts the application processor (the ARM part).



          Comment


          • #25
            Originally posted by Ardje View Post
            Well, uboot can dynamically alter the dtb, as uboot is in a position it knows a few things (same SoC, different model).
            It could, but for most hardware I've seen (for example all boards supported by Armbian, and all hardware supported by OpenWrt) this is far from a requirement, and it can just boot with a board-specific dtb that is not touched by the bootloader.

            And yes, it is setting up: you prepare the image at a board specific memory position, and hand over the pointer to the kernel.
            That's just loading stuff in RAM, not "setting up", but maybe I'm just nitpicking.

            On ARMv8 everything needs to be decompressed by the bootloader as well, and the bootloader also needs to know the more esoteric compression algorithms. ARMv8 also doesn't allow concatted initramfs images AFAIK.
            I'm not sure how a processor arch (ARMv8) can dictate what the bootloader does, or that the Linux kernel must be uncompressed.
            I mean, the bootROM only executes raw code from some source (loading it to RAM first or not, usually yes nowadays). It's far too dumb to load an actual OS, and it's not supposed to. From that point on the bootloader can do whatever it wants.
            an example of initramfs boot on ARMv8 http://weng-blog.com/2017/03/ARMv8-manual-boot/

            Anyway: the Arm's I know probably load the first stage bootloader in cache, because you can't initialize a memory controller if you have no clue about how it is attached.
            Afaik devices with a bootROM do a execute-in-place from the internal ROM as it's fast and small enough (and they don't have much choice anyway).
            I've seen enough cases of L2 caches being disabled on boot while RAM most definitely was usable, and caches had to be enabled by the u-boot bootloader by writing some magic to a register.

            My intel NAS
            Are you saying Intel ARM? That's some pretty old and discontinued stuff.
            If it's x86 then all the initialization is done by FSP blobs and redboot is just a bootloader tasked to load a kernel.

            the point is: redboot initializes memory to be able to download to.
            My point is, in more modern SoCs the RAM and peripheral init is handled by the bootROM which is a true ROM containing some unknown code and is inside the SoC. The bootloader (usually uboot) is not doing initialization and sits on a storage media like NOR/NAND flash or USB/SDcard/eMMC/Sata.

            Final point: generically a SoC doesn't know the memory that's connected to it, so it would be unable to initialize and use it,
            The only unknown is the RAM size. The controller is known. Atheros SoCs just run a full RAM address space scan when initializing RAM controller, and this allows them to auto-sense the RAM size.

            There is a 99.9% chance that if you can download to memory it is by using a second stage bootloader like uboot's (pre) init that has already initialised memory. Or uboot is the third stage bootloader.
            uboot can be even a tenth stage bootloader (and if we are talking of modern ARM where there is also Trusted Boot yes it gets funny https://chromium.googlesource.com/ex...ware-design.md ), the point I'm making is that most of the SoC init is handled by the bootROM, as the "TTL recovery" or "USB OTG recovery" functionality functions even if you hose or physically remove the whole flash, see here an example for the Allwinner hardware. https://linux-sunxi.org/BROM that when you trigger the recovery mode https://linux-sunxi.org/FEL makes it show up as USB on a PC, so you can load the bootloader image.

            Look at the output, it has initialized RAM and it knows its size
            HELLO!
            BOOT0 is starting!
            boot0 version : .3.0
            dram size =1024
            Succeed in opening nand flash.
            Succeed in reading Boot1 file head.
            The size of Boot1 is 0x00036000.
            The file stored in 0X00000000 of block 2 is perfect.
            Check is correct.
            Ready to disable icache.
            Succeed in loading Boot1.
            Jump to Boot1.

            On RPI the main CPU loads the second stage from microsd, which in turn initialises memory and then continues loading, and finally starts the application processor (the ARM part).
            yes, the "bootcode.bin" which is what, 50kbytes? What's the size of the bootROM in the Allwinners again? 32 KiB. Are you seeing a pattern yet?
            Last edited by starshipeleven; 30 July 2019, 08:15 AM.

            Comment

            Working...
            X