<sc6502>
hey all, gotta be a quick one, going out soon.
<Xogium>
sc6502: heya
<Xogium>
sc6502: so er yeah… the problem is that now navit does what you said it would waits forever for a display… but spams you with i2c errors all the while
<Xogium>
peterm6881: just leme finish the readme for our new build and I'll try and have a look at the orange pi one
<sc6502>
I take it there is no initial message of "there is no display"
<Xogium>
sc6502: nop
<sc6502>
It seems odd that it can open the display successfully (apparently), then fail to write to it.
<Xogium>
quite so
<sc6502>
Rather than detect for possibly failed open, I'll just nuke the error message this evening.
<sc6502>
Anyway, gotta go run round a field for an hour, under the guise of "exercise"
<peterm6881>
:)
<peterm6881>
...enjoy!
<peterm6881>
fun stuff is happening. MangoPi uploaded an R3c schematic, AND a Bill Of Materials
<Xogium>
fraking finally
<Xogium>
who did that, mangobuge or dfrobot ?
<peterm6881>
it shows a CH340e now, although it appears to show it connected to pe0 and pe1, which i dont understand
<Xogium>
sigh
<peterm6881>
lol maybe i just dont understand it, but i believe pa-pf are physical hardware pins
<peterm6881>
ive sent the schematic, bom and silk screen masks to my Pakistani friend Arslan
<peterm6881>
see if we can create our own gerbers
<peterm6881>
what that would mean is no more carrier board, integrated screw terminals, screw mounting holes, mechanical drawings and the ability to make changes
<peterm6881>
ok I ran a make clean && make -j5, randomly
<Xogium>
feel free to test my instructions… they should work but who knows
<Xogium>
now let me try and debug the orange pi one
<peterm6881>
excellent work Xogium
<peterm6881>
can i just check, your testing on manopi was definitely on 2022.02?
<peterm6881>
mangopi
<Xogium>
also if you use the same buildroot directory for the buildroot that build your orange pi you might want to use a different name than output/speedsaver for O= and subsequent cd
<Xogium>
yes
<peterm6881>
ok thanks
<peterm6881>
i'll just nuke it and reclone
<Xogium>
Ididn't mean the external tree I mean buildroot
<peterm6881>
im really sorry, im doing something stupid
<peterm6881>
peter@peter-powermatemlxxx:~/buildroot-2022.02$ for p in /home/peter/buildroot-speedsaver-mangopi/buildroot-patches/*.patch; do patch -p1 < $p; done
<peterm6881>
bash: /home/peter/buildroot-speedsaver-mangopi/buildroot-patches/*.patch: No such file or directory
<Xogium>
its path to the external tree you just cloned
<peterm6881>
yeah just shoot me
<peterm6881>
cant believe io fell into that trap again lol :)
<peterm6881>
its a useful reminder just how dumb i am
<peterm6881>
;)
<peterm6881>
ok building now
<Xogium>
you were the one that asked me to word it like this even lol
<peterm6881>
can i make a minor suggestion, in the readme instructions, id put a line separating the 4 steps in the build section
<Xogium>
blank lines between each command ?
<peterm6881>
yeah previously it was more complicated! i guess i out dumbed even myself
<peterm6881>
yeah just to separate them for clarity
<peterm6881>
its building nicely, exciting times
<peterm6881>
im soldering up screw terminals to PE0 and PE1
<Xogium>
also here's a trick, if you want to figure out why the orange pi speedsaver build really crash, what you can do is avoid passing -j option to make
<peterm6881>
ohh
<peterm6881>
good knowledge thank you
<Xogium>
that will disable parallel build so it will be slower but since buildroot will then build only one package at a time you will be able to see exactly why it crashed
<peterm6881>
understood, makes perfect sense, good tip
<Xogium>
are the instructions for falshing clear ?
<peterm6881>
guess what?
<peterm6881>
let me look, hang on
<peterm6881>
are you sure you dont always have to erase a mangopi-r3c straight out of the box, like the wiki described?
<Xogium>
it should be empty
<Xogium>
if it wasn't, then you wouldn't get straight into FEL mode
<peterm6881>
out of the box it doesnt go straight into fel mode, i think it has to be formatted. Remember nand showed up as none fitted
<Xogium>
nop for me it went straight into FEL
<peterm6881>
I think thats because I formatted it before I sent it, but im not 100% sure
<Xogium>
but that's easy to check I have still one blank mangopi
<Xogium>
hmm
<Xogium>
ah, maybe
<peterm6881>
i'd need to get some more. But im pretty sure going straight into fel wasnt a thing
<Xogium>
well if its really the case then I'll fix up the readme
<peterm6881>
id need to check. I cant remember if i formatted them all
<peterm6881>
its most likely both of yours will be the same, but yes it would be useful for you to try the other one
<Xogium>
I will soon as I'm done building orange pi speedsaver
<peterm6881>
i discovered mangopi designed the R3c on Kicad
<peterm6881>
when you get a chance, try sc6502's commit
<Xogium>
yep
<peterm6881>
ok good news, mango just built successfully on Lubuntu
<peterm6881>
exciting times
<peterm6881>
now the fun begins.......getting it onto the nand!
<peterm6881>
by the way, if Arslan can create new gerbers, we can specify whatever nand we want
<Xogium>
well yes and no, who'd be manufacturing it for us ?
<peterm6881>
theres a few factries here in Northern Ireland
<peterm6881>
factories
<Xogium>
I doubt they would offer you such a low proce as dfrobot did, though
<Xogium>
er price
<Xogium>
if they don't make it $10/board like dfrobot suggested to you as price, then
<peterm6881>
yes, we'll back both horses.
<peterm6881>
heres the thing
<peterm6881>
it gets rid of the carrier board
<peterm6881>
thats the main advantage
<peterm6881>
plus we can create mechanical drawings
<peterm6881>
as it is, Janangas enclosure will have to be based on the carrier board, since we dont have mechanical drawings for the MangoPi-R3c
<Xogium>
what do you mean carrier board
<peterm6881>
now, its possible mangopi will publish them, if they exist
<Xogium>
for me a carrier board is the term used to describe a board like the odyssey where the SoC and such is separate from the rest
<peterm6881>
the carrier board mounts the mangopi-r3c and provides the screw terminals, plus board mounting holes
<Xogium>
oh yeah
<Xogium>
in that sense
<Xogium>
got it
<peterm6881>
its early days, ive provided Arslan with all the information available, it might not be viable. But im just getting the ball rolling on that
<peterm6881>
for now, the carrier board is definitely a viable option, in fact ive sketched it
<peterm6881>
so in due course, ill do a cost analysis of making it ourselves
<peterm6881>
it could well be bananas, but you see the advantages im sure
<peterm6881>
its useful to know if we COULD go that way. Full control
<peterm6881>
unless Allwinner cancel the F1C200s of course :)
<peterm6881>
its a cool chip
<Xogium>
well yeah but then we'd be screwed no matter what
<peterm6881>
na we'll drop in something else
<peterm6881>
this is a great board Xogium , good find my friend
<peterm6881>
yeah by the way i know i made that SOUND simple, but i realise from a build perspective, its back to square 1 lol
<Xogium>
well yes but I mean I'd have to port this work to yet another platform the day the f1c200s is discontinued
<peterm6881>
yeah im not making light of it. The onus is on us to ship a shit ton of them
<peterm6881>
then it wont get cancelled
<peterm6881>
stunning work this last couple of weeks
<Xogium>
st started work on a new SoC in the mp1 family
<Xogium>
stm32mp13
<Xogium>
how do I know that ? I found it in the kernel logs. They are mainlining a device before it even gets released to the public
<Xogium>
now that's good policy
<Xogium>
there's not a single mention of it yet anywhere on their website
<peterm6881>
interesting, how much is it?
<Xogium>
no idea
<Xogium>
the only info there is on it I got from the kernel logs and commits
<peterm6881>
did you try your other board for being in fel mode?
<Xogium>
nop not yet am trying out sc6502's commit
<peterm6881>
this one needs formatted, so yours probably will too
<Xogium>
ah
<peterm6881>
but check it first
<peterm6881>
i think thats why the wiki was done the way it was. I dont know why they ship them that way
<Xogium>
makes sense
<peterm6881>
straight into fel would have been way better out of the box
<Xogium>
yeah
<Xogium>
ah well
<peterm6881>
question
<peterm6881>
are you there?
<peterm6881>
thats not.. etc..
<peterm6881>
before I follow your flashing guide, am I still in ~/buildroot-2022.02-mango/output/speedsaver
<Xogium>
peterm6881: what do you mean ?
<peterm6881>
is that where I run sudo sunxi-fel -p uboot images/u-boot-sunxi-with-spl.bin from, or is that run from the fel command prompt itself?
<peterm6881>
im following your readme
<peterm6881>
just not sure where i should be, when i run your commands
<Xogium>
you shouldn't have moded from the output directory where which you ran make
<Xogium>
*moved
<peterm6881>
so sudo sunxi-fel -p uboot images/u-boot-sunxi-with-spl.bin is run from the output directory, correct?
<peterm6881>
its pretty clear enough, i just wanted to be absolutely certain
<Xogium>
yes
<peterm6881>
i ran the next command withing 15 seconds of getting the fel command prompt back, but i still got sudo dfu-util -a u-boot -D images/u-boot-sunxi-with-nand-spl.bin
<peterm6881>
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
<peterm6881>
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
<peterm6881>
dfu-util 0.9
<peterm6881>
This program is Free Software and has ABSOLUTELY NO WARRANTY
<Xogium>
I think the boot will not be insanely fast
<Xogium>
like never
<Xogium>
its part of using raw flash, ilnux and u-boot both perform checks to ensure data integrity
<peterm6881>
ok i have news
<Xogium>
will do another build I just realized we have a tiny problem
<peterm6881>
we have a fix
<peterm6881>
so the gps on PE0 PE1 just works
<peterm6881>
you know we have no startup jingle?
<Xogium>
we do
<peterm6881>
whats the login for this
<peterm6881>
i forget
<Xogium>
same as orange pi's
<Xogium>
root navit
<peterm6881>
lo,l i just realised
<peterm6881>
yeah
<peterm6881>
yeah we do have audio, as you said earlier its very quiet
<peterm6881>
let me check the settings again
<Xogium>
even with headphone boosted up
<peterm6881>
by the way what was the problem you identified?
<peterm6881>
u said you needed to push something
<Xogium>
I forgot to prevent the system from logging on the flash
<peterm6881>
my mistake on the audio
<peterm6881>
forgot DAC needs maxed out too
<Xogium>
ahah
<peterm6881>
not just Headphone
<peterm6881>
sorry
<peterm6881>
how the heck did i forget something so obvious...grr
<peterm6881>
if you're tinkering, is there anything you can do to speed up boot time?
<Xogium>
I'll adjust
<peterm6881>
thanks Xogium
<peterm6881>
by the way it built way faster than the orange pi. Cant JUST be the smaller maps
<Xogium>
no we have a lot less software
<Xogium>
like no network manager
<peterm6881>
speaker-test -c2 -t wav works beautifully
<peterm6881>
is your speaker still connected?
<Xogium>
yes
<Xogium>
well, then
<peterm6881>
can I just say, you totally nailed this Xogium . Congratulations
<Xogium>
as soon as I push the stuff you can do your build again
<peterm6881>
and its a super board. Im excited
<Xogium>
do we get gps fix ?
<Xogium>
what about chrony, what does chronc sources says
<peterm6881>
yes, i did confirm that, you must have been busy :)
<peterm6881>
let me check
<Xogium>
er chronyc sources
<peterm6881>
sources GPS0
<peterm6881>
but it hasnt synced...
<peterm6881>
dunno why
<peterm6881>
whats the force command, can you remember
<Xogium>
hmm
<peterm6881>
chronyc -a makestep
<Xogium>
but does it gives you only ? signs ?
<peterm6881>
no its fine
<Xogium>
ah
<Xogium>
did it work ?
<peterm6881>
chronyc -a makestep worked. Just dunno at what point the stupid thing is meant to synchronise by itself
<peterm6881>
i read somehwere about it taking 10 minutes. I think that was even longer
<Xogium>
yeah it depends how much of a leap we have to make
<peterm6881>
we may need build in chronyc -a makestep
<peterm6881>
plus i think we'll need your simulated rtc as well
<peterm6881>
since we cant guarantee a fix , and it will lose time immediately its disconnected
<Xogium>
I'd really rather have a rtc for this, honestly
<peterm6881>
but im delighted Xogium , cant believe the progress
<peterm6881>
the problem with an add on board is cost, complexity of build, and the need to have batteries
<peterm6881>
the great thing about the new gnss modules is they use a capacitor, so we can declare the device battery free for shipping
<Xogium>
we don't need to ship the battery
<peterm6881>
but i do appreciate the need for fairly accurate time. its annoying gps time is still not the magic bullet
<Xogium>
what's the big deal with telling people to put a cr1225 or whatever in the back of the device
<peterm6881>
lol maybe
<peterm6881>
version stamp displayed UNKNOWN
<peterm6881>
i didnt even know that was handled, nice
<peterm6881>
so, while you're tweaking
<Xogium>
its navit trying to do that but not finding the release version
<peterm6881>
can we fix that?
<peterm6881>
its easily loud enough, love it
<peterm6881>
this board rocks
<Xogium>
er yeah let me reproduce what we did on speedsaver
<peterm6881>
can i ask for one more minor change at this stage
<peterm6881>
instead of this:
<peterm6881>
Welcome to Widora MangoPi R3
<peterm6881>
mangopi-r3 login:
<peterm6881>
can we have Welcome to Speedsaver
<peterm6881>
Speedsaver login:
<Speedsaver>
peterm6881: Error: "login:" is not a valid command.
<peterm6881>
Speedsaver login
<Speedsaver>
peterm6881: Error: "login" is not a valid command.
<peterm6881>
"Speedsaver login:"
<Xogium>
ok should have changed login and stuff, and displayed version stamp
<Xogium>
will just do a build then push it
<peterm6881>
great
<peterm6881>
orange pi build checks out fine by the way. we can go ahead and make that a release
<peterm6881>
audio, gps, all tested good
<Xogium>
is it worth maintaining it now that mangopi is working ?
<peterm6881>
yes i would say so, its not much work, its kinda fun, and it gives us a backup platform, agreed?
<peterm6881>
i think it would be kinda reassuring to keep both. I think that looks impressive to an outsider looking in. It would be a shame to just drop it
<Xogium>
dunno if its worth it
<Xogium>
but its fine if you want to keep it
<peterm6881>
it is, it gives us options to use the H2+ or H3, even for alternative use cases. We dont know what this thing is gonna become
<peterm6881>
Im happy to keep a watch for new BR lts and test them, after that its just a kernel update.
<peterm6881>
let me put it this way Xogium
<peterm6881>
you know how the biggest pain in open source is badly maintained, obsolete and out of date stuff?
<peterm6881>
we both came through a world of pain, for like what, 2 years or more? to achieve that level of maturity and support
<peterm6881>
and with Pierre, since 2016 when I first introduced the Orange Pi Zero to the project
<peterm6881>
Id like to keep it ticking over, if thats ok. We dont have anything to lose by doing that
<peterm6881>
remember its badass spec, quad core, 512 MB RAM
<peterm6881>
we might want that defconfig for other offshoot projects
<Xogium>
$18 per board is too pricy for us I'd say
<peterm6881>
yeah for speedsaver
<Xogium>
well its all for speedsaver in that repo
<peterm6881>
for speedsaver, too expensive. As a development platform, in a cute box with speaker, amplifier , display and GPS, its not
<Xogium>
yes but the whole repo is specific to speedsaver
<peterm6881>
i know, but as I said, we dont know what this will become. We could fork the OPi0 into something general purpose
<Xogium>
but we'd still build the device
<peterm6881>
id enjoy keeping that repo in reserve
<peterm6881>
ok let me pull your changes
<peterm6881>
can i check, did sc6502's fix work?
<Xogium>
yep it did
<peterm6881>
niceness
<peterm6881>
go relax!
<peterm6881>
you've been outstanding today
<peterm6881>
if you hadnt got the bot working who knows when id have spotted he made a commit
<peterm6881>
i love that
<peterm6881>
we're going great guns Xogium
<peterm6881>
i think your readme pretty much covers it, since the note tells you what to do if the nand isnt blank. Its up to you if you wanna put that first though
<peterm6881>
since i think it only goes automatically into FEL mode AFTER you've formatted the nand
<Xogium>
I see
<peterm6881>
try it with your other board
<Xogium>
yeah will do
<Xogium>
but you can reflash your board even if the nand has been written to of course
<peterm6881>
yeah true. let me think about it some more. leave it as it is
<Xogium>
but we need to have rauc working before we ever launch with the mangopi
<peterm6881>
as long as we have a strategy, it doesnt have to be finished
<Xogium>
it does though, people won't understand how to flash their board in windows
<peterm6881>
itll be 6 months before anybody needs it
<Xogium>
and they cannot use rauc to update if rauc isn't already working on the image that has been flashed in their nand
<peterm6881>
since HERE dont apply map updates in anything less than 6 months
<Xogium>
it doesn't matter
<Xogium>
what I'm saying is if we launch and we provide images without any working rauc, they won't be able to update to get rauc
<peterm6881>
cant they just do what im doing to install the firmware?
<Xogium>
on linux yes
<Xogium>
no fucking clue about windows
<Xogium>
or even mac
<Xogium>
not to mention we need a special fork of sunxi-tools, forgot about that one
<peterm6881>
i seem to have managed to corrupt that first board, trying to get the new firmware into it
<Xogium>
hmm did you ?
<Xogium>
how so ?
<Xogium>
did you forget to erase the nand ?
<peterm6881>
no thats the problem, somehow it got erased, so it boots straight into fel mode, but when i run the first command it says ERROR: Allwinner USB FEL device not found!
<Xogium>
er… what
<peterm6881>
and no combination of button presses can get past it
<Xogium>
are you sure its reall in FEL mode
<peterm6881>
yeah i have no idea what happened. It LOOKED like the firmware loaded
<peterm6881>
i get the prompt in PuTTY
<Xogium>
so you put it in FEL mode, ran sunxi-fel again, it said no device found ?
<Xogium>
or like how did you erase the nand exactly
<peterm6881>
at the minute it puts itself into fel mode, but even when i press the buttons i get the same error
<Xogium>
stupid question, you have both usb cable connected ?
<peterm6881>
yeah , gonna reboot pc
<Xogium>
yeah its like
peterm6881 has quit [Remote host closed the connection]
<Xogium>
you shouldn't be able to even break FEL mode
peterm6881 has joined #Speedsaver
<peterm6881>
no rather sadly, under no circumstances will this see an Allwinner FEL device
<peterm6881>
im a little shocked it can be killed
<Xogium>
what do you see on the serial port when you press reset, nothing ?
<peterm6881>
yes fel boots
<peterm6881>
im downloading to a new device
<Xogium>
what do you mean fel boots
<Xogium>
like, if you just press reset and don't try to boot in fel mode, what do you see, nothing ?
<peterm6881>
i mean it spits out boot messages, then get to a fel command prompt
<peterm6881>
ok good news
<Xogium>
can you show me some of these messages ?
<peterm6881>
2nd device works ok with the latest image
<peterm6881>
so the changes didnt break it, and its nothing im doing, or cables
<peterm6881>
alsamixer settings are correct
<peterm6881>
interestingly, the version stamp says V on BR 2022.02
<peterm6881>
no actual version information
<Xogium>
yes that's because I didn't make a release
<peterm6881>
lol fair enough
<Xogium>
I'd still like to debug the first board you got
<peterm6881>
ok what do you wanna try
<peterm6881>
nope we're ok, its recovered
<peterm6881>
u-boot installed ok, now downloading the firmware again
<peterm6881>
i did something wrong before, but i dont know what. Its a tricky process
sc6502 has quit [*.net *.split]
<peterm6881>
hmm. spoke too soon. Something not right with this board
<peterm6881>
ive erased the nand, ill try again
sc6502 has joined #Speedsaver
<peterm6881>
sorted
<peterm6881>
its working now
<Xogium>
yeah I would be impressed if you fucked up the FEL mode itself
<peterm6881>
i might need to work out how we can burn these chips en masse
<peterm6881>
lol it would go into fel mode, according to PuTTY
<peterm6881>
but the terminal begged to differ
<Xogium>
doulbt it somehow
<peterm6881>
well, i got a fel prompt, and I could erase the nand
<peterm6881>
so what would you call it?
<Xogium>
with mtd erase spi-nand0… etc ?
<peterm6881>
yes
<peterm6881>
thats what fixed it
<Xogium>
sounds like a weird u-boot
<peterm6881>
=> this prompt, in PuTTY
<Xogium>
yes that's u-boot
<peterm6881>
oh
<peterm6881>
yeah im confused, sue me
<Xogium>
FEL mode is actually totally silent on serial
<peterm6881>
got it
<peterm6881>
my mistake
<Xogium>
it stops being silent when you run sunxi-fel
<peterm6881>
anyway its recovered, phew
<peterm6881>
yeah for production, we will definitely be cooking this in bulk
<peterm6881>
these
<peterm6881>
its been a fabulous day, thanks to you
<peterm6881>
you did it
<peterm6881>
slower boot time is a bit of a backwards step, however it does give the GNSS more time to get a fix
<peterm6881>
time to go driving
<peterm6881>
there are a few boot error messages, some of those might be part of the problem, one in particular
<peterm6881>
it seems to take quite a while at this, right before it runs the code
<Xogium>
nah it does other things, its just that they are quiet
<peterm6881>
by the way, remind me what we use systemd for
<Xogium>
though yeah I will have to do some cleanups because we don't need these 2 things
<Xogium>
what do you mean
<peterm6881>
remember you said you added it, whats its purpose?
<peterm6881>
im just curious
<peterm6881>
i know you told me before
<peterm6881>
is it essential?
<Xogium>
it is our init system
<Xogium>
handles supervision of services as well as boot up procedure, so like if navit crashes it restarts, that kind of stuff
<Xogium>
busybox is just a very very much more basic design
<Xogium>
it only handles init. Handles boot up, starts the shell scripts it finds in /etc/init.d, and then its done. It stays active to provide you with a shell and keep the system running but, that's about it. It doesn't supervise processes. So if one of them crashes, well too bad
<peterm6881>
controversiaol question, but could we try busybox?
<peterm6881>
controversial
<Xogium>
see what I just wrote above
<peterm6881>
yes i know, but we never tried it with busybox
<Xogium>
we did
<Xogium>
not all of our things but
<peterm6881>
id be curious to know if that slowing down the boot time
<Xogium>
the buildroot-mangopi-r3c repo uses busybox
<peterm6881>
thats
<peterm6881>
its just a thought. its about 50 seconds before you get a display
<Xogium>
but it will be very limited, if navit crashes there'd not way to know about let alone restart it, don't even think about dependency handling (make service a require service b)
<peterm6881>
do you know what it is for the orange pi?
<Xogium>
about 10 seconds, if I remember
<peterm6881>
11 seconds
<peterm6881>
yeah....
<Xogium>
well… yes
<peterm6881>
i should point out, we've never restarted navit
<peterm6881>
just playing devils advocate here
<peterm6881>
what was that alternative to busybox you found, that you like
<Xogium>
as I said, 15 seconds of that are the dfu timeout period, then you have u-boot making sure the ubi volume/fs isn't corrupted and is sanely working, which takes about 3 seconds or so, then loading our kernel from the nand takes about 5 seconds because its not fast
<Xogium>
that all adds up
<peterm6881>
what was that alternative to busybox that you liked
<Xogium>
raw nand is slower than micro sd and eMMC and all that because they use spi
<Xogium>
I don't even think the f1c200s has quad-spi support, which means its only 1 byte per transfer
<peterm6881>
we might have an opportunity to go eMMC, depending on what Arslan says
<peterm6881>
although i presume its more expensive...
<Xogium>
definitely
<Xogium>
tradeoffs with raw flash vs handled flash like eMMC are like this
<Xogium>
raw flash costs less, but is far more complex to deal with (needs 3 layers of softwares to be handled properly, requires to know exactly the data of your chip so your produced image is right, that sort of thing)
<Xogium>
eMMC and friends cost more but reduce complexity to almost nothing, because they show up loke regular disks
<Xogium>
er like
<peterm6881>
ill discuss flash options with Arslan if hes prepared to take on the project
<Xogium>
but in a way then I'm greatly annoyed I even bothered making this work
<peterm6881>
so if you had to choose, you'd prefer eMMC right?
<Xogium>
well. I know how to handle both now. No big deal anymore
<Xogium>
but if you feel this is too slow, alright then
<peterm6881>
no its fine Xogium, im just thinking out loud about possible options to improve boot time. Its early days. We have a working prototype, thats all that matters just now
<Xogium>
meh sounds like its not so good
<Xogium>
what use is the device if it takes 50 seconds to display anything
<Xogium>
you'd be on the road for the past 50 seconds
<Xogium>
I didn't find any alternative to busybox, by the way
<peterm6881>
lol well its 50 seconds versus 10 seconds
<Xogium>
still 40 seconds too long
<peterm6881>
i thought you did..
<Xogium>
no
<peterm6881>
dunno what i was thinking of
<peterm6881>
do you think theres a way to disable the dfu timeout?
<Xogium>
but like even loading our 2.7 mb kernel takes a few seconds so it isn't like I could pull off miracles
<Xogium>
yes there is a way
<Xogium>
but that will mean no dfu at all
<peterm6881>
its not a criticism of you, or the board, its just an interesting new dimension to think about , that id never had to think about before, because we were spoilt
<peterm6881>
hmm......
<peterm6881>
we cant do without dfu surely
<Xogium>
if our chip handled quad-spi then we could wire up the spinand in qspi mode but as it is, its not even dual-spi
<peterm6881>
i mean, customers cant change the nand chip!
<Xogium>
and customers shouldn't have to deal with dfu
<Xogium>
dfu is useful but only at the factory when programming the devices
<peterm6881>
ok anyway we're in a good place
<Xogium>
the end user should only have to updat via rauc bundles
<Xogium>
that's the idea
<Xogium>
I can't provide windows or mac instructions for handling FEL or dfu let alone softwares for doing so, which is exactly the reason I want to get rauc going asap
<peterm6881>
the process in MangoPi's wiki would work
<peterm6881>
for Windows anyway. Dont care about mac
<peterm6881>
sorry i meant DFRobots wiki
<peterm6881>
we just point it at our firmware instead of theirs
<peterm6881>
in fact, I might test that
<Xogium>
but we don't have the same infrastructure
<Xogium>
besides who's to say their software will be available from the wiki forever ?
<peterm6881>
lol ok ok , just dont lose any sleep over rauc
<Xogium>
oh I don't need that to lose sleep
<peterm6881>
you have a copy of their SPI_firmwareV0.2 handy?
<peterm6881>
you can see the structure
<peterm6881>
shouldnt be hard to adapt it to our firmware
<peterm6881>
but the windows process is a ballix, all that installing the drivers with a hwole other app bullshit. Fuck that
<peterm6881>
whole
<peterm6881>
but its doable
<peterm6881>
maybe sc6502 could write a custom update app for Windows. Meh, we'll figure something out
<peterm6881>
its really the maps dont forget
<peterm6881>
in fact, we should probably actively discourage users from updating the OS unless its a bug fix
<peterm6881>
otherwise we'll be tortured with idiots bricking their Speedsavers for zero reason
<peterm6881>
dont forget to close that i2c write error issue some time you're not busy
<peterm6881>
peace
<peterm6881>
orange directory 45.6 GB, mango 39.7 GB, not that different
<peterm6881>
why do they end up so huge
<peterm6881>
good news is at the time of writing , its still 2022.02 ;)
<peterm6881>
flashing the 4th one now, actualy the flashing process in linux is really straightforward
<peterm6881>
terrific job on the readme
<Xogium>
I don't understand why your folder gets so big, mine is 5.6 gb for mangopi
<peterm6881>
really?
<peterm6881>
that is bizarre
<peterm6881>
talk to me about the kernel, we're stuck with 5.4.99 right?
<Xogium>
yes
<peterm6881>
forever i take it
<Xogium>
and stuck with u-boot 2020.07
<peterm6881>
its an ARMv5 thing
<Xogium>
well yes and no. Depends whenever it gets mainlined
<peterm6881>
who do i need to seduce about that?
<peterm6881>
:)
<Xogium>
didn't know you were toward men
<Xogium>
hehe
<peterm6881>
i mean, how do these things get decided anbd by whom
<peterm6881>
and
<peterm6881>
metaphorically speaking Xogium ;)
<Xogium>
honestly, for allwinner its on a community effort. If someone feels like mainling the chip in their free time they might do it
<Xogium>
because allwinner is unlike st and doesn't bother upstreaming anything
<peterm6881>
tell me this, in your experience, can you name individuals who would be best placed to do that?
<Xogium>
I've honestly got no idea
<peterm6881>
Linus Torvalds?
<peterm6881>
;)
<Xogium>
doubt it… He actually develops less and less on kernel these days
<peterm6881>
have you ever had any contact with any dev whos done any mainlining?
<Xogium>
hmm
<Xogium>
I can't remember if I ever did
<peterm6881>
who would even know wtf we were talking about
<peterm6881>
its not essential, but it would be useful for me to build support for this chip
<peterm6881>
I'd enjoy that
<peterm6881>
ill check out sunxi
<peterm6881>
see what the normal channels are for this kinda thing
<peterm6881>
is the v3s mainlined?
<peterm6881>
or the H2+, or the H3?
<peterm6881>
anyway ill shut up now
<peterm6881>
give you peace, you certainly should chill for a while
<peterm6881>
we've reached a new plateau, a sunny upland
<peterm6881>
outstanding work Xogium
<Xogium>
yes h2-plus and h3 are both mainlined, v3s is struggling along
<Xogium>
we use mainline kerel on orange pi, remember ;)
<Xogium>
kernel
<peterm6881>
i wonder if we can find out whos working on the v3s
<peterm6881>
@AOSC-Dev Member. Linux-sunxi developer focused on sunxi mainlining. Might be a magical girl ;-) WARNING: currently in low-productivity mode.
<peterm6881>
she's not a hobbyist, shes a kickass dev from the home of Allwinner
<peterm6881>
i need to reach out to this person, agreed?
<Xogium>
dunno, you saw the warning
<peterm6881>
yeah i think i saw that the last time too, when i was in touch with George Hilliard. But look at her GH activity
<peterm6881>
contributions on the 6th, 7th and 8th of March
<peterm6881>
2022
<peterm6881>
nothing since, should we be worried?
<peterm6881>
;)
<peterm6881>
icenowy@aosc.io
<peterm6881>
icenowy zheng
<peterm6881>
ill email her a link to our organisation, see if she fancies revisiting the F1C100s / F1C200s
<peterm6881>
mainlining is her speciality
<peterm6881>
i think that would be very cool.........
<peterm6881>
i'll let you know how road testing goes.
<Xogium>
woah the GOTTA_GO_FAST is fucking LOUD
<peterm6881>
haha
<peterm6881>
yeah is a decent amp on that board
<Xogium>
seven hells yes
<peterm6881>
PAM8301, from Diodes Incorporated, it gives a nice healthy output
<peterm6881>
its a great board
<peterm6881>
i think that onboard audio amplifier is a very rare feature, I dont know any other dev board that has it
<Xogium>
yeah but notice how navit even is slightly slow to startup. Takes it a good 3 seconds to start up and notice you're speeding
<Xogium>
so yeah spinand means it is also slow. That plays a role in how slow it is to boot up but we have ddr1 ram and a most probably clocked up to 400 mhz single core cpu
<peterm6881>
yeah ill check that now, i didnt really notice GOTTA_GO_FAST performing any differently than it does on the OPi0
<Xogium>
so of course it won't be as badass as the opi
<peterm6881>
back soon, stay tuned
<peterm6881>
hey Xogium
<peterm6881>
are you there?
<peterm6881>
ok I have the definitive results of side by side comparison testing between the OPi0 and the MPi-R3c
<peterm6881>
aside from boot time, no difference in performance. Identical
<peterm6881>
so all in all, probably the best day of the project since the start