Hacker News Reader

> I'm pretty sure they chose the i.MX8 because they couldn't source Snapdragons

I'm pretty sure that it was expressly chosen because it's reasonably documented unlike most SoC chips. Not that this solves the expense and effort with iterating hardware, of course.

Back when it was Freescale, I don't remember their documentation being that much better than Qualcomm's. The software support sure was better at first but given the RaspberryPi community size, I think it'd be a wash - although I don't know when LibRem started development. The biggest difference I experienced was that you could download iMX documentation along with all the reference designs without breaking into a Freescale employee's house or proving to one of their account managers that you could sell millions of units.

That is, by far, the thing I loved the most about the i.MX6 design I worked on: it was a high cost low volume board, but we could still get parts from Digikey and just download the reference material off the website. A company like Qualcomm wouldn’t have given us the time of day.

The raspberry pi is based around a graphics chip with a proprietary threadx based operating system. Librem's "software support" standards are high enough (no proprietary software) that this qualifies as worse support than a random Allwinner SoC.

This project feels like how the Pandora project was. It was expensive for it's time, promised to do cool things and then was in suspended animation for years while the world changed. Snapdragons got mainlined. Phones got cheaper. Other Linux phones that worked completely came out. They should have delayed it and just put in a mainlined snapdragon processor.

Easier said than done. As of few years ago, Qualcomm wouldn'y really talk to you unless you can guarantee at least 100k unit purchase- which gets quite expensive fast at ~30-40$/pc for a mid range SoC.

At the point where we got access to documentation and very basic support, around $1M USD was paid (part of which was covering the initial shipments of chips though).

It's funny you mentioned Pandora actually. I backed the open Pandora and when I first got it, I was severely disappointed. I think I threw it into a desk drawer for a couple of years and I stumbled upon it. When I opened it I was surprised to see it was still an active community and the device was not only usable but actually a joy to use! I used it has a laptop for a long time until a lost it (oops).

I should check on the pyra and see how that is.

That's just reminded me that I also backed the Pandora, waited ages (years?) and then when I got it I had moved on in need, and I was really disappointed in it. I sold mine within days, and the only upside was it was really profitable to do so as they were still in heavy demand at the time.

I thought I'd check on the project while writing this (every now and then I come across something that reminds me of it), and I see that the Preorder FAQ for the Pyra looks exactly like the one that was up for the Pandora for (what seemed like) years!

It's getting pretty close: https://pyra-handheld.com/boards/threads/production-pyra-pho... :)

That really makes me miss my pandora......

I'm having a hard time reading the last part. You lost your laptop? What made you disappointed?

Ahh sorry! The openpandora was my laptop, it was incrdibly small and worked really well for that. I also had a small USB keyboard i I needed to sit down and type longer.

I lost the open pandora, and that was a sad day.

And NXP is generally considered a very good vendor to work with!

Yes, only because the reference point is the average of all manufacturers :-)

Last time I checked, they hadn't corrected the documentation of their previous line of SoCs (almost 10 years old), despite acknowledging the errors I reported many ears ago. You can either consider that personal support was good, or that, by not correcting stuff they know is false, they don't give a damn about wasting every other user's time (and wasting the support staff time again and again each time a user will ask the same question).

I also remember using a simple piece of software from them (a GUI for pins assignment, which basically consisted of a list of checkboxes, or some kind of simple spreadsheet if you want): that super basic thing leaked several gigabytes of memory per hour, just idling. Well, I couldn't let it on 1 hour, I had to take the habit to stop and restart it after 15-20 minutes...

I've been around the block in major, Top 10 silicone companies.

The app you talk about was probably developed by some summer intern on a tight schedule and never documented, then someone else took over.

They literally don't give a flying fuck about software. One manager I had once was so clueless, he couldn't understand that the GUI of the C# app I made had no code behind it, and kept asking why clicking the buttons isn't doing anything no matter how many times I tried to explain that a GUI can exist without functionality and it's a separate effort to implement that.

Certain apps we were using internally were based on same Java version from 12 years ago since the person who developed it is now a senior line manager and also the sole maintainer.

Then they brought in some Agile/Scrum consultant to increase efficiency and he implemented 45 minute daily stand-ups with 10 people and half of them remote via phone from another country and then he spent most of the day chasing us around the building asking how soon story X will be done. Then they outsourced the whole thing to Poland.

Working in that industry as a SW developer has been a colossal pain and a huge setback for my career I try to slowly erase from my resume.

> Top 10 silicone companies.

Silicon, lest anyone think you were working in a different industry.

I can't believe I forgot to mention the errata! A mentor got so pissed off at Qualcomm one time that he delayed the start of his next contract by a month so he could farm a list of professional electrical engineers working for companies that use Qualcomm chips and developed a relationship with many of them just to create a secret errata sharing network of EEs that were covered under Qualcomm's NDAs. Even a few lawyers at one of the biggest companies who got wind of the idea decided it was worth the risk.

Sadly he passed away before he had the time to really get it off the ground.

> Silicon manufacturers have very little respect for software and it really makes the entire process a lot more painful than it should be.

Do you know why? In my eyes that would make them a crazy unattractive supplier.

I don't know much about that side of the industry so this is only what I've gleamed from mentors and account managers at suppliers: silicon fabrication is extremely conservative and naturally monopolistic because of the sums of money involved and these two factors interact in weird ways. The gross margins on chips are 90%+ but because of the large amounts of upfront capital, they have to strike a balance between derisking the R&D and maximizing profit. Since it is so expensive, demand for specialized chips can only support so many customers per design which limits competition and redesigns are so expensive that clients are locked into their suppliers. The vendors know this and they know that hardware designs are locked in whereas customers have a lot more control over their software so when it comes to derisk the project, investment into software quality is always the first to get cut to the bone. Afterwards, due to that derisking, most of their software engineers spend time chasing bugs in the barebones software and supporting customers so they never get to invest in the software after release before they have to move onto the next product.

This isn't the kind of environment you'd find many passionate software engineers because most of them leave for greener pastures unless they really care about the product they're working on, but they're rarely qualified to run developer experience departments.

Sounds like the silicon fabrication industry is ripe for disruption ala Stripe / Monzo. May be, since you know so much, you should build one. :)

You spoke of the Basebands...that reminded me that Fabrice Bellard works on the other side of the equation [0]. May be, if we are lucky, he turns his attention to fixing mobile phones [1].

[0] https://www.amarisoft.com/about-us/

[1] https://osmocom.org/projects/baseband

I wish! I've actually looked into it and there's lots of interesting work in academia and garages on small scale, low cost silicon fab [1] as well as the electron microscopy necessary to do quality control [2]. Last I checked the state of the art was using regular microscopes with Texas Instruments digital micromirror devices from projectors with basic photoresist and etchant. The DMD reflects light from your light source onto the wafer with the resist and you can control the micromirrors like pixels to only reflect light at the pixels you want to expose the resist. The doping is doable with basic vapor deposition but alignment between steps is brutally hard and the doping requires a lot of tuning and environmental stability to get right so the feature limit is 1 micrometer at best.

I even found a TI 1080p UV DMD and bought a roll of lithographic film to try to get that feature size limit down. My plan was to expose the litho film instead of the wafer directly and build very precise jigs for the film off of a precision machine base I could get for a few grand, with custom built linear motors to move between steps but I got stuck on the physics and math. It looked like I had a solution using neural networks and a DIY laser interferometer as the feedback loop as a shortcut to learning control theory but then got distracted by more urgent matters... c'est la vie

[1] http://sam.zeloof.xyz/category/semiconductor/

[2] http://sam.zeloof.xyz/garage-electron-microscopy-first-image...

Some very interesting work there, reminds me of Ben Krasnow's lair. You guys should hang out!

I thought the voiceover video for the SEM lithography experiment worked really well ( https://youtu.be/SB94rQtKlKI ). How does the spot size from the SEM compare to the ~1-um resolution you get from the DMD? I assume you're not actually getting 5 nm out of it...?

I doesn't make a difference because in the industry they all are the same and always have been. Except when they are worse. :-/

I've been on silicon side. Because chips are rushed out the door and always behind schedule, and they expect large customers to make 2-3 product lines with it during the chip's lifetime.

Curious what helper apps you're using, I've always set my own DRC rules but have been mostly on the R&D side so it wasn't as critical

It's been a while since I moved up the stack to frontend development so I don't remember most of them but the primary one was the Saturn PCB toolkit [1]. There was one that we used in place of Saturn PCB toolkit that was far easier to automate but I can't find it now. I wrote lots of custom scripts to turn Excel formulas into Altium rules and there were quite a few crappy WinForm apps from fabs.

Edit: Nowadays I only do electronics for personal projects and since I stick to three fabs (a local one one I've got a relationship with and two Chinese specials), I've just got a few manually created DRC templates per fab, # of layers, and max signal speed with a few templates just for RF that I got from a mentor.

[1] https://saturnpcb.com/pcb_toolkit/

Sounds more like writing open kernel drivers, except you get paid.

Still aspiring to work on something challenging is healthy and I respect GP’s sentiment!