<cyrozap_web>
> my server is now supplied with enough current
<cyrozap_web>
uhh
<cyrozap_web>
Would you mind if I had the IA archive those pages?
<rqou>
wait, it's actually an odroid then
<rqou>
?
<rqou>
maybe you should dump it under doc/ in the repo
<pointfree>
Yeah it's an Odroid XU4 in my apartment and I added a big HDD
<rqou>
i thought odroids were in famously lagging mainline kernels by an insane amount?
<cyrozap_web>
rqou: I like to archive links so whoever sees these logs in the future doesn't have to go hunting for the new locations. Though, there's no reason we couldn't do both.
<cyrozap_web>
rqou: The Odroid C2 can run mainline. You're probably thinking of Allwinner SoC-based boards.
<rqou>
hmm, probably a problem with the older odroids
<cyrozap_web>
The effort to 100% mainline the Amlogic S905* SoC kernels is pretty recent.
<rqou>
the one i was thinking of isn't even an amlogic
<rqou>
iirc it was one of the exynos ones
<cyrozap_web>
Oh, yeah, that's because Samsung will literally not sell anything to you unless you're a Korean company, so their SoCs don't wind up on a lot of dev boards. Also, IIRC, they have a locked/proprietary bootloader and don't really release SDKs for anything but Android.
<cyrozap_web>
That said, Samsung _does_ do a lot of mainlining work themselves now, so the kernel situation with their SoCs isn't terrible.
<rqou>
do you know what the situation with Kirin chips is?
<cyrozap_web>
But since their main use of SoCs is in smartphones and Chromebooks, which are enormous markets, they have very little incentive to get their chips out into the hands of hobbyists.
<cyrozap_web>
Kirin is HiSilicon (a.k.a. Huawei)
<rqou>
i meant how close they are to upstream
<rqou>
so my new phone (since my old phone has now totally quit working properly) is on 4.1.18
<rqou>
so better than qualcomm but still not great
<cyrozap_web>
They've been working on mainlining some of the stuff to support their 96boards devices, but good luck getting support for any of their other SoCs.
<cyrozap_web>
Same for MediaTek and all the other SoC manufacturers that sell SoCs used on 96boards devices.
<rqou>
hmm i wonder if i can easily break into EL3 on my phone? :P
<cyrozap_web>
Maybe? But good luck getting any docs for your SoC.
<rqou>
it's also a Kirin 960, which has a 96boards board
<cyrozap_web>
rqou: Which phone is it?
<rqou>
the dead phone is a nexus 6p
<rqou>
new phone is a huawei p10 plus
ZipCPU|Laptop has quit [Ping timeout: 248 seconds]
<rqou>
i need to prepare to re-unlock the bootloader because apparently a system update relocks it
<rqou>
quality(tm)
<cyrozap_web>
Android doesn't require too many changes from mainline nowadays, though I don't know the specifics because I have no desire to run Android on my mini PCs :P
<rqou>
binder? ashmem? "the shit needed to make SurfaceFlinger work?"
<azonenberg>
rqou: i have a pair of odroid c2s
<azonenberg>
was gonna set one up on my microscope and send the other to my brother as a cheap web browsing box
<cyrozap_web>
Someone got a 2013 Nexus 7 running mainline with the Freedreno OpenGL driver with "only 50 patches" (or something like that), and that's a Qualcomm device.
<rqou>
i remember that
<rqou>
too bad it didn't seem to have enough explanations for "people who know linux reasonably well but know nothing about android"
<rqou>
nor explanations of "how do i do that to a new device?"
<rqou>
now what about "now do i enable a new device?"
<cyrozap_web>
Step 1: Get complete vendor docs
<cyrozap_web>
Step 2:
<cyrozap_web>
Use vendor docs to write drivers
<rqou>
which drivers are needed to actually make android boot?
<rqou>
how do i tell why android isn't booting?
<cyrozap_web>
UART
<rqou>
how does android even boot?
<cyrozap_web>
Same as any OS
<rqou>
fine :P
<rqou>
after pid1 is launched, what happens? (on android)
scrts has joined ##openfpga
<cyrozap_web>
No idea, I don't really care about Android. You should look into LineageOS's docs (continuation fork of Cyanogenmod) for porting to a new device.
<rqou>
wait, what happened to Cyanogenmod?
<cyrozap_web>
Cyanogen, Inc. killed it.
<cyrozap_web>
Literally took down the domain, the wiki, and everything else.
<cyrozap_web>
But the main thing you're missing is that it's not hard to get Linux to _boot_ on a device.
<mtp>
but once you've booted it, you're running linux
<rqou>
i mean, i know that
<rqou>
i've booted super-bare-metal systems before
<rqou>
where init is basically busybox ash
<cyrozap_web>
It's hard to get _mainline_ Linux to boot _and_ utilize all the hardware peripherals without any blobs or a hacked-to-death kernel.
<rqou>
but yeah, things that i can't find any good documentation for include "what is a surfaceflinger? what does it need to work? how does (e.g.) Minecraft PE or the calendar app interact with the GPU?"
<azonenberg>
Ok so... looks like led[2:0] are behaving correctly with this new patched emulator
<azonenberg>
but led[3] is total garbage
* azonenberg
investigates...
_whitelogger has joined ##openfpga
<azonenberg>
or nope
<azonenberg>
it's MC6
* azonenberg
goes and checks that
scrts has quit [Ping timeout: 276 seconds]
mifune has joined ##openfpga
mifune has joined ##openfpga
mifune has quit [Changing host]
scrts has joined ##openfpga
<azonenberg>
Soooo right_pterms[28]
<azonenberg>
Which is PTC for NC6
<azonenberg>
is correct
<azonenberg>
it's a pulse that goes high for one clock every time we're supposed to toggle count[3]
<azonenberg>
Whiiich means the bug is in the macrocell and not the PLA (I also found an inversion bug in the PLA, separately)
<azonenberg>
... whoah
<azonenberg>
this is interesting
<azonenberg>
the OR term is showing toggles
<azonenberg>
So my OR array is derping
<cyrozap_web>
pointfree: Hey, so I was just thinking, have you tried bulk-loading a bitstream config into the configuration registers?
<azonenberg>
oook
<azonenberg>
Here's my problem
<azonenberg>
the PLA OR array is completely borked
<azonenberg>
i have configs i'm totally not supposed to
<pointfree>
cyrozap_web: What do you mean by bulk-loading? Do you mean writing a loop that goes through all possible routes, etc?
<azonenberg>
the OR array config in the bitstream is all 1s (i.e. no terms selected)
<azonenberg>
the parsed OR config in my config SRAM has a lot of 0 bits
<cyrozap_web>
pointfree: My thoughts are that if it's possible to have OpenOCD load bitstreams on its own (via JTAG/SWD without the use of the ARM core), we could possibly standardize our bitstream files and tools around ELF and ihex.
<cyrozap_web>
pointfree: Alright, I'm going to try converting that to an ihex file and loading it with OpenOCD. If that works, we can kind of treat the PSoC as an expensive, RAM-based CPLD with an ARM core attached :)
<cyrozap_web>
That would require use of the Cortex-M3 for decompression, wouldn't it?
<cyrozap_web>
That'd be more useful for when we want to store the bitstream in flash.
<cyrozap_web>
I'm just talking about directly loading the bitstream, FPGA-style.
<qu1j0t3>
azonenberg: that's an interesting layout (re screenshot). What produces its organic appearance? I was expecting a lot more visible structure.
ZipCPU|Laptop has quit [Ping timeout: 260 seconds]
<azonenberg>
qu1j0t3: that's just how the PAR did it
<azonenberg>
and i was actually impresed at how *much* structure there was
<azonenberg>
Sooo it looks like i'm going to be speaking at hardwear.io on bitstream RE etc
<azonenberg>
now i have to actually do the research :D
<qu1j0t3>
it's just less regular than i expected
<azonenberg>
Lol you clearly have not looked at much post-PAR layout
<azonenberg>
ISE normally makes giant blobs of hash with little discernable structure :P
<azonenberg>
this is way more structured than usual
<qu1j0t3>
true, i'm not an expert
<qu1j0t3>
and i've never looked at ISE output
<nurelin>
azonenberg: going to talk about the CR2 RE ?
<azonenberg>
nurelin: Yes, and more
<azonenberg>
i want to do some higher level RE tools that are independent of target device
<azonenberg>
the abstract was kinda generic so i would have flexibility to do actual RE work
<azonenberg>
and not get tied into one niche
<nurelin>
tools based on chip imaging ?
<azonenberg>
I want to make a generic RE framework
<azonenberg>
that takes in bitstreams from $DEVICE
<azonenberg>
for some large set of formats
<azonenberg>
turns them into Yosys RTLIL
<azonenberg>
then does higher level analytics as yosys passes
<azonenberg>
e.g. turning collections of xors into adders
<azonenberg>
sn00n: Re your question in the other chan
<balrog>
azonenberg: would there be a way to implement a jtag-killer that isn't a chip-killer?
<azonenberg>
As of right now, the open toolchains i am aware of
<azonenberg>
lattice ice40 -> icestorm
<azonenberg>
silego greenpak4 -> gp4par
<azonenberg>
xilinx coolrunner-2 -> cr2par, WIP
<sn00n>
ah, ok
<sn00n>
but no artix 7 or cyclon v and so on?
<azonenberg>
Correct
<azonenberg>
Those are major undertakings
<azonenberg>
clifford is interested in artix7 and is meeting with some folks to discuss today if memory serves me right
<azonenberg>
But no real progress yet
<azonenberg>
i'm gonna start working on spartan3a soonish to get my feet wet with LUT FPGAs
<balrog>
I thought someone was working on cyclone but I forget who
<sn00n>
"no real progress" means like 5% done?
<azonenberg>
yeah somebody was tinkering
<azonenberg>
sn00n: less than that
<sn00n>
what are the problems? checksums?
<sn00n>
oh
<azonenberg>
more like "interested but havent done anything"
<azonenberg>
lol, checksums
<azonenberg>
the CRC is known
<azonenberg>
thats the easy part
<sn00n>
ah, cool
<sn00n>
the bitstream format is complete nasty brain fuck? :)
<azonenberg>
Yes :p
<sn00n>
hmpf
<azonenberg>
the high level format is a chunk based file format with basically (register, length, block of data)
<azonenberg>
that is documented
<felix_>
azonenberg: have you already made some die photos of the lower layers of an artix7? would probably really help us to figure out the global routing switch boxes
<felix_>
yes, we're currently discussing things
<azonenberg>
the actual fabric configuration stuff goes into the "frame data register in" and "frame address register"
<azonenberg>
Going into THAT, you have addresses to "frames" a kB or so in size and then frame contents
<azonenberg>
none of the frame contents are doc'd
<azonenberg>
or what frame address does what
<azonenberg>
felix_: i have not
<azonenberg>
me or digshadow, i forget which (we've passed the dies around) have an xc7a35t decapped and top layer imaged
<azonenberg>
but nothing below
<felix_>
ok
<sn00n>
azonenberg: is there a kind of a wiki about "what we currently know"?
<rqou>
note that LDCP (latch) doesn't match what yosys expects
<rqou>
not that yosys can infer a LDCP-type latch anyways
<azonenberg>
lol
<azonenberg>
i'm still working on bitstream emu right now
m_w has quit [Quit: leaving]
bit_lySLH2uSZHed has joined ##openfpga
m_w has joined ##openfpga
bit_lySLH2uSZHed has left ##openfpga [##openfpga]
<azonenberg>
rqou: so, project organization/structure question
<azonenberg>
Do you think a bitstream-to-netlist tool using the openfpga libraries belongs in the openfpga repo, or its own?
<balrog>
azonenberg: I think there should be an org for the project and one repo per major tool
<balrog>
Git is not designed for single monolithic repos :P
<azonenberg>
So you'd want to split the greenpak and coolrunner stuff?
<azonenberg>
even though they share a lot of code?
<balrog>
is the shared code in some sort of library?
<azonenberg>
Yes
<balrog>
it almost seems like it should be
<balrog>
which then would have its own repo (and you could use submodules for all that)
<azonenberg>
More stuff should be moved to that library, it can be more generic
<azonenberg>
But yeah i can probably rearrange stuff at some point
<azonenberg>
For now let me make a new repo for hardware RE stuff...
<rqou>
ugh i hate submodules
<azonenberg>
i actually have the netlist-tools repo
<azonenberg>
maybe i can revive that
<balrog>
rqou: eh, why?
<rqou>
mostly because their states seem to often get out of sync
<rqou>
they don't clone when you clone the toplevel
<rqou>
and forking becomes a huge pain
<balrog>
yeah you have to do git submodule update --init --recursive
<balrog>
and if you want to update the code in the submodule you have to go there, pull, and commit (the reason for that is so submodules can allow pinning a version)
<balrog>
but submodules are best for bundled stuff
<balrog>
if you're having a library that gets installed with `make install`, submodules don't make sense
<rqou>
i'd rather have a super-repo
<balrog>
then separate repos and instructions saying "install this dependent library" make more sense
<balrog>
super-repos work with svn but kinda fall apart with git because everything is stored forever and you get a lot of cruft
<rqou>
i don't really care about cruft
<balrog>
it also means you can't easily isolate commits
<balrog>
(svn works because each directory can be pulled into its own repo)
<lain>
I've said it before and I'll say it again (paraphrasing from some quote, I forget who said it): git is a great toolkit for building a VCS, someone should really do that.
<balrog>
but like, bisect becomes significantly more annoying
<rqou>
yes, i've heard this joke too :P
<lain>
rqou: it's not a joke, it's reality :D
<azonenberg>
rqou: so thinking a bit more
<lain>
git is about the least user friendly thing I've used in recent memory, save perhaps the openbsd installer
<azonenberg>
i'm probably going to say, make install openfpga
<azonenberg>
then have netlist-tools be self contained given that
<rqou>
arrgh i hate things that work like that
<rqou>
now i have to go through a whole "install" process on the dependencies
<azonenberg>
well the thing is, openfpga is set up to be a self contained project with its own packaging etc
<azonenberg>
it wont work well as a submodule
<balrog>
but "openfpga" is several projects in one
<rqou>
i would just dump the RE stuff into "openfpga" also
<azonenberg>
not really, any more than yosys is several in one
<balrog>
rqou: messy, crufty repo :(
<balrog>
azonenberg: icestorm is not part of yosys though
<openfpga-github>
[yosys] azonenberg pushed 25 new commits to master: https://git.io/vQKRp
<openfpga-github>
yosys/master 908ce3f Robert Ou: coolrunner2: Also construct the XOR cell in the macrocell
<openfpga-github>
yosys/master a64b566 Robert Ou: coolrunner2: Initial techmapping for $sop
<openfpga-github>
yosys/master 6e0fb88 Robert Ou: coolrunner2: Initial commit
<balrog>
the high level libraries are
<rqou>
wait did clifford merge my PR or what did you just do?
<azonenberg>
He merged it a while ago
<azonenberg>
I pulled upstream to my fork
<azonenberg>
which logs here
<rqou>
ah, last i looked (before i was sick) it hadn't been merged yet
<azonenberg>
he tweaked it a bit
<azonenberg>
but merged
<balrog>
rqou: basically there should be a balance between "single monolithic repo" and "dozens of tiny repos" is what I'm saying
<balrog>
the former means a ton of unnecessary cruft; the latter is a pain in the ass
<rqou>
i'd rather have cruft than pain in the ass
<openfpga-github>
[netlist-tools] azonenberg pushed 1 new commit to master: https://git.io/vQK0c
<openfpga-github>
netlist-tools/master f180e0d Andrew Zonenberg: Updated README, reviving this project
<balrog>
rqou: why can't there be a reasonable in-between?
<rqou>
there probably can be, i've just never seen it
Hootch has quit [Ping timeout: 276 seconds]
Hootch has joined ##openfpga
<pointfree>
I like how with mecrisp-stellaris I can just union mount with upstream because they don't endorse any dvcs, and that means I can use a better designed dvcs than git such as darcs or pijul for my subsystem, eg:
<pointfree>
sudo mount -t overlay overlay -o lowerdir=mecrisp-stellaris-2.3.6,upperdir=mecrisp-stellaris-cy8c5888,workdir=mecrisp-stellaris mecrisp-stellaris
<balrog>
rqou: wow... last I heard of that it wasn't yet included with git
<pointfree>
Just about everything in the Linux (ACL) whac-a-mole security theater needs sudo because it's not a capability system. Although conveniently I don't need sudo to delete the contents of my home directory.
<rqou>
hmm, subtrees sound like they aren't any better than a super-repo if we control both the toplevel and the dependency
<azonenberg>
pointfree: lol
<azonenberg>
... oooh my PCBs shipped
<azonenberg>
Getting closer to thermal characterization
DingoSAL has joined ##openfpga
DingoSaar_ has quit [Ping timeout: 240 seconds]
DingoSAL has quit [Remote host closed the connection]
DingoSAL has joined ##openfpga
DingoSAL has quit [Remote host closed the connection]
DingoSaar has joined ##openfpga
<awygle>
i've found subtrees to be a bit more convenient for "i want to compose many dependent repositories into a larger project-specific repository" than submodules
<awygle>
iirc
<awygle>
it's been a while since i've looked in-depth but i remember subtree being really good for saying "i want to pull in the current versions of all of these relatively stable dependencies for my new project and afterwards i want them to just look like code", but really bad for updating dependencies later
<awygle>
whereas submodules were a pain every time you had to touch them (setting up a new project, deploying to a new machine, etc) but were much better isolated
<awygle>
(the company at which i learned this tried to make their own tool based on google's repo tool, then eventually converted to a monorepo)
<azonenberg>
Neither handles all of the dependent repos changing frequently
<azonenberg>
in both direcitons
<azonenberg>
i.e. pushing to upstream and pulling updates
<azonenberg>
i basically want a symlink to another repo
<azonenberg>
so a pull will pull the latest version of that
<azonenberg>
a push will go to upstream
<awygle>
yeah i hear you. git is not good at that, even though it seems like it should be.
<awygle>
it looks like mercurial is a little better maybe, but idk anybody who actually uses mercurial
<rqou>
the TAs for a class i took used mercurial
<rqou>
all of my project team used git bridges to interact with the repository
<balrog>
python was probably the biggest mercurial-using projects
<balrog>
they recently moved to git
<balrog>
recently meaning a few years ago
<balrog>
2015-2016
<pointfree>
facebook uses mercurial because it scales better than git
m_w has left ##openfpga ["Leaving"]
<azonenberg>
ok, finished implementing all to-be-supported macrocell features
<azonenberg>
waiting for a build to test
<azonenberg>
aaand failed to route due to congestion
* azonenberg
looks
<azonenberg>
Global clocks failed to route due to congestion? Hmmm
<azonenberg>
rqou: Do the coolrunner latches have a clock enable?
<azonenberg>
i.e. is PTC used for anything in latch mode?
<azonenberg>
ah ok i see whats going on
<azonenberg>
need to add muxing on the latches
cyrozap_web has joined ##openfpga
<cyrozap_web>
<balrog> it also means you can't easily isolate commits
<cyrozap_web>
balrog: `git log subdirectory`
<cyrozap_web>
That'll give you the commit log filtered to only include changes in that subdirectory.
clifford has quit [Ping timeout: 260 seconds]
<cyrozap_web>
azonenberg: If you want to be able to make changes to inter-tool API's/ABI's, I strongly recommend using a monorepo with subdirectories for each tool--at least while the project is still small and in rapid development. Git submodules are a huge maintenance burden, and result in build systems (see: https://github.com/frida/frida).
<azonenberg>
cyrozap_web: so, what i do is
<azonenberg>
i use submodules for libraries that are shared across unrelated projects
<azonenberg>
like the log framework is now used by both my antikernel stuff and openfpga
<azonenberg>
but those submodules do not have a build system of their own
<azonenberg>
they just drop into a subdirectory and are built as part of the parent project
<azonenberg>
and statically linked in
<azonenberg>
Anything bigger becomes its own full repo and is just manually installed systemwide
<cyrozap_web>
azonenberg: That seems sane.
<azonenberg>
the log repo contains a leaf-level cmakelists and splashfile
<azonenberg>
to integrate into a larger cmake or splash project
<azonenberg>
but is not intended to ever be checked out on its own and built
<azonenberg>
For tightly coupled things, like the different openfpga tools, i do one repo with a subdir per tool
<azonenberg>
even if it's modular, helps to have it all in one place
<cyrozap_web>
s/result in build systems/result in complex build systems/