Announcement

Collapse
No announcement yet.

That Open, Upgradeable ARM Dev Board Is Trying To Make A Comeback

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

  • Originally posted by lkcl View Post
    iiinteresting. perhaps they're starting to get it, after all. now all they need to do is bring out SoCs that don't have gaping security vulnerabilities at the hardware level - https://slashdot.org/story/16/05/05/...roid-user-data

    althouugggh... that might just be the case that you simply don't use that vulnerable hardware engine and it's fine...
    basically, yes. And fortunately all of qcom's SoC's where are available in the catalogue market are the non-modem variants.

    Originally posted by lkcl View Post
    darn it, robclark, you're convincing me to investigate the 410 properly mind you, i do have to say, it's still going to take around $20k and 4-6 months because they don't have PCB CAD Reference Designs available to work from. and i have to get through this campaign first, but yeah - a 5-10 year lifespan is worthwhile pursuing.

    so, thank you! really grateful to you for finding that the SoCs and PMICs are available on arrow, that's a definite "tick" on hte checklist. and it's got a reverse-engineered 3D GPU, that's *really* good.
    Between linaro and qcom (and a couple sony/xperia folks), qcom definitely gets the "most improved" award. Their upstream situation is coming together nicely. On the apq8016 (and other newer "B" family devices) they are even working on upstreaming the video dec/enc hw.

    From a driver-writer perspective, I rather like the qcom hw... iommu's everywhere is nice (and not having to deal w/ carveouts/cma).. I think pretty much all the blocks that have fw blobs sit behind a cpu/linux controlled iommu, so at least if you steer clear of the parts with modems they don't really live up to their "spooky" reputation..

    Comment


    • Originally posted by unixfan2001 View Post
      I've explained this to you in the other thread.
      As of current, Firefox add-ons run inside the chrome. The chrome has, for the most part, privileged access to your system resources (with very little protection in its way).
      It's not unreasonable to assume that someone would write an addon trashing your machine. In fact, accessing libc and other shared objects is painfully simple, so with some creative coding I could easily trash your filesystem or even just reboot your computer from in there.

      It's why Mozilla is getting rid of the current addon system and it's also why they require signing for it.
      Can I add something to this?
      On Windows there are already at least 4 pieces of %&%£$ adwares that add their own plugin to snoop on you, lockdown other ads and carpet-bomb you with their ads while you browse.

      By carpet-bomb I mean that more than 50% of screen space of firefox is occupied by flashy, annoying, animated ads. I know that for the average user it's normal browsing experience, but I was getting worried someone managed to sidestep all-powerful ublock origin from server-side (truly worrying event).

      On windows it's a trend, and this trend has to fucking stop. Now with the signing these %&&%£ can no more do this.

      On Chrome it's also the same, I had to force-reset quite a few Chrome browsers to nuke a stupid adware plugin.
      I don't think they have yet implemented this signing.

      Comment


      • Originally posted by SystemCrasher View Post
        Greetings. Uhm, I could be a bit rude/trolly, but at the end of day I'm really up for crap-free computing and care about it :P.
        good enough for me

        Chinese SoCs are interesting by the fact most china companies are putting more efforts into just doing good CPUs and virtually zero efforts in doing treacherous or troublesome or just overengineered crap. That's what I like about them. Relatively easy to understand what's going on and it often happens to be more or less crap-free.
        ... because they're realistic about the fact that the factories have absolutely no clue about what they're making: it might as well be spoons or baggy pants. allwinner's engineers might get called in to sort out some mess they've made by ignorant tinkering: if it's treacherously locked down there's absolutely no way they could do that.

        we benefit indirectly from that...

        Speaking for myself, there're quite few SoCs I would really appreciate,
        if you've got a list in mind tell me what they are, i can go through the checklist.

        But EOMA68 was never meant for laptops.
        it is... but i have to be realistic about what i can get hold of, what's available and so on, and also think ahead - take a calculated risk.

        USB 3.x is unpopular in cheap SoCs,
        i've just seen that it's in some of the newer Rockchip SoCs which is good news. i was anticipating a slow trickle-down as the hard macros from Cadence, Synopsis and Mentor Graphics and so on mature and become affordable.

        hi-end SoCs implementing it are bring plenty of other issues, ranging from poor mainline support to overengineering and treachery.
        argh i heard about how the drivers for peripherals are requiring real-time check-in online to download firmware.... argh....

        Then price really matters and somehow just SBCs or modules are easier to connect to particular application, cheaper and far more popular/available.
        i take the long-term view, that modules save people money long-term, that they give people choice, and that upgrades end up being cheaper because you don't throw everything away. i've talked to hundreds of people personally and they really like that. you can also look up "Phonebloks" - they got 900,000 supporters and reached over 350 million people with a modular phone *concept* - not even a product! so we know that people really *really* are fed up and want modular computing appliances.

        It is hard to disregard these facts if I'm trying to get things done. Real world is tricky and there're no perfect solutions. Sometimes one have to make tough decisions.
        that's for sure.

        If someone wants to spin off crap-free SoCs, especially opensource, they are really welcome.
        what i really want is a crap-free SoC that itself isn't crap... important to make that distinction i think

        Comment


        • Originally posted by SystemCrasher View Post

          So user does not misses alarm/reminder even if device has been powered off. This isn't evil on its own, though one could abuse RTC wakeups by causing unexpected system boots. It comes to question who controls SW in system. And relatively easy to spot. Realistically, nearly all microprocessors and microcontrollers got RTC HW and it behaves like this. I guess one could achieve same behavior on Allwinner, it surely got RTC and AXP20x know not to power off RTC LDO either. Not sure it going to work everywhere to full extent. Say, most AW boards lack RTC backup supply but would keep RTC running as long as main power presents.
          i dealt with that in the laptop housing (aka "dock") by adding in an STM32F072 (which cannot be DRM-locked), it's powered continuously from the battery, it has RTC functionality and wakeup.... but critically the firmware is entirely LGPLv3+ (libopencm3) and GPLv3+. NO spyware. http://git.rhombus-tech.net/?p=eoma-...s/heads/master

          Most cell modems are backdoored, roughly since some point of 3G. So if one loves fucked-up architectures, taking SoC with integrated cell modem and GPS is a good bet to win RRLP jackpot. If something lacks cell modem it can't behave like this, obviously. IIRC qualcomm had some app processor(s) without cell modem, but since they're not cheap or widespread I had little reasons to investigate further. Most Qualcomm SoCs I've met were cell modem first, everything else second. If there're some better Qualcomm processors, I could imagine some of them aren't evil.
          jaezuss. *sigh*. well it looks like, from robclark's investigations, that qualcomm are actually making an effort, and he says (above) their catalog parts don't even have modems at all.

          Nice. Though when it comes to laptops I'm not really sure EOMA68 is a good idea. Strongest points of A20 are SATA and Gigabit, everything else is quite boring. Actually I prefer to use it when I need decent net and storage. It isn't bad in other things, but these two are well above of any competitors I could think of.
          *sigh* yeah. i did work on a standard called EOMA200 (still in development) - http://elinux.org/Embedded_Open_Modu...cture/EOMA-200 - but it's a desktop standard (not a portable one), similar to COMExpress. COMExpress is *nice*. none of the interfaces are "optional" which instantly kills a standard stone-dead.

          the thing is, once you wander into SATA and GbE territory, pricing goes up massively, power goes up, complexity goes up. i had to make that call to stick within what i could reasonably achieve on a reasonable budget without *any* VC funding.

          we'll bootstrap up to more powerful standards and modules... but i gotta start somewhere, y'know?

          Comment


          • Originally posted by robclark View Post

            . And fortunately all of qcom's SoC's where are available in the catalogue market are the non-modem variants.
            ah _good_. ok so it's starting to look like it would make quite a nice spyware-free and possibly even a libre-compliant SoC. which is hilarious given qualcomm's prior record. well, being realistic, we can either boycott them and blame them for being muppets in the past... or we can "reward" them for good behaviour (by making systems based around this style of SoC), get it out there and thus indirectly give them the message that if they repeat the exercise they'll be rewarded again.

            Between linaro and qcom (and a couple sony/xperia folks), qcom definitely gets the "most improved" award. Their upstream situation is coming together nicely. On the apq8016 (and other newer "B" family devices) they are even working on upstreaming the video dec/enc hw.
            niiiice. hmmmm.... http://www.96boards.org/forums/topic...ding-in-linux/ hmmmm.... nobody's explicitly asked, "is this entirely libre so that we can guarantee there's no security flaws and vulerabilities in it? these video engines typically have arbitrary and full access to system memory".

            Comment


            • Originally posted by starshipeleven View Post
              Can I add something to this?
              On Windows there are already at least 4 pieces of %&%£$ adwares that add their own plugin to snoop on you, lockdown other ads and carpet-bomb you with their ads while you browse.

              By carpet-bomb I mean that more than 50% of screen space of firefox is occupied by flashy, annoying, animated ads. I know that for the average user it's normal browsing experience, but I was getting worried someone managed to sidestep all-powerful ublock origin from server-side (truly worrying event).

              On windows it's a trend, and this trend has to fucking stop. Now with the signing these %&&%£ can no more do this.

              On Chrome it's also the same, I had to force-reset quite a few Chrome browsers to nuke a stupid adware plugin.
              I don't think they have yet implemented this signing.
              Not to rain on your parade or scare you, but those things would probably still be possible on Firefox' signed infrastructure. If to a lesser extent and more difficult to implement.

              Only type 2 add-ons (extensions) require signing. Those are the kind of add-ons that go way beyond the ability of your browser. They can access your file system, read stdin, write to stdout/stderr and even utilise functions exposed by shared objects*. They're the ones that signing tries to protect against. The kind of "peanuts" you talk about is still within reach of the enterprising cracker.


              *Shame Mozilla never seemed to have realised just how good their framework would be as the basis of an OS and how horribly overpowered it is for a browser.

              Comment


              • Originally posted by unixfan2001 View Post
                Only type 2 add-ons (extensions) require signing. Those are the kind of add-ons that go way beyond the ability of your browser. They can access your file system, read stdin, write to stdout/stderr and even utilise functions exposed by shared objects*. They're the ones that signing tries to protect against. The kind of "peanuts" you talk about is still within reach of the enterprising cracker.
                The ones I talked about were extensions, showing up in extensions tab and all. Not malware but adware. Technically legit.
                They were removable, but some mothership adware program somewhere was reinstalling them automatically.
                Pests, nothing more. For a certified professional anyway. For users they are a pain.
                So the Mozilla move is justified. Having to bring your PC to someone to do pest control scans isn't cool.

                *Shame Mozilla never seemed to have realised just how good their framework would be as the basis of an OS and how horribly overpowered it is for a browser.
                (thinks at FirefoxOS)
                (cries loudly)
                Last edited by starshipeleven; 05 July 2016, 03:13 PM.

                Comment


                • Originally posted by starshipeleven View Post
                  (thinks at FirefoxOS)
                  (cries loudly)
                  Firefox OS was a waste of potential.
                  Should've optimised XUL for mobile use and improved re-use of desktop code.

                  That being said Firefox OS is actually still around as B2G (Boot to Gecko). It's merely the mobile offering that was liberated to the wider community.

                  Comment


                  • Originally posted by lkcl View Post
                    niiiice. hmmmm.... http://www.96boards.org/forums/topic...ding-in-linux/ hmmmm.... nobody's explicitly asked, "is this entirely libre so that we can guarantee there's no security flaws and vulerabilities in it? these video engines typically have arbitrary and full access to system memory".
                    I think there is a fw blob (although not sure if I've ever seen a video dec/enc block that didn't have some sort of fw), as with the gpu.. and as much as I'd prefer the fw to be open too, at least in both cases the hw block is behind an iommu that is controlled by the linux kernel, so no unfettered access to system memory, which is the more important thing.

                    Comment


                    • Originally posted by kaprikawn View Post

                      Wait, what? They're trying to get FSF accreditation on a device using components from a known GPL violator? That's brazen to say the least.

                      Cool concept, let down by the fact that they're using Allwinner tech.
                      They're trying to get FSF accreditation on a device using one of the few relatively modern SoCs that's actually usable without any binary blobs. Yes, really. Part of the reason Allwinner had so many complaints about GPL compliance is that their hardware holds a lot fewer secrets than competing systems - for example, suspend-to-RAM works by jumping into a special piece of code that runs outside the OS environment and with access to RAM disabled, just like on x86, except that unlike on x86 this is ordinary code you can replace rather than part of a locked-down BIOS image running partially in System Management Mode where it can't be touched by normal end users. Which is why people insisted not having the source for it was a GPL violation but the much less free x86 equivalent is fine.

                      You lose hardware 3D acceleration (2D acceleration is theoretically doable if someone wants to write a driver - that accelerator's documented) but pretty much everything else is open source now, even supported in the mainline kernel in many cases.

                      Originally posted by starshipeleven View Post
                      This is 2016, not 2012. Raspi 3 laughs at this and is mostly opensource now.
                      All versions of the Raspberry Pi require a proprietary binary blob running on a proprietary processor on order to even boot the damn thing. At one point the Pi Foundation were considering working around the FSF's requirements by sticking that binary blob (which, it should be noted, is running with full access to RAM whenever you're using the system) in a write-protected flash chip where users couldn't upgrade it, but they gave up on that idea.

                      Comment

                      Working...
                      X