Don't suppose there's actually documentation for the CPU anywhere?
(I mean more than a tiny "datasheet" with a very high level overview and/or a pile of random Linux/uboot patches)
Readit Newsswetland commented on Orange Pi RV2 $40 RISC-V SBC: Friendly Gateway to IoT and AI Projects riscv.org/ecosystem-news/... · Posted by u/warrenm
swetland commented on I got almost all of my wishes granted with RP2350 dmitry.gr/?r=06.%20Though... · Posted by u/elipsitz
Lots of nice improvements here. The RISC-V RV32I option is nice -- so many RV32 MCUs have absurdly tiny amounts of SRAM and very limited peripherals. The Cortex M33s are a biiig upgrade from the M0+s in the RP2040. Real atomic operations. An FPU. I'm exited.
swetland commented on I got almost all of my wishes granted with RP2350 dmitry.gr/?r=06.%20Though... · Posted by u/elipsitz
Coordinating access to the memory bus and peripherals is probably not easy to do when the cores weren’t ever designed to work together. Doing so could require a power/performance penalty at all times, even though most users are unlikely to want to deal with two completely different architectures across four cores on one microcontroller.
Having both architectures available is a cool touch. I believe I criticized the original RP2040 for not being bold enough to go RISC-V, but now they’re offering users the choice. I’ll be very curious to see how the two cores compare… I suspect the ARM cores will probably be noticeably better in this case.
They actually let you choose one Cortex-M33 and one RISC-V RV32 as an option (probably not going to be a very common use case) and support atomic instructions from both cores.
swetland commented on Zilog Z80 CPU – Modern, free and open source silicon clone github.com/rejunity/z80-o... · Posted by u/jnord
This page says 50 MHz.
https://github.com/rejunity/z80-open-silicon/blob/main/docs/...
That's the expected clock rate for the TT07 run... but Tiny Tapeout designs only have 8 in, 8 out, and 8 bidirectional IOs (plus a reset and clock input) available, so they're using a multiplexing strategy where the Z80 clock runs at 1/4 of the base clock rate and alternates between control signals, A0-A7, control signals, and A8-A15 on the OUT pins:
https://github.com/rejunity/z80-open-silicon/blob/68438f0019...
So you'd get an effective 12.5MHz Z80 clock and need a bit of external logic to demultiplex the full IO interface. Still not too shabby!
The goal (per the project README) appears to be to prototype with TT07 and then look into taping out standalone with ChipIgnite in QFN44 and DIP40 packages (which would be able to have the full traditional Z80 bus interface and run at the full clock rate).
swetland commented on Unlocking the NES (For Former Dawn) (2022) somethingnerdy.com/unlock... · Posted by u/zoklet-enjoyer
It's a fantasy NES expansion like how the Pico 8 is a fantasy console. I think it's really cool, especially since the game will be coming out on a cartridge that's playable on a real NES
Yeah, the whole "what could we do with the original CPU and PPU of the NES given much more RAM and game data storage" experiment is pretty neat -- and based on what they've shown so far the results are quite impressive.
swetland commented on Reflecting on 18 Years at Google ln.hixie.ch/?start=170062... · Posted by u/whiplashoo
I'll vouch for it, I think you may have escaped what it became: I'm a couple generations after you, joined Google/Wear in 2016 and accepted defrag onto Android SysUI in 2018. Much lower level, topped out at L5, but saw a ton because I was the key contributor on two large x-fnl x-org projects in those 5 years, one with Assistant[1], one with Material/Hardware.[2]
Both were significantly more dysfunctional than any environment I've seen in my life, and fundamentally, it was due to those issues.
Pople at the bottom would be starved for work, while people in the middle were _way_ overworked because they were chasing L+1 and holding on to too much while not understanding any of it. This drove a lot of nasty unprofessional behavior and attitudes towards any partnerships with orgs outside of Android.
As far as lacking focus on solving user problems...man I can't figure out how to say it and still feel good about myself, i.e. illustrate this without sounding hyperbolic _and_ without having to share direct quotes tied to specific products. TL;DR the roadmap was "let's burn ourselves out doing an 60% copy of what Apple did last year and call that focus." This was fairly explicitly shared in public once at an informal IO talk, and it's somewhat surprising to me how little blowback there was externally. The justification is, as always, it's OEMs fault. OEMs just asked about what Cupertino just released, just in time for the yearly planning cycle.
[1] https://blog.google/products/assistant/next-generation-googl...
[2] https://www.androidpolice.com/google-material-you-interview-...
I had moved on from Android by 2013, so I definitely don't have much insight into what it's become over the past decade. In the earlier years it was very much about working hard to build the platform, products, and ecosystem. The team was pretty small and generally isolated from the rest of the company, which was both good (we got to focus on doing our thing and not get distracted) and bad (integrating with Google properties, services, etc was often rather painful).
Part of the reason I left the team was Clockwork (before it became Wear) turning into "just cram Android on to a watch", which was very much not an approach I was excited about and things getting more political and "too big to fail", combined with burnout and needing a change of scenery.
swetland commented on Reflecting on 18 Years at Google ln.hixie.ch/?start=170062... · Posted by u/whiplashoo
Yeah, I definetly wouldn't want to have been on the early Android team.
Imagine you work your ass of to build the Android 1.0 device to compete with the Blackberry and then when you're close to launching the iPhone drops and your leadership says we gotta throw everything in the trash and start over from the touchscreen perspective.
Mind you, the iPhone employees didn't have it much better either, with most of them working 16h days and sleeping in hotels next to the office to save time, while having their marriages ruined according to some of them.
The early Android vs iPhone development war was basically a Hail Mary gold rush from both companies trying to capture as much marketshare as quickly as possible.
The whole "throw everything in the trash and start over" thing is massively overstated. The iPhone announcement absolutely impacted things, not entirely all bad -- there was interest from OEMs before that, but it went through the roof after -- and it did mean we moved from the plan to ship a blackberry-style device first followed by a touchscreen device to skipping right to touch for initial launch, recognizing that the landscape had absolutely changed.
Initial work on the touchscreen based hardware started back in June 2006 (I remember meeting with HTC during a monsoon to kick off the project that became Dream/G1) and OS work to support larger displays, touch input, etc was underway before iPhone was announced.
Blackberry was not really the concern early on... Windows Mobile was. Folks (correctly as it turned out) believed mobile was going to be the next big platform area and there was concern (from Google, but also from OEMs, cellular carriers, etc) that Microsoft might end up entrenching themselves the way they did in PCs through the 90s, possibly including a more successful attempt to control the browser/web experience.
swetland commented on Reflecting on 18 Years at Google ln.hixie.ch/?start=170062... · Posted by u/whiplashoo
This is interesting, surprisingly blunt, and quite on point about the current malaise, but . . . I think this is the perspective of someone that was happily drinking the kool aid for longer than they should have been.
For example, my impression was that had Android assimilated into the wider Google they would have failed. The wider Google views the fact Android isn't Chrome OS as a strategic failure, but the truth is wider Google doesn't understand how to work with other companies. The Android unit did have certain ludicrous habits (I recall huge laundry bins in the reception of their building at one point) but the reason for this was they understood what was at stake. (People forget just how much needed to be done between Android 1.6 and 4.1 to stop the iPhone completely running away with it, although that effort has now been effectively squandered). There have been other units that also fail to assimilate and then just peter out, but Google under Mr Pichai never learns from acquired companies, it just imposes their way on to them. If you came from the Chrome side of the fence you wouldn't notice this because it was your way being imposed elsewhere.
Mr Pichai has always had a singular vision, to be CEO of Google, and then stay there. What to do with that never seemed to cross his mind.
Yeah, I take exception to the painting of Android as inherently "unhealthy" and not "solving real problems for users." Also with lumping it in with the unmitigated disaster that was the Social/G+ effort. I attribute much of Android's success to Larry & Eric being very supportive, shielding the team from constant interference from the rest of the company, and letting us get shit done and ship.
I came aboard during the Android acquisition, some months before he started at Google, so of course I may be a bit biased here. I was pretty skeptical about landing at Google and didn't think I'd be there for more than a couple years, but spent 14 years there in the end.
Android had plenty of issues, but shipping consumer electronics successfully really does not happen without dealing with external partners and schedules that you can't fully control.
No idea what the laundry bins thing is about -- never saw that.
If they did that, someone might actually develop an open source toolchain and software stack for these. However, considering they charge 200x more for the software than the hardware, I can't imagine that's in their financial interest :)
Oh I don't even mean the FPGA side (of course that'd be nice), just the SoC's CPU complex and its peripherals! The only "documentation" I've found is a high level block diagram.
Not finding any documentation for this SoC on either the beagleboard or microchip websites. I'm still waiting for a RISC-V SoC that actually has reasonable documentation instead of a pile of random linux kernel and (maybe) bootloader patches. A list of base addresses for peripherals and a block diagram does not count.