to paraphrase that one veterinary handbook; if you need to get a Linux SoC to work:

  • DON'T TRUST A VENDOR
  • USE YOUR BRAIN
  • USE DRUGS
  • when i say "USE DRUGS" i mean literally use drugs. alcohol. amphetamines. opioids. trust me, by the time you're done, your soul will be too ragged to survive without

    thinks

    The cat vendor is faster and has sharper teeth and nails lawyers and NDAs than you do. It has 'no code of ethics' or considerations for its own future. In a fair fight it will win.

    advice still works, huh

    i spent far too much time on this
    @whitequark imo 2 and 3 are not in the right order
    @whitequark "... and has sharper NDAs and lawyers than you do." would work to include more from the previous post
    @lunareclipse i considered it but the mental image of a feral vendor was too funny to pass on
    @whitequark uncomfortably accurate advice
    @nirya years of industry experience encapsulated in a single .jpeg
    @whitequark all fights against the vendor are unfair until proven otherwise
    @whitequark (me trying to instate all the dependencies over cross-compiling the SoC)
    @whitequark is telnetd drugs in this analogy
    ✧✦Catherine✦✧ (@[email protected])

    when i say "USE DRUGS" i mean literally use drugs. alcohol. amphetamines. opioids. trust me, by the time you're done, your soul will be too ragged to survive without

    Treehouse Mastodon
    @whitequark taking notes for my coming attempt to revive a dead e- reader
    @SnoopJ EPDs are cursed and somewhat proprietary but from what i've seen the cursedness is somewhat contained. you might be fine
    @whitequark yea my backup plan is to just cannabalize the display, they're not too complicated to talk to
    @SnoopJ usually it's not too hard to just boot linux on something, the problems begin when you want the device to do things besides "talk to you over a shell". unsolved problem in computer science (input/output)

    @whitequark thankfully this is an older device with very exposed TX/RX, but I think its kernel bit-rotted while it sat unused for so long, requiring more invasive surgery than I've done before.

    Haven't seen much info about this on the web except a surprisingly detailed write-up by a bored EE graduate in the funniest possible place: linkedin

    @whitequark this is why I’m cat-hiss-noises at embedded Linux, after I briefly looked at uboot and busybox and all the horrendously outdated kernel trees. At least with microcontrollers I can plausibly trust some parts of some SDKs, and if I don’t like it, implement it myself (even if it takes ages because I’m not as good a coder)
    @s0 @whitequark
    I got started in embedded programming in the 1970s, with the Z80, 6502, and 8048, then later the 8051, 68HC05, 68HC11, and PIC16. On those, you used a tiny, trivial RTOS, or bare metal (no OS at all).
    I fully understand what "embedded Linux" is, and have developed with/for such, yet the term still causes me cognitive dissonance. My brain still wants to think, "That's not embedded, that's a REAL computer system!"

    @brouhaha @s0

    embedded OS, n.: any OS that is 10 years out of date yet is installed on millions of units every day

    @brouhaha @s0 @whitequark thats not even a real os, thats a toy os based on linux code, working in severely degraded mode because it was not designed for that purpose.
    @whitequark
    As the software lead at a SoC Linux vendor, I hereby submit my protest.
    @Mux all right, let's see your BSP :3
    Welcome - L4B Software Embedded Systems & Software

    L4B Software is a global leader in embedded software solutions. With deep expertise across automotive, medical devices, and consumer electronics, we provide end-to-end software engineering services tailored to your needs. ISO-certified and with a commitment to innovation, our comprehensive offerings from Embedded Linux to AI ensure your projects excel.

    L4B Software - E2E Software Solutions
    @whitequark as a veterinary professional, each of these pieces of advice is valid on its own

    @whitequark if performance isn't the highest priority some fpga with a LiteX SoC is an option!

    If you're happy with ~120MHz RiscV (but potentially multiple cores?) you can even do it all with an OSS toolchain.

    Is it a great solution? No! But it does solve some of the problems.

    @hp yeah, I've been working on OSS FPGA toolchains (and Migen, in the past) for almost a decade now...

    @whitequark sorry! I didn't know!

    Migen is great! I've been using it for the past few weeks. Thanks for your work! ♥️

    @hp I actually think it's terribly designed and implemented, so much so I at one point designed its replacement (which is now called Amaranth)

    @whitequark I'll check it out! I've been enjoying migen in the context of LiteX and not having to write system verilog. 😅

    The abstractions like SDFTristate and such is really nice to keep my cores portable before I settle on the the final FPGA. Currently my stuff works ok on an xc7 and an ECP5.

    I was quite impressed.

    @hp Migen is generally an improvement on Verilog as long as you don't look too closely at what it's really doing, but it's really buggy (look at every bug I've filed with a fixed-in-nmigen tag) and there are no attempts to nail down a semantic aside from "well, this translates to such and such Verilog"; there's also a bunch of really annoying limitations like "everything goes into one module", "Record is trying to do two things and does three of them poorly", and "no async resets"

    @whitequark sound like I'll probably be less impressed when I use it more then? 😅

    I could wrap something written in your new system and use it with LiteX I think? I'll try porting a small core I wrote!

    Thanks for the information!

    @hp yes; particularly if you want to know exactly what behavior is guaranteed (this applies to LiteX even more so than Migen, we spent a lot of effort on streams for example and LiteX's ones are... inconsistent)

    yes, you can use Amaranth and LiteX together, but you have to combine them at the Verilog/RTLIL level, they don't directly interoperate

    0061-minimal-streams - The Amaranth RFC Book

    @whitequark Thanks for the explanation!

    Given that LiteX already has a Zephyr port moving everything over might be a challenge. But I think integrating at the Verilog level should be fine.

    I'll give it a whirl! My custom peripheral is only ~1k lines of migen so it shouldn't be very hard to port.

    @whitequark Are the drugs for you or for the SoC?
    @whitequark forgot a step: never document it and wonder the next day how you ever managed