<ktemkin>
discord's API provides a dictionary mapping mentions to display names; and then it goes and does a .replace() on each mention to replace it with the display name
<ktemkin>
but that's a single replace; not a global one :)
<d1b2>
<C-o-r-E> are rockchips docs normally secret?
<d1b2>
<C-o-r-E> (perhaps a dumb question)
<hl>
not so much afaik
<hl>
there are far worse vendors
<d1b2>
<C-o-r-E> I mostly know TI and STM
<hl>
TI and STM are usually okay except for a minority of NDA'd parts
<d1b2>
<esden> @Kate Temkin Yeah I though so much that it would be something similarly simple.
<hl>
the vendors that are a complete pain are the ones used to selling more "value-add" or "advanced" chips shall we say, and thus used to having some kind of process you have to go through to become a customer of theirs
<hl>
as opposed to "just buy it on digikey"
<d1b2>
<esden> @Kate Temkin my upload is slower... but I am uploading it to my german server... it might be faster for those of us that are on the other land mass 😄
<d1b2>
<gimbas> i don't really get that business model, what are they trying to achieve?
<hl>
e.g. broadcom, qualcomm, and the long tail of SoC vendors who are peddling SoCs for specific applications (e.g. TVs, IP phones)
<d1b2>
<Kate Temkin> @esden half my servers are in frankfurt =P
<hl>
search me, I think it's dumb
<d1b2>
<esden> @Kate Temkin 🙂 😄
<d1b2>
<C-o-r-E> Hmm yes Marvell seems to also be in that camp
<d1b2>
<C-o-r-E> must be a b2b culture thing
<d1b2>
<esden> A very common excuse why vendors don't release documentation to everyone and/or don't sell their chips on digikey is: "but then we will have to support those customers with our precious human support time" ... (my answer is usually "most of us don't want to talk to you ever... we just want the chip and decent written documentation... sigh "
<hl>
another reason tends to be "it makes our product look bad by revealing how crummy our documentation, or product (e.g. errata), actually is"
<d1b2>
<esden> that is the actual reason ... yeah
<ktemkin>
another reason is "if nobody sees the docs there are no security flaws"
<d1b2>
<C-o-r-E> in my very limited experience with one such vendor, that NDA'd documentation is total trash
<d1b2>
<esden> @Kate Temkin yep that too
<d1b2>
<C-o-r-E> @Kate Temkin thats a nice one
<d1b2>
<esden> we should create the "almanac of bad and actual reasons why chip vendors are tight lipped and require NDA" 😄
<hl>
also I assume it makes shopping around harder, since it tries to force you to commit to them before you can properly evaluate their product
<d1b2>
<C-o-r-E> "what could possibly go wrong"
<hl>
sure, it's not like they contractually oblige you to go with them, but you have to sink the cost of the time to "establish the relationship" :/
<ktemkin>
I gave a talk at some point where I yelled at vendors
<d1b2>
<esden> hl: "I already spent three months creating a relationship with that vendor and we are buddies now, we can't move on and use some other chip" 😄
<hl>
ktemkin: sounds interesting
<ktemkin>
at an event where the vendors were
<hl>
d1b2: yep
<ktemkin>
it was a bit awkward at one of the parties, afterwards =P
<whitequark>
"most of you don't want to talk to you ever" lmao true
<d1b2>
<C-o-r-E> good point about the sunk cost attack
<whitequark>
the few times i talked to a vendor it cured my desire to repeat the experience right away
<hl>
d1b2: from talking to the CEO of a PCB vendor in another channel I gather that having a business relationship with broadcom is a deeply blargh experience
<whitequark>
broadcom seems spectacular in that as far as i can tell literally no one *wants* to work with broadcom
<d1b2>
<C-o-r-E> 🙂
<ktemkin>
whitequark: yeah, talking to vendors has gradually shifted my "something's wrong in the docs" from "here's a nice e-mail explaining what I think is wrong and why" to "here's a twitter shitpost about your issue"
<whitequark>
it's usually easier to reverse-engineer their hardware than to get an answer from their support
<d1b2>
<C-o-r-E> On the other hand, what are vendors that you guys like?
<whitequark>
and far less of a headache
<hl>
remember folks, broadcom is literally the company that, if you report a bug in its firmware blobs to it, will literally fix the bug, give you the blob with the fixed bug, and then not fix that bug in your mainline but keep it for that customer only
<ktemkin>
the hardware's the real arbiter of truth
<ktemkin>
it gets thing right way more than support does
<hl>
every customer gets their own source fork, with only the bugs _they_ reported getting fixed in that fork
<hl>
it's insane
<whitequark>
ktemkin: well, yeah, but only if they never make a revision
<ktemkin>
hl: I mean, if they just patched the bugs for everyone everyone would know where the bugs are
<whitequark>
>There is some evidence to suggest that Broadcom once added certain utterly random functions to its NICs; namely card readers and TPMs (yes really)
<ktemkin>
then again, it's possible all this "NDA first" is because they've had to deal with some of the people who respond to my twitter messages and make me wish I hadn't bothered sharing~
<hl>
somehow I doubt that
<hl>
oh, another reason is paranoia over detection of patent infringement
<hl>
there are too many patents, thus everyone is accidentially violating patents, thus keep things which prove it secret
<hl>
though I don't think that really makes much sense, since "what the product does" is basically apparent from a marketing brief PDF, and the register manual isn't exactly going to be more revealing in that regard
<hl>
ultimately it's a corporate attitude, which is imposed because "that's how we do things"
<hl>
for example: Broadcom never publishes datasheets because they're dicks. And they're so asinine the datasheets they give under NDA are a) watermarked with "For <COMPANY_NAME>" and b) passworded PDFs with randomly-generated, customer-specific passwords (hint: they're usually "docs####" or "docs######" where #=0-9, which can be bruteforced in moments)
<whitequark>
lol
<whitequark>
and i bet you can remove watermarks with pdf2ps and grep
<hl>
but! Some of Broadcom's business units got transferred to Cypress. What did Cypress do? Just publish the damn datasheets, because they're not dumb. Did the sky fall in? NO
<hl>
it's not a rational thing, it's just superstition and company culture
<hl>
why say yes to releasing datasheets when it could be your ass on the line if something goes wrong as a result?
<whitequark>
don't forget draconic DLP programs
<hl>
DLP?
<whitequark>
data loss prevention
<hl>
oh god
<whitequark>
yeah did you think working there is fun? no
<hl>
i have heard rumours you can procure SDKs, datasheets from aliexpress.com but I don't know any details
<hl>
also see the raspberry pi. the fact that even today, there's no datasheets and no register manuals for the damned SoC, not only that (and uniquely for a SBC AFAIK) they won't even release proper schematics... suddenly it all makes sense when you realise rpi was launched by a group of ex-broadcom engineers. I guess they brought that culture with them
<d1b2>
<esden> I wish the <insert_fruit> pi alternatives using one of the rocket chips had actually a stable and well working set of drivers and running it as a dumb rpi replacement would not be painful... then rpi would be in actual trouble... 😦
<hl>
yeah
<d1b2>
<C-o-r-E> hl: thanks for that article, very interesting
<hl>
so also replying to the "if we publish datasheets they might try and tie up our valuable time with questions" thing, and tying in with this article...
<hl>
there are chips where the vendor (rightly or wrongly) has an expectation that nobody will be able to use the chip without their assistance
<hl>
of course this might just be "OEM doesn't know how to make a linux kernel driver because they don't have that much talent and want a turnkey solution", though of course this is fundamentally mistaken insofar that it ignores the "crazy coffee-drinking hobbyist" clientele, who can figure out anything if they have docs
<hl>
hence all the consulting services chip vendors are hoping to make extra $$$ from
<d1b2>
<esden> hl: oh yeah this is why I mentioned the "good documentation part" if the documentation would not suck and the chips were not so damn buggy they would not have to spend money and time on massive support teams ... ;)... I got scarred by another company with horrible practices: Renesas... and the M16 chip line they bought from Mitsubishi.
<whitequark>
"nobody will be able to use the chip without their assistance" could be an expectation, or it could be a goal...
<d1b2>
<esden> @whitequark hehe 😄 indeed
<hl>
but there are also chips where the vendor literally designed the chip to be useless without their help (as in: it has a binary blob which needs to be customised for a specific application, and only the vendor can customise the blob because it's a blob, so "contact the vendor and ask for their help" is literally a non-bypassable part of the design process... this is of course a dumb design, but in
<hl>
this case "we don't want randos taking up our valuable time" is literally reasonable)
<hl>
(I think whitequark can mention some chips like that IIRC)
<whitequark>
tps65983?
<hl>
whitequark: yep thought so, some TI USB PD thingy right?
<whitequark>
i mean they *tried* but the reality is that you can just upload the blob for tps65982 on it which is 100% compatible afaict
<d1b2>
<esden> the first thing that comes to mind are the useless arrays of undocumented register pokes to get an LCD to initialize.
<hl>
ha
<whitequark>
i think the restrictedness of tps65983 comes from asinine intel licensing requirements
<whitequark>
i gathered that not even other vendors like that bullshit
<whitequark>
esden: that one feels more like "we have zero confidence in our ASIC work but we still want to tape it out once"
<whitequark>
so everything gets a chicken bit
<whitequark>
or a knob or whatever
<d1b2>
<esden> yeah that is a real possibility too
<whitequark>
i've seen that with EPDs
<whitequark>
well, i mean, it's very visible with EPDs
<hl>
EPDs?
<whitequark>
electrophoretic displays
<whitequark>
aka epaper
<whitequark>
the one supported in glasgow actually requires a hardware kludge
<whitequark>
you have to attach a diode to its charge pump and tickle it while it boots
<whitequark>
or it just won't work
<d1b2>
<esden> I found it really cool that @zka managed to teach some of the epapers to do selective updates and tweak the undocumented calibration curves to jack up refresh rate on some small epaper displays.
<whitequark>
yeah they're pretty hackabe
<whitequark>
hackable*
<whitequark>
nrf24l01 is also super hackable interestingly
<hl>
I recall reading about how epaper vendors consider their "waveforms" secret, NDA'd
<hl>
(read: the bloddy drive signals to make the damned thing work)
<fridtjof[m]>
<electronic_eel "matrix works quite nicely, we ar"> I just read the chatlog from ~5h ago about bridges, which reminds me: can someone tell me how this message looks on IRC? On the matrix side, I'm replying to a message from that discussion
<hl>
02:16 <fridtjof[m]> <electronic_eel "matrix works quite nicely, we ar"> I just read the chatlog from ~5h ago about bridges, which reminds me: can someone tell me how this message looks on IRC? On the matrix side, I'm replying to a message from that discussion
<fridtjof[m]>
oh, interesting. I almost expected it to just cut the reply part
<whitequark>
matrix/irc bridges work shockingly well
<whitequark>
a near-native experience really
<whitequark>
discord isn't that good but i'm certainly willing to take it given how many people find it convenient
<d1b2>
<Qyriad> it took much npm fiddling to even figure out how to test the code change I made >.>
<d1b2>
<esden> @Qyriad ❤️ 😄
<ktemkin>
this'll be excellent for when I want to tag @esden like 400 times in the same message
<d1b2>
<esden> 😭 but I......
<ktemkin>
I'm sure at least 90% of them will be for good things
<d1b2>
<esden> at the end I am not sure it will increase the notification strength @Kate Temkin
<d1b2>
<Qyriad> so that's a feature I should request to discord, right? Increasing notification priority per mention?
<d1b2>
<Kate Temkin> @Qyriad when I specifically mention @esden, it should also send him an SMS per mention
<d1b2>
<Qyriad> …I'll get right on that one
<d1b2>
<esden> ROFL 😄 ... /me imagines a massive bullhorn jumping out of the computer screen
<kc8apf>
My recent experience with broadcom has been them saying they will only provide more info via an FAE. They will only allow us to talk to an FAE if we buy a support contract.
<kc8apf>
Please pay us so you can determine if your part is even usable for our system
<hl>
hahahaha
<whitequark>
kc8apf: wow, they let you buy a support contract? how generous
<whitequark>
i mean i'm being sarcastic but i've heard that this isn't a given.
<kc8apf>
Unclear.
<kc8apf>
The sales person has been slow to respond
<kc8apf>
They don't want us to buy their 100G switch ASICs apparently
<hl>
they genuinely seem to hate having to actually sell things
<whitequark>
CIA front company?
<whitequark>
maybe that's why the ASICs are called "Tomahawk" and "Maverick".
<whitequark>
and... whichever weapons systems is the 100G one
<hl>
but would a CIA front have a drugged sex dungeon?
<d1b2>
<miek> @WillC i've not tested with Glasgow, but i got around similar problems on ubuntu 18 by running python3.7 -m pip install pip to setup pip, then pip install --ignore-installed <thing> to install stuff
<d1b2>
<madbodger> I usually dodge issues like that with virtual environments.
<d1b2>
<WillC> Lol I'm working in a virtual environment @miek if I haven't sent you the VM for the team I will now. That is where I am trying to install this
<d1b2>
<WillC> I'll give that a shot though
futarisIRCcloud has joined #glasgow
Yatekii_ is now known as Yatekii
bvernoux1 has quit [Quit: Leaving]
<electronic_eel>
@esden you there?
<d1b2>
<esden> electronic_eel: more or less, having a very late morning ...
<electronic_eel>
good morning then!
<electronic_eel>
you have a few minutes to talk revC2?
<electronic_eel>
grr, don't understand how they can be this stupid
<electronic_eel>
they have one competetive advantage, and they are about to completely ruin it
<d1b2>
<Hardkrash> Do you have a lattice contact, I can let my GSM team know I’m disappointed about this with them 😉
<d1b2>
<esden> Everyone who has lattice contact should be expressing disappointment. And in the same sentence express that they should just publish the documentation of the bitstream and the timing database themselves, and stop wasting everyone's time.
<kc8apf>
electronic_eel: users of FOSS tooling are a tiny, tiny portion of their market
<kc8apf>
MachXO3D is positioned as a device to be included on every Intel-based server board
<electronic_eel>
with proper and popular open source tools, you can open completely new markets, see Arduino which saved Atmels ass for some years
<electronic_eel>
lattice could for example push into the educational market
<electronic_eel>
there you often don't need the biggest, fastest fpga, but something you can understand and tinker with on all levels
<Ultrasauce>
there is certainly a choir to be preached to here but the hard part is convincing the suits
<kc8apf>
electronic_eel: you're preaching to the choir. I've made these arguments to the FPGA vendors directly many, many times.
<electronic_eel>
I think key is understanding what motivated their change in license terms
<kc8apf>
I've argued it with VCs
<kc8apf>
in general, hardware teams and companies do not understand the value of opensource
<electronic_eel>
@esden so about revC2, I'd like to coordinate with you, as git merge of kicad layout doesn't work
<esden>
electronic_eel: sure I understand. I heard you mention the ADC swap.
<esden>
What is the reasoning behind it again?
<electronic_eel>
move to INA233. the reason is that it will allow us to measure and limit current
<electronic_eel>
so you can program a max allowed current, and the hardware will trigger ocp on it's own, without software intervention needed
<esden>
I see, that is useful indeed. We should prototype it in this version of the board before I finalize it. It is a good idea I think.
<electronic_eel>
I would really like to use glasgow as a test jig board for other products, measuring current is very valuable for that
<electronic_eel>
I have checked that out and currently on my screen
<electronic_eel>
about silkscreen: there is a "I2C" label next to the aux header, what is that about?
<esden>
Ok, I should probably move the branch to the official repository and create a pull request. So we can discuss the current state of the board.
<electronic_eel>
I don't mind working off your branch and send pulls there, but wouldn't mind the other way round
<esden>
Ohh DUH... I somehow thought it was just the i2C interface exposed ... my bad
<esden>
I will remove that :D
<electronic_eel>
thx
<electronic_eel>
there is another issue niklas found when working on the edinburg
<electronic_eel>
h
<electronic_eel>
the 5v rails and vioa and viob rails cross layers with just one via. this is a bit risky as there is >100mA flowing through
<electronic_eel>
a via could be conductive, but still have a manufacturing defect. it could go bad in this case, so better use two vias for these cases
<esden>
Ahh good. I think it is time to start creating issues for the revC2 so we can track these changes.
<esden>
I see there are a few more things to do before we are done with revC2 which is fine with me. :D
<esden>
I rather keep those issues on the main repo
<electronic_eel>
the question is if we want to collect them in your branch?
<esden>
so we should move it over there
<electronic_eel>
fine with me
<esden>
whitequark: is it ok if I push the revC2 branch to the main repo? Then we can keep working on it there.
<electronic_eel>
but I'd prefer if you (or someone else) could do the silkscreen and finetuning of the adc change - I think my layouts don't look as nice and clean as yours
<esden>
I am happy to do all / any changes we agree on as a group. :D
<electronic_eel>
do you plan any schematics changes in the next days? then I can take your current state and change the adc
<electronic_eel>
I mean if you don't plan any schematics changes
<d1b2>
<esden> I am not aware of any schematic changes at the moment. Just board silkscreen stuff.
<electronic_eel>
ok, so I plan to do the schematics for the adc change over the weekend
<electronic_eel>
it isn't that much, but it is some bom cost to shave off
<d1b2>
<esden> I was even thinking of switching to descrete parts, but it turned out it is not saving much money... I will look at the littelfuse part and see.
<electronic_eel>
what do you mean with discrete? like a single diode for each pin?
<electronic_eel>
I don't think this will save you much, will take much more time to assemble
<electronic_eel>
a cheaper combination would help though I think
<whitequark>
esden: so the "revC2" branch is a post-release one (i.e. once we call revC2 good enough we create that)
<whitequark>
you can push to wip-revC2 or something to make it clear what the nature of the branch is
<whitequark>
other than that all good
<electronic_eel>
wip-revC2 sounds good to me too
Exec1N has quit [Ping timeout: 240 seconds]
<esden>
whitequark: ok sounds good will rename the branch and push it to the main repo as wip-revC2
<whitequark>
yep
<whitequark>
then pull-request to master I think?
<esden>
yeh when we are finished with the design yeah
<esden>
or maybe for ongoing convo?
<esden>
Ohh you mean to have something to refer to in issues and discuss things to do ... right?
<whitequark>
sure
<whitequark>
there's no harm in having a PR sitting there
<esden>
sounds good
emilazy has quit [Ping timeout: 246 seconds]
lukego has quit [Ping timeout: 244 seconds]
furan- has quit [Ping timeout: 252 seconds]
_florent_ has quit [Ping timeout: 246 seconds]
ktemkin has quit [Ping timeout: 272 seconds]
sorear has quit [Ping timeout: 272 seconds]
englishm has quit [Ping timeout: 244 seconds]
key2 has quit [Ping timeout: 244 seconds]
analprolapse has quit [Ping timeout: 260 seconds]
eddyb[legacy] has quit [Ping timeout: 260 seconds]
flammit has quit [Ping timeout: 256 seconds]
arisum has quit [Ping timeout: 256 seconds]
levi has quit [Ping timeout: 272 seconds]
kc8apf has quit [Ping timeout: 272 seconds]
levi_ has joined #glasgow
key2 has joined #glasgow
_florent_ has joined #glasgow
evck has quit [Ping timeout: 272 seconds]
jacob|_ has joined #glasgow
futarisIRCcloud has quit [Ping timeout: 252 seconds]
nmolo has quit [Ping timeout: 252 seconds]
nmolo has joined #glasgow
jacob| has quit [Ping timeout: 272 seconds]
evck has joined #glasgow
emilazy has joined #glasgow
jacob|_ is now known as jacob|
eddyb[legacy] has joined #glasgow
kc8apf has joined #glasgow
furan- has joined #glasgow
arisum has joined #glasgow
analprolapse has joined #glasgow
lukego has joined #glasgow
futarisIRCcloud has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 265 seconds]
Stormwind_mobile has joined #glasgow
ktemkin has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 240 seconds]