Announcement

Collapse
No announcement yet.

La Frite: A Libre ARM SBC For $5, 10x Faster Than The Raspberry Pi Zero

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

  • #21
    Has anyone looked at the video decoder support on similar boards? From what I can gather the Mali-450 has at least some support. Trying to figure out if this would make a good Kodi host.

    Comment


    • #22
      Originally posted by reavertm View Post

      And how do you plan to gain from those 64bits, given 512MiBs of memory? Sounds more like a waste than anything.
      64 bit on the Raspberry Pi 3 was marginally faster back when I was still messing with mine, although you had 1GB of ram (minus video)... not that the CPU is the real bottleneck on the Pi.

      Comment


      • #23
        Originally posted by reavertm View Post

        And how do you plan to gain from those 64bits, given 512MiBs of memory? Sounds more like a waste than anything.
        More registers. Wider registers. Double the NEON execution rate.

        Keep in mind these aren't meant to be desktop replacements, so if you're expecting to run big, fat applications, you're going to be disappointed.

        Comment


        • #24
          Originally posted by dungeon View Post

          In other words this sounds like - if they ship board without memory.price would be $0.99
          Too bad they aren't making a 4GB version then.

          Comment


          • #25
            Originally posted by caligula View Post

            Even 16Mbits would be enough to store the whole kernel. U-boot + SPL can be configured to produce a < 500 kB binary. Without U-Boot it can be smaller. You can easily fit a headless Linux in 3,5 MB when using xz compression. Maybe even include busybox and init. This is with all drivers. If you compile extra drivers (everything except mmc and filesystem) as modules, it's gonna be easy.
            Oh, agreed, you *can*, but my point is with no uSD card I can stuff in there and not buying an eMMC module, what can I do to boot it when I receive it. Does the SoC already have a boot ROM that knows how to probe USB and/or do PXE over the ethernet port? Or are they counting on the BROM to boot from the SPI and some secondary bootloader (like uboot) will take over. I can't find that info. I'm trying to get ready for when my board shows up. I'd like to know just what I need to have on hand. If the BROM only knows how to boot from eMMC, uSD, and SPI, but the SPI comes blank, then I'm up a creek without a paddle. I'd need to get out my pomona SOIC clips and rig up an SPI flash programmer and figure out what to put on it. That's a lot more work than burning a premade image on a USB stick or setting up a simple PXE boot server.

            I asked this question on Kickstarter and got this reply:
            "The SPI is flashed with u-boot. It supports network/PXE boot."
            Elsewhere they replied to someone asking about boot sources and they replied:
            "You can boot via USB sticks, USB hard drive, eMMC, or network boot."

            So, it looks like BROM knows how to boot from uSD (not on the board), eMMC, and SPI. The SPI has a secondary bootloader that knows how to network boot and boot from USB.

            That's all I'll need. I can just burn an image to a USB sitck, plug it in and be done. Yay, thanks Libre Computing Project!
            Last edited by willmore; 12 October 2018, 02:02 PM. Reason: More info from supplier

            Comment


            • #26
              Originally posted by Serafean View Post

              Pi's ethernet is connected through the USB 2.0. Making network throughput dependent on other devices connected through USB.
              To elaborate on this, all the Rpi boards have *one* USB root port--and it's not even a normal HOST controller, it's a reduced functionality OTG controller. Those with more than one port use a USB hub with a built in ethernet controller. The ethernet and all the USB ports share the one port of bandwidth to the SoC.

              Other board--like the Orange Pi--have several proper USB HOST controllers and native ethernet controllers--directly on the SoC. They don't need hubs and external USB ethernet controllers. Because of that, they don't have to share a small amount of bandwidth for their external storage and networking. Each port has it's own bandwidth. This not only allows the boards to perform better, but it makes them more consistant as there are fewer surprised because of unknown shared resources.

              Comment


              • #27
                Originally posted by NateHubbard View Post
                Too bad they aren't making a 4GB version then.
                4GB DDR4 would need to cost about $50 and then people would complain oh, why this is so expensive when for $70 there are also much better boards anyway

                Amount of RAM drives the price a lot anywhere.
                Last edited by dungeon; 12 October 2018, 02:32 PM.

                Comment


                • #28
                  Originally posted by dungeon View Post

                  4GB would need to cost about $50 and then people would complain oh, why this is so expensive when for $70 there are much better boards

                  Amount of RAM drives the price a lot anywhere.
                  Let them complain. I'd buy one.

                  Comment


                  • #29
                    Originally posted by willmore View Post

                    More registers. Wider registers. Double the NEON execution rate.

                    Keep in mind these aren't meant to be desktop replacements, so if you're expecting to run big, fat applications, you're going to be disappointed.
                    More registers is not something that comes with 64bit by design, it's just perhaps a property of arm64 vs arm32. And gain from wider registers may be offset with overhead in memory addressing (upper 32 bits of each address are never used as I understand, unless cpu does some magic with it). To me, transferring those never used bits are just wasted electrons, dead weight. 1GiB can be addressed directly with 32bit pointers. Perhaps arm supports x32 abi-like mode?
                    Last edited by reavertm; 12 October 2018, 03:23 PM.

                    Comment


                    • #30
                      Originally posted by reavertm View Post

                      More registers is not something that comes with 64bit by design, it's just perhaps a property of arm64 vs arm32. And gain from wider registers may be offset with overhead in memory addressing (upper 32 bits of each address are never used as I understand, unless cpu does some magic with it). To me, transferring those never used bits are just wasted electrons, dead weight. 1GiB can be addressed directly with 32bit pointers. Perhaps arm supports x32 abi-like mode?
                      Most addressing on ARM is through registers or with offsets embedded in the code. Yes, sometimes you need to store a full pointer to memory, but it's not as bad as people make out.

                      For ARM, there are more registers in 64 bit mode. That is part of the AARCH64 design. Since we're talking about an ARM board, that should be understood from context. There may be an arch that went from 32 bit to 64 bit and didn't increase the number of registers, but none come to mind. Maybe SPARC could be said to have done that as it used a window into a larger sliding set of registers and the window size may not have changed--I'm not a SPARC expert, I haven't touched it since the early 90's.

                      ARM does support a 32 bit addressing, 64 bit data mode, but I'm not aware of anyone actually using it as it's not really worth all the support effort--recompiling the world and kernel support.

                      Most architectures were designed by people who knew that just doubling the size of everything wasn't a good idea and they went through a lot of effort to lessen the burden.

                      Comment

                      Working...
                      X