<peterm6881>
i was gonna say dfrobot not only released a new version of the firmware update tool, compatible with the CH340 bridge, but they also released new firmware for the board, bumped from 0.1 to 0.2
<peterm6881>
windows process still broken though, ah well
<peterm6881>
i think ive had enough of this. Too much actually
<Xogium>
and I doubt that firmware is really much different from the mangopi one
<peterm6881>
did mangopi release new firmware?
<Xogium>
yeah, they did, the other day ? You were the one that pointed that out
<peterm6881>
cant remember
<Xogium>
you said they had uploaded new prebuilt images
<Xogium>
they had none of these before or something
<peterm6881>
oh yeah, on widoras website
<peterm6881>
mangopi.org doesnt load
<peterm6881>
pretty much everything that COULD be broke, is in fact broke. They nailed it 100%
<peterm6881>
so, i think we're done with this
<peterm6881>
agreed?
<peterm6881>
brb
peterm6881 has quit [Read error: Connection reset by peer]
peterm6881 has joined #Speedsaver
<peterm6881>
back
<Xogium>
its your call to make on that one, I guess
<peterm6881>
we dont have any choice
<peterm6881>
its way beyond our capabilities
<Xogium>
how's that ?
<Xogium>
its not like the windows software matters
<peterm6881>
my point is nothing works
<peterm6881>
you wont fork the software because USB is broken and our external tree wont boot, and we have no path to fix either of those. Ergo, its a dead end
<peterm6881>
windows was just the final straw to prove that absolutely nothing works
<Xogium>
I'm sorry if I'm trying to not put more trash on the market and trying to fix things before I actually try working on a possible fork
<peterm6881>
can we adapt our external tree to use current u-boot
<peterm6881>
i dont see it as putting trash on the market, i see it as publishing what we've got in the hope that someone will come along and fix it for us
<Xogium>
no, like I've said before, current u-boot still is too young and the community effort for supporting the f1c100s and f1c200s SoC has barely begun
<peterm6881>
github users do that all the time. We already published broken shit
<peterm6881>
well the windows stuff is so awful it takes my breath away
<Xogium>
fine then. I suppose I'll take down the mangopi repo
<Xogium>
shouldn't have wasted my time working on it anyway
<peterm6881>
the update tool says FEL mode detected even before i press the buttons, goes off into la la land, and meanwhile at this point Windows detects an unrecognised USB device
<peterm6881>
dont take it down
<Xogium>
that's because the update tool detects your board in FEL mode for real
<peterm6881>
do not do that
<Xogium>
if you don't have a micro sd inserted, it goes to FEL automatically. No need for the buttons
<peterm6881>
never undo actyual progress, since there's so little of it
<peterm6881>
actual
<peterm6881>
theres no micro sd inserted, i knew that would be likely to confuse things
<Xogium>
don't see what's the point since you give up on the idea
<Xogium>
what's the point in maintaining an external tree for future buildroot releases of a board we don't care about as speedsaver
<peterm6881>
maybe somebody will fix it
<Xogium>
maybe
<Xogium>
but then, what's the point still ? If we don't use it, this thing needs a new maintainer
<peterm6881>
its not like we're gonna jump to something else, it can just sit there
peterm6881 has quit [Read error: Connection reset by peer]
<Xogium>
well, if you dump the platform as unusable
<Xogium>
then we go back to orange pi obviously
<Xogium>
but I will still have to maintain the whole mangopi external tree for future lts of buildroot, doing builds to verify it didn't blow up for months and we were not aware ?
<Xogium>
that also means following whatever the vendor does, if they add this or that I have to add it there too
<Xogium>
anyway, brb washing stuff
peterm6881 has joined #Speedsaver
<Xogium>
back
<peterm6881>
the new firmware dfrobot released fixes their wiki for Linux
<peterm6881>
i just erased the nand
<Xogium>
is dfu even working
<Xogium>
erasing the nand in u-boot means that the nand is detected, so that's a good sign. But is dfu-util even detecting a dfu device
<peterm6881>
nearly at that point. i just made the 2 scripts executable
<Xogium>
running sudo dfu-util -l would let you know if it was
<peterm6881>
yes, they fixed it
<Xogium>
good on them
<Xogium>
now if we could just do that in buildroot
<peterm6881>
the name of the script changed, so their wiki is out of date, but it works
<peterm6881>
dfu-nand-ubifs-i2c-spi.sh
<peterm6881>
is the new name
<Xogium>
so is it currently burning the image ?
<peterm6881>
Opening DFU capable USB device...
<peterm6881>
ID 1f3a:1010
<peterm6881>
Run-time device DFU version 0110
<peterm6881>
Setting Alternate Setting #4 ...
<peterm6881>
Claiming USB DFU Interface...
<peterm6881>
Determining device status: state = dfuIDLE, status = 0