peterm6881 has joined #Speedsaver
<peterm6881> im over here
<peterm6881> guess SC6502's Raspberry Pi blew up
<peterm6881> heh
<Xogium> heh maybe
<peterm6881> rest in peace
<peterm6881> hi Xogium are you having a good day?
<Xogium> its not too bas so far
<Xogium> ;)
<Xogium> *too bad
<peterm6881> its ok , I have bas days too
<peterm6881> where u cant type for shit
<peterm6881> ;)
<peterm6881> licheepi-nano-buildroot
<peterm6881> oops
<peterm6881> so did we build that from the latest Buildroot?
<peterm6881> or
<peterm6881> what
<Xogium> which one
<Xogium> the one that kernel panics ?
<peterm6881> yeah
<peterm6881> i think i must have
<Xogium> no, we used the original buildroot fork of mangopi
<Xogium> they didn't provide this as an external tree like we do for speedsaver, or how it's down for the unframework licheepi-nano-buildroot
<peterm6881> no wait, I think I just downloaded the latest stable released
<peterm6881> ffs
<peterm6881> release
<peterm6881> so was that why it kernel panicked
<Xogium> this is a complete fork of buildroot
<Xogium> and the one that panicked
<Xogium> it is 2020.02.7 version of buildroot, no longer able to build on archlinux, still manageable in ubuntu
<peterm6881> i dont understand, what was the image you shared?
<Xogium> the image I shared was make from the unframework licheepi-nano-buildroot repo
<Xogium> it never talked over serial
<Xogium> then you found official mangopi buildroot, I tried it on arch, build failed
<peterm6881> but the readme says download Buildroot
<Xogium> told you to try on ubuntu, you got an image that worked, in the sense that it booted… but then failed to mount the rootfs and panicked
<peterm6881> If using Vagrant VM to perform the build:
<peterm6881> vagrant plugin install vagrant-vbguest
<peterm6881> cd licheepi-nano-buildroot # location of this repo's files
<peterm6881> # install required plugins
<peterm6881> vagrant plugin install vagrant-disksize
<peterm6881> vagrant up
<peterm6881> vagrant ssh
<peterm6881> Otherwise, download Buildroot and extract it into a folder that is separate from this repo's files.
<Xogium> that is unframework's licheepi-nano
<Xogium> I'm talking about, this
<peterm6881> read back this conversation to 18:41:15
<Xogium> unframework's repo never made the board boot, official buildroot from mangopi folks made it boot, then panic
<peterm6881> sry i get easily confused. ok let me go through that one. I wanna get back to something that at least partially worked. Bear with me
<Xogium> yeah. I won't be able to use it here, so I'll probably investigate the unframework repo
<peterm6881> you dont think it could be fixed to work in Arch?
<Xogium> to fix it, it would need to be upgraded to 2021.02.8 of buildroot
<peterm6881> is that .... like... hard n shit
<Xogium> not easy to do that because they forked the entire buildroot project as you can see
<Xogium> it doesn't have the same stuff as ours or the unframework repo, external.mk, external.desc
<Xogium> it isn't an external tree you can hook up to pretty much any br version with a minimum of effort, but a complete fork of buildroot
<peterm6881> why would mangopi themselves leave stuff out....
<peterm6881> thats a bit....weird
<Xogium> because they don't really care
<Xogium> and they aren't the only one
<peterm6881> that makes no sense, if they wanna sell a dev board they made
<Xogium> it's common to see vendors deciding to fork buildroot, put patches on top, never send said patches to upstream buildroot, and never upgrade
<peterm6881> but i agree they've been proven to no care about what works and what doesnt
<peterm6881> not
<peterm6881> like their windows tool
<Xogium> just like vendors do with the kernel or the bootloader
<Xogium> they don't seem to get it
<Xogium> that the whole point of open source and free code means you could do a minimum of effort to provide your own code to upstream, get important security fixes or updates
<peterm6881> thats why i think we need to go back to basics with a shiny new SIP and do things our way
<Xogium> instead they fork the repos, do their own little thing in their own little world, and never ever contribute
<peterm6881> instead of dicking with all this CRAP
<Xogium> but you find that practically everywhere
<Xogium> allwinner does that, rockchip does that, amlogic does that, raspberry pi foundation does it
<Xogium> hell, even seeed did this
<Xogium> they made a frankly nice board, hardware side
<Xogium> but the software ? They might have got debian buster to work, which is more than we can say about some vendors
<Xogium> but they sure did the very same pattern
<peterm6881> we could rock the boat if we built support for the F133-A
<peterm6881> but is it feasible
<Xogium> tossed the board on the market, provided some 2019 debian 10, and never updated it again
<peterm6881> its a huge risc
<peterm6881> -v
<Xogium> indeed
<peterm6881> would it be fun?
<peterm6881> or a dystopian nightmare
<Xogium> frankly, as things are right now, it will be difficult. I don't have any idea what's the state of the support of the SoC in linux kernel, for all we know it's not supported at all, we might need to bother allwinner to figure out what the hell to use as kernel, same for bootloader
<peterm6881> if the mangopi-mq is 9.50 USD, I know the F133-A ticks the money box
<Xogium> to be fair here, we could do exactly the same thing with the f1c200s
<Xogium> make our own board
<peterm6881> we could, but all the work on the F1C200's was done in 2017-2019
<Xogium> the whole point of buying these dev boards is to evaluate the f1c200s platform for our use, after all
<Xogium> if we can't evaluate the risc-v SoC with a dev board before jumping and trying to make our own, honestly, that doesn't exactly tempt me
<peterm6881> yes I know, but immediately we've hit a wall of nothing works, including your Arch build environment. Reason: the world has moved on
<peterm6881> yeah i agree its a tough call
<Xogium> it could be the very same thing with this SoC, for all we know
<peterm6881> given you're the key to all this nonsense, its your call to make
<Xogium> plus, I've been trying to help you remotely debug this, which is not really helping because remote debugging of boot issues is hard
<Xogium> for all we know, when I'll get mine, I'll be able to figure out why it didn't want to even begin booting on the unframework repo
<peterm6881> yeah my plan was to give you remote access, but because they put a chip in the way of ttyS0 and you cant physically press reset, fucked
<Xogium> well, even without a chip in the way of the serial console, I wouldn't be able to do that
<Xogium> I suspect that it might just be something very stupid like just trying to use the wrong device tree
<peterm6881> yeah...u could reboot the server but you'd lose your connection, no win situation unless i rig up a relay to the alarm board to reset the R3 :)
<peterm6881> at that point it all gets a bit , nuts
<Xogium> it will be much easier to dig into this issue once the boards are here
<peterm6881> nicely summed up
<Xogium> what's their size anyway ?
<peterm6881> smaller than a raspberry pi zero
<Xogium> nice
<Xogium> but bigger than the nano
<peterm6881> probably the same size as a RPi Pico, but im not sure
<Xogium> frankly the nano, it's so small I'm scared I'll crush it to nothing when I hold it to plug the micro usb cable in lol
<peterm6881> ok its rectancular, one side is only the size of the 2 micro usb sockets and 2 rows of pins
<peterm6881> the other side is about 3 times that length
<Xogium> nice
<Xogium> yeah the nano is about the size of a full size sd card. Not the micro sd kind, but full sd
<peterm6881> yes bigger than the nano, on one side, not the other
<Xogium> that said I've seen a much much smaller pcb than that lol
<Xogium> it's design to fit inside the usb ports of a computer. Like, inside the socket themselves
<Xogium> it has a stm32l4 microcontroller inside
<Xogium> that pcb is well… smaller than a micro sd card
<Xogium> I was actually scared to drop it when I received it lol
<peterm6881> i can find my lichee zero, im sure i had nanos buit i dunno what happened to them
<Xogium> I used cable ties, you know this stuff they use to put around cables for packing, it's metal covered with plastic
<peterm6881> but *
<Xogium> there is a tiny hole on one end of the pcb, so I threaded that through. I can tug on it that way and remove the device from my usb port
<peterm6881> good grief
<peterm6881> you're building quite a working knowledge of this stuff
<peterm6881> Buildroot will download sourcecode when compiling the firmware. You can grab a TRUSTWORTHY archive of 'dl' folder for speed up
<Xogium> which one ?
<peterm6881> do you know what this means?
<peterm6881> sbc's in general
<Xogium> yeah it means that buildroot will just download the source code of every piece of the system
<peterm6881> it would be great to build our own
<peterm6881> grab a TRUSTWORTHY archive of 'dl' folder for speed up
<Xogium> and they apprently offer a download archive with everything already inside, or some such
<peterm6881> what do they actually mean by this those
<peterm6881> grab it from where??
<Xogium> who knows ?
<peterm6881> though *
<Xogium> I didn't really bother with that since I have a fast connection anyway…
<Xogium> and it is questionable to imply this will make your build go faster, since you still have to download their archive. It won't make you save time, in the end
<peterm6881> it couldnt fix your failure to build?
<Xogium> no it is compilation error
<peterm6881> mangobuge is the guy. Its his repo and its the same guy who posts on MangoPi's Twitter account
<peterm6881> he's their board designer too.... he posted a link to an update of KiCad
<peterm6881> interesting guy.....
<Xogium> I bet they don't even know it fails to build on anything too recent
<peterm6881> too busy getting RTOS to run on a D1
<peterm6881> we just need one fucking thing, and make it work beautifully, fully documented
<peterm6881> simplicity
<peterm6881> I have some news
<peterm6881> ok just to clarify, the Allwinner D1s is aka F133
<Speedsaver> Title: D1s - linux-sunxi.org (at linux-sunxi.org)
<Xogium> hmm
<peterm6881> thats not the news
<peterm6881> wait
<peterm6881> For Xuantie CPU Series Kernel build
<peterm6881> The D1s features a single RV64GCV[3] core XuanTie C906 from T-Head Semiconductor (subsidiary of Alibaba).
<peterm6881> By the way T-Head / Alibaba have committed to going Open Source. But what that actually means in practice, who knows
<Xogium> hm
<Speedsaver> Title: YuzukiNezha D1s - linux-sunxi.org (at linux-sunxi.org)
<peterm6881> This is a very expensive dev board, 100 USD, MangoPi-MQ got a lot of attention because its going to be a tenth of the price, supposedly
<peterm6881> question: is c-skys buildroot repo for the Xuantie CPU any good?
<Xogium> hmm
<peterm6881> i notice it talks about T-Heads own ICE board, but I dunno if thats a thing
<peterm6881> or vapourware
<Xogium> confusing
<peterm6881> The D1s features a single RV64GCV[3] core XuanTie C906 from T-Head Semiconductor (subsidiary of Alibaba)
<peterm6881> c-skys repo claims to be buildroot for it
<Xogium> I know, the buildroot repo is confusing
<peterm6881> ok im gonna let you think about that one. But its an interesting place to start for a brand new SIP in a brand new architecture right?
<Xogium> dunno
<peterm6881> lol;
<Xogium> we don't even know if it works, they of course tested on super old system
<peterm6881> ironic, since its kinda cutting edge
<peterm6881> for Allwinner
<Xogium> they probably only support their own boards
<Xogium> meaning that mangopi will have to do their own buildroot again
<peterm6881> this is moving fast...
<peterm6881> so, the Nezha was the single core dev board, 100 USD
<peterm6881> the RVB-ICE is dual core
<Xogium> aren't those the same one that make the polar fire board ?
<Speedsaver> Title: T head RVB ICE Development Board,Dual core XuanTie C910 RISC V 64GC ,1.2GHz, Support Android/Debian System|Demo Board| - AliExpress (at www.aliexpress.com)
<peterm6881> the 414 USD
<peterm6881> the T-Head RVB-ICE is 414 USD
<Xogium> yeah risc-v is still a young architecture
<peterm6881> we need this D1s....
<Xogium> the price for the most powerful boards is still very high
<peterm6881> wait let me check your question
<Xogium> like this one
<Speedsaver> Title: HiFive Unmatched - SiFive (at www.sifive.com)
<peterm6881> looks like a company called microsemi made Polar Fire
<peterm6881> I think this a possible interesting direction.......
<Xogium> I don't know if risc-v is worth it yet tbh especially not if we start straight from scratch
<peterm6881> ok can youi do something for me
<peterm6881> you
<Xogium> sure
<peterm6881> at least check out the c-sky repo and let me know if it looks sound
<Xogium> like I said, it's confusing me, it's a weird layout, it's neither a full buildroot fork or an external tree
<peterm6881> but yeah, its only the first step on a pretty big mountain
<peterm6881> yes its literally just for the CPU
<Xogium> no no it's for a board
<Xogium> or well a serie of boards based on these
<peterm6881> like you said, MangoPi will have to make their own Buildroot
<peterm6881> unless we can, based on c-sky
<peterm6881> oh yeah, true, its for the Ice
<Xogium> would make no sense if it was for a cpu
<peterm6881> and no, i dont plan to buy any lol
<peterm6881> but id definitely buy a bunch of MangoPi-MQ's
<Xogium> dunno if its worth it
<Xogium> do we even have the pinouts ? Do we have what our project would need ?
<peterm6881> we can get a pinout from the schematic. MangoPi pulished it, with a Bill of Materials
<Xogium> kinda weird they didn't do that with the r3, huh
<peterm6881> yes indeed. Maybe T-Head insisted, under their open hardware commitment
<peterm6881> At the conference, Zhang highlighted their RISC-V development progress which includes their four high-performance RISC-V cores XuanTie E902, E906, C906, and C910. Alibaba announced it has opened sourced those cores which will now go under a new name called OpenE902, OpenE906, OpenC906, and OpenC910 respectively. Those cores are now available on the T-Head Semiconductor GitHub.
<peterm6881> why wasnt I told about this.....
<peterm6881> ;)
<peterm6881> ok I have the partially working image again
<peterm6881> interestingly, it's 109 MB
<peterm6881> the one you sent me was only 19 MB
<peterm6881> weird
<Xogium> they probably add way more stuff
<peterm6881> If i connect it to the server, could you capture the entire post?
<Xogium> possibly
<peterm6881> if I reboot the device for you
<Xogium> but I already know what is the cause of the panic
<peterm6881> remind me?
<Xogium> either it doesn't wait long enough for the micro sd to show up, it lacks the driver for the sdio controller in the kernel, it misses the entry in the device tree, or it doesn't know about the filesystem it is trying to use
<peterm6881> its seeing the 128 MB GigaDevice SPI NAND, so thats good news. Definitely a DFU issue then
<peterm6881> ah yes i remember you said that twice before lol, but will post give you more clues as to WHICH
<Xogium> not really
<peterm6881> can i suggest you capture it anyway, since the boards I sent probably wont do anything by the time they arrive
<peterm6881> i cant send it to you, because screen doesnt scroll beyond the ... umm.. screen
<peterm6881> and Putty in Lubuntu doesnt let you copy and paste, crazy fucking shit
<peterm6881> it does in Windows, but Hexchat broke itself in Windows with an automatic update and now it wont install at all
<Xogium> I can try
<peterm6881> gimme a sec
peterm6881 has quit [Quit: Leaving]