log
399 entries in 0.068s
bvt: (talking about rk3399 here)
bvt: yes, but nevertheless the boards with these chips appear every day. perhaps need to show inca earplugs of some minimum size to get them?
bvt: to my understanding you design them yourself; devboards are just for testing the cpu/chipset
bvt: well, those are devboards, i don't think anyone sells them as a serious item. but amateurs - buy
bvt: (chinese messed with m.2 port wiring, need to buy strange adapter board to bring it to sanity)
bvt: i have an m.2 nvme ssd there, but the hw setup is convoluted enough to recommend bying *some other* board for these purposes
bvt: i have a http://archive.is/EUW9n item at home, with kernel from some arm64 distro and pizarro rockchip rootfs, but i never got time properly setup this device (plan was, run trb node)
bvt: it is not clear to me if big.little ever worked acceptably with linux -- they are tuning even today
bvt: iirc changed, but too recently to even consider a switch anyways
bvt: asciilifeform: rk3399 is a bit trickier in usage than rk3328 of pizarro rockchip -- big.little arch, so scheduling and power management have to come from rockchip kernel tree, not vanilla.
bvt: the kind of cloth used for lens cleaning works as well?
bvt: could be, i never got to disassemble and check the board after changing wlan card.
bvt: it has an annoing problem of producing high-pitched noise when running with ext. input devices or wlan on, but overheat happends only after ~45 min of compiling, which i don't do any more.
bvt: is it that much more stable with lenovo bios? i had it overheat with both orig. and coreboot variants, so stayed with coreboot
bvt: at the time i was getting mine - only w. T2400 and iirc slower cpu were available
bvt: right, t2400 is 32bit, t7200 is later generation - 64bit
bvt: please check, because all docks pointed into '32bit only' direction - perhaps it was disinfo.
bvt: hm. i have the same, but T2400 is 64bit in 'PAE' sense, not in register width sense.
bvt: this would actually be interesting for x60 machine owners as well. the register pressure would also increase on i386
bvt: only on mult, not on modexp
bvt: asciilifeform: depends on whether there will be a usecase for such item, but in any case shifts/adds should be simpler than comba
bvt: then, perf increase should be substantial
bvt: hi. the exact cut will depend on what % of ops in barret are mults
bvt: also, i was under impression that asciilifeform suggests to ditch C after getting sane iron ☟︎
bvt: http://btcbase.org/log/2019-04-25#1909969 << that clarifies the issue, thanks. i got momentarily confused because imho cuntoo (as gentoo repo snapshot) is too large to pull off http://btcbase.org/log/2019-04-24#1909621 - i see no way to replace gcc with tcc and 'rebuild world' without rewriting ebuilds/getting a ton of errors; but should be realistic with something smaller (which i plan to do). ☝︎☝︎
bvt: http://btcbase.org/log/2019-04-24#1909728 << he indeed looks very experienced http://archive.is/VOaOV#selection-1166.1-1192.0 http://archive.is/nmzYW#selection-3746.0-3773.78 http://archive.is/FeiYm#selection-3319.1-3321.349 ☝︎
bvt: though to my understanding he uses zeptobars photos at least sometimes (http://archive.is/pjqcH#selection-1139.1-1483.105 , http://archive.is/K1Efi#selection-3499.55-3503.154)
bvt: he worked with 580BM80A as well http://archive.is/01iuf, http://archive.is/RKAEx , also with feature recognition
bvt: http://btcbase.org/log/2019-04-24#1909723 << i will definitely write him ☝︎
bvt: *the cited link should've been http://btcbase.org/log/2019-04-24#1909727 ☝︎
bvt: http://btcbase.org/log/2019-04-24#1909683 << do you mean the pdf/word in the vm1 directory? or whole repo with e.g. http://archive.is/E2iex#selection-3535.0-3561.54 ? if there is a single document, i'd definitely read ☝︎
bvt: http://btcbase.org/log/2019-04-24#1909614 << i can do some experiments with tcc-based linux; this may be a too big chunk if i start with cuntoo, but should be possible with some very minimal linux. ☝︎
bvt: http://btcbase.org/log/2019-04-24#1909627 << added to the list of things to try ☝︎
bvt: http://btcbase.org/log/2019-04-23#1909552 << i grok this. the question is, how much work should go into cuntoo? ☝︎☟︎
bvt: PeterL: binary ave1gnat is already hosted by asciilifeform; but it's integration into cuntoo is an open problem that ave1 should be best equipped to handle ☝︎☟︎
bvt: http://btcbase.org/log/2019-04-23#1909490 << speaking of which, http://archive.is/pEMWM ; also, i guess elbrus-2 (~1985) and besm-6 are still running ☝︎☟︎☟︎
bvt: http://btcbase.org/log/2019-04-23#1909440 << this would involve getting binutils under our control - bigger part of these timestamps are added by ar/ld; tbh i even dunno if gcc is responsible for this at all. ☝︎☟︎
bvt: also, you can't build ave1gnat from scratch on fresh adaless system because of http://btcbase.org/log/2019-04-23#1909529 - so initial gnat binary will be required (ebuilds just download binary gnat for that). ☝︎
bvt: http://btcbase.org/log/2019-04-22#1909279 << you can't use adacore's gnat to bootstrap ave1gnat on musltronic systems, but http://btcbase.org/log/2018-05-15#1813753 works for that purpose; ☝︎☝︎
bvt: http://btcbase.org/log/2019-04-22#1909254 << i suspect that fixing direct gcc6->gcc4 step involves something like http://archive.is/cBg9N#selection-9.1340-9.1425 ☝︎☟︎☟︎
bvt: the problem with these both approaches is that it's impossible to get gnat/ada that way - gnat was bootstrapped from some commercial ada compiler in ~1994, and is self-hosted since that times. (well, impossible by definition with just tcc) ☟︎☟︎
bvt: http://btcbase.org/log/2019-04-23#1909396 << do you mean going [preinstalled gcc6] -> tcc -> gcc2.95 -> gcc4.7 -> gcc4.9 for cuntoo? or drop gcc entirely, try to get as much as possible running on tcc? ☝︎☟︎☟︎
bvt: thank you, this is a great honor to me
bvt: i see; if vendor can subvert the chip in nonobvious way by changing delays organizing a military style приемка would be the only option for actually using the devices
bvt: i get the propagation delay physics; i guess the question is how much is lost due to suboptimal design tools, vs max capability of hardware
bvt: i have to admit i have zero experience with these tools
bvt: the larger fpga - seems to be it https://symbiflow.github.io/prjtrellis-db/ ? last time i checked it was work in progress
bvt: asciilifeform: isn't ice40 a done thing, i.e. is there anything else to add to it?
bvt: asciilifeform: http://trilema.com/2015/la-chacarita/#selection-107.0-107.209 ?
bvt: yes, this is a point; i don't believe they'll even try to use oak - they have 'modern, improved' materials these days
bvt: http://btcbase.org/log/2019-04-15#1908583 << well, after ww2 germans did rebuilt everything as accurately as possible ☝︎
bvt: the only smaller item in my pipeline is unrolling comba for ch10 multiplication; and i'd like to give a shot a 'kill /dev/random and /dev/urandom' experiment, replacing them with buffers than can be directly fed from userspace, but this - even later. ☟︎
bvt: hello. just to give you a bit of information: i am alive; i'm pretty short on work time this month; given that this did not cause any further discussion i will stall it for some time.
bvt: phf: http://bvt-trace.net/2018/10/vpatch-replacing-mktemp3-take-two/#selection-13.0-31.43
bvt: i guess asciilifeform will comment tomorrow if he feels good enough (gute besserung!); i have to go to sleep right now
bvt: (iirc asciilifeform has a SU keyboard-driven prom burner, which may be a valuable device for bootstrap)
bvt: yes, with tape writers/serials, os can be delayed much further; persistent storage would complicate bootstrap a lot.
bvt: yes, i agree that a simple and clear boot sequence is a requirement
bvt: re add with carry, http://www.loper-os.org/?p=1913#selection-2329.9-2347.129
bvt: unfortunately i've worked mostly with x86, so the only other assembler i've seen was arm64 (did not look at it's instruction encoding though)
bvt: re 1, both worth using (but no lisp cpus here yet) and with features useful for bootstrapping
bvt: re 2, after a restricted ada assembler, should a ada-dos be built? mes assumes that linux kernel is a given, which imho is a big hole in the process
bvt: but are there any other features that help the bootstrap? even if this increases hardware complexity a bit
bvt: i.e. re 1 you opted for architecture where instruction encoding is easy to do by hand
bvt: to my understanding there are two questions: 1. what are the requirements to the architecture 2. what is the first interim stop after a post-M1 assembler? ☟︎
bvt: http://btcbase.org/log/2019-04-05#1906987 << well, this depends on the subset of ada; re contributors - this is a known issue ☝︎
bvt: of course, ada/gnat is too complex for bootstrapping as-is, but i guess equivalent safety properties would be still required
bvt: so far everything points into the direction opposite of linux/c (http://mocky.org/Log-Reference-Why-Ada/ may be interesting)
bvt: indeed there is; the relevant thread is http://btcbase.org/log/2019-03-18#1903170 ☝︎
bvt: !!v 3E663D0A962864DA7A238FA8497667A046916568FA36ED6112CEAE9C25A9FBAE
bvt: !!rate OriansJ 1 stage0 author
bvt: !!up OriansJ
bvt: started pizarro isp (http://pizarroisp.net/), and wrote FFA crypto library, in case you wondered what 'FFA style' from my investigation report was: http://www.loper-os.org/?p=3141 - vpatch + a write-up for helping fitting-in-head the code
bvt: to give you a short introduction, people from this place have developed FG TRNG (http://nosuchlabs.com/hardware.html), V versioning system (http://btcbase.org/patches?patchset=v), Eulora MMORPG (http://ossasepia.com/), maintain a btc reference node
bvt: OriansJ, you can register a GPG key with deedbot (http://deedbot.org/help.html), i'll rate you and you'll be able to up yourself.
bvt: OriansJ is the stage0 author, please up him upon request
bvt: !!up OriansJ
bvt: mircea_popescu: i'll try to get him into #trilema on the weekend
bvt: asciilifeform: yes, ending up with the same gnu stuff is pretty sad work result
bvt: http://btcbase.org/log/2019-03-26#1904859 << that 'me' was OriansJ, if wiki change log can be trusted ☝︎
bvt: i also don't like how at the 'mes' stage a linux kernel 'magically' appears as the underlying substrape, while stage0 parts are designed to work without os
bvt: asciilifeform: they claim that it is work-in-progress, but in fact c compiler that manages to compile tcc may be less then 10% of required work.
bvt: OriansJ in #bootstrappable has a notion of hygiene (at least basic, ie groks fits-in-head), and still works on the stage0; i had no interaction with janneke (mes author) yet, so can't make claims about him. he does make some noise in the #bootstrappable and #guix
bvt: linux bootstrap with actual mes is way more disappointingto stage0 components (the claim is 'c compiler is scheme and scheme interpreter in c', but in fact they require bash, patch, tar, etc. for the bootstrap).
bvt: hello. i did not manage to finish work on mes report part 2 last week, and i don't have a possibility to do any work this week. i plan to finish it around weekend next week.
bvt: i.e. finishing stage0/mes integration, and also there is a problem of bootstrapping gnat
bvt: well, the question is then, whether we want to do this for cuntoo -- this work will need some resources dedicated to it.
bvt: it's just that if components fit in head, imo alpha/beta does not apply
bvt: nope, it's not 'did' even for linux; this work is in WIP, not even alpha stage.
bvt: otoh, author did mention that most of the tools can be easily made to work on e.g. dos
bvt: asciilifeform: yes, this is a problem; for example, their x86_64 hex0-2, as little sense as this can make (in presence of intel me&etc), are done as linux binaries: currently their goal is to bootstrap linux
bvt: http://btcbase.org/log/2019-03-17#1903106 << i also agree that it is; i don't find myself knowledgable enough to make a decision on the republican cpu architecture, but for bootstrapping using ice40 with its limited resources a simple mips core sounded fitting. ☝︎
bvt: http://btcbase.org/log/2019-03-17#1902991 << as far as the 'stage0' is concerned, there is one guy manaloneing (OriansJ in #bootstrappable), and a dozen of people watching. can't say anything about 'mes' yet, it has a different author. ☝︎
bvt: hello
bvt: ok, i see
bvt: iirc the c-t version of algorithm comes later - around section 5. there is a formula for calculating upper bound of iterations, but I did not check his math.
bvt: also, i did not forgot about http://btcbase.org/log/2019-03-01#1899904 , but had too little time to investigate it properly; will try to do tests over this week and do a writeup on the weekend ☝︎
bvt: asciilifeform: https://gcd.cr.yp.to/papers.html -- rather new constant time gcd from djb. i did not look at it closely so can't say if it's anything good or belong to the kunstkammer
bvt: rather, http://btcbase.org/log/2019-03-10#1901346 ☝︎
bvt: trinque: after applying http://btcbase.org/log/2019-03-10#1901339 your signature verifies correctly. thanks! ☝︎