<apritzel>
duclare: I will have a think. Probably busy this and next week with the bigger SoCs, but we should definitely brainstorm this at some point
<duclare>
Ok. Problem is I don't know if I know enough about things to give any kind of useful feedback
<norton>
wait i forgot
<duclare>
apritzel: Btw does pine64 use A/B partitioning or somesuch mechanism?
<duclare>
I'm quite used to bundling kernel and DT in fit on systems where bootloader is something we don't touch after it's installed and works
<norton>
nevermind
<norton>
u-boot doesn't react to `press key to stop auto-boot` and boots from sata ssd
<norton>
what do?
<duclare>
If there is hardware support for A/B, then I guess uboot could be updated too and then fdtcontroladdr would make more sense (though it still feels risky)
<duclare>
norton: I don't know what input devices it supports or how. Serial console should be basically always supported and that is what I always use for development.
<duclare>
I have never tested usb keyboard in uboot. That would require a bunch of things to be right: configuration, drivers, DT..
<apritzel>
USB keyboard works fine on the boards I tested
<apritzel>
duclare: mmh, interesting, I see your point, but why would you want to update the DTB for an A20 board anyway?
<apritzel>
and I don't think there is anything like hardware support for A/B booting, but the SPL could potentially select one of multiple configurations (U-Boot+DTB) from the FIT image
<duclare>
Let's say I plug in a piece of hardware to one of the exposed i2c or spi pins? Or need different configuration for some peripheral?
<duclare>
Or maybe I need to pass new options to a new/updated kernel driver
<apritzel>
but that would be handled by overlays, loaded and applied at boot time by U-Boot?
<apritzel>
kernel options? that goes via the bootargs env variable?
<duclare>
No, driver options
<duclare>
Let's say rs485-enabled-at-boot
<duclare>
or whatever
<duclare>
Overlays may work but now I need to update u-boot with the logic to figure out which dtbs to apply, right?
<duclare>
I really hate pushing complexity into the bootloader
<duclare>
All this becomes a non-issue for me if I just bundle kernel + dtb
<apritzel>
I have a patch that goes through a directory and applies every .dtbo file it finds
<apritzel>
which means you just "cp" (or even symlink) the .dtbo you want into a fixed directory
<apritzel>
duclare: I sense we have quite a different approach how to deal with DTBs ;-)
<duclare>
So what's the likelihood that one day one dtbo too much triggers a bug in u-boot and suddenly renders the whole system unbootable?
<duclare>
Also juggling these files sounds like another layer of complexity. Plus to understand the whole set-up, I'll need to look at the base dt that was compiled in uboot N years ago plus a pile of ovelays
<apritzel>
then you break into the U-Boot prompt and boot the failsafe option?
<duclare>
Yeaa... nah ;)
<duclare>
I'm talking from the perspective of someone who has to support thousands of headless systems out in the field, locked in racks somewhere. Any kind of requirement for physical access to recover is expensive
<duclare>
And in practice means hw gets sent to factory
<apritzel>
honestly I found your approach intricated, the main problem is that it bundles the DTB and the kernel, which is conceptually wrong. The DTB should be provided by firmware
<apritzel>
but I think we come from very different worlds
<duclare>
I think that ship sailed
<duclare>
DTB evolves all the time
<duclare>
Yes, the ideal was that it is written once and set in stone
<duclare>
The reality is that .. as we update kernels, as we find bugs or features in hardware, etc., things need to change
norton has quit [Ping timeout: 480 seconds]
<apritzel>
not necessarily, it can improve, and if you need the improved version, you update your firmware. If not, you just leave it
<apritzel>
I am not so much into this fiddly embedded world, but more interested in distro boots and single image kernels and such
<duclare>
As far as I'm concerned, kernel *is* firmware as much as the bootloader is. The only question is how to eliminate moving parts and make updates as rock solid as possible
<apritzel>
yeah, that's a fundamentally different understanding
<duclare>
.. and avoid updating things that we cannot recover without expense if it goes wrong
<duclare>
:/
<duclare>
So yea it's a bit different from a system that is treated like a normal computer
<apritzel>
the kernel is provided by the distro, and both don't care about what board or DTB they are using, that's the job of the firmware
<duclare>
Ye. In my case kernel and userland is provided by me, just as the bootloader is.
<apritzel>
but I see how this gets troublesome in those deeply embedded scenarios
<apritzel>
I still would like to treat "embedded" use cases as some special cases of the "normal computer" approach, not as something fundamentally different
<duclare>
Anyway I'm not using olimex for this and I don't think my approach is necessarily the right one
<duclare>
.. but it would be cool & interesting if we had something in general that worked just as well for embedded as everything else
<apritzel>
yes, that's what I aim at
<apritzel>
but I am not sure we can make *everyone* happy with one single approach
<duclare>
Next product might have A/B so we can update bootloaders too.. though, to be frank, I'm still kinda terrified at just how much complexity wants to accumulate in the bootloader.. that's the part where it's difficult to automagically recover if it goes south
<duclare>
Ye
<apritzel>
though I believe those SBCs are now good enough to get more of a grown-up computer treatment
<apritzel>
it's not like we have to squeeze everything into 8MB of RAM or so anymore ;-)
<duclare>
Yea, I just find that all too often "grown-up computer treatment" ignores the hard parts and pretends there's always a sysadmin behind the screen ready to take over if $overcomplicated_system blows up :P
<duclare>
If the process is not rock solid and there are enough devices in the field, murphy's law has it that some will fail
<apritzel>
from my point of view those embedded system are often unbelievably hacked up, mostly because they miss out on peer review, when they don't (need to) go through any upstreaming process
<apritzel>
I myself write a lot of misguided nonsense, but most of this gets caught, corrected and fixed by other community members
<duclare>
Heh speaking of hacked up..
<apritzel>
I still believe we can support both worlds
<duclare>
recently I hacked the kernel on one of our products to treat the rw on kernel's cmdline as ro
<duclare>
:D
<apritzel>
that's what I mean ;-)
<duclare>
Anyway, it's not for lack of peer review.. once again this was motivated by the fact that updating bootloaders in the field is risky
<duclare>
And fixing that is much trickier (if not impossible) than just making the kernel do what we want :P
<apritzel>
what SoCs are you dealing with? Do you actually need DT updates? I think for the A20 ones for instance we didn't see much in a while ...
<duclare>
Yes, we do actually need to update DTs
<apritzel>
anyway, need to get out early tomorrow (and it's late your side as well, I reckon), so have so sign off
<duclare>
yup, good night
<apritzel>
but feel free to keep feeding the logger ;-)
<duclare>
As a recent example, we've needed to change the drive strength on some pins for emc compliance reasons
<duclare>
And slightly less recently.. something serial related. There might have been more than one change in fact
<duclare>
Changes in drivers, changes in software
<duclare>
And I'm finding more stuff like handwritten userspace drivers for some i2c chip, which should be moved to kernel
<duclare>
That will need DT updates
<duclare>
Sometimes you have to change clocks
<duclare>
Hmm, one serial related change was disabling dma on a system where the driver was updated to support it and we subsequently found serial broken
<duclare>
Though I can't remember whether that was a DT change or driver change that worked around it
<duclare>
RS485 related settings might have needed changing too, not sure
<duclare>
Just like in BIOS/UEFI of a modern PC.. there really are lots of knobs and options for good reason, not everything is set in stone
<duclare>
Sometimes you need these for software compatibility, sometimes to work around a hardware problem, sometimes something else, perhaps support for a new expansion board oslt
<duclare>
As another example
<duclare>
Switches have long been net/phy chips with rather bespoke drivers
<duclare>
Now they're being incorporated in the DSA framework
<duclare>
So you may have good reason to switch your switch over to DSA, which again requires DT changes
<duclare>
You can also find boards and socs with an application processor and a microcontroller
<duclare>
These often support changing the way peripherals are assigned
<duclare>
So you might decide to offload some realtime-ish task to the microcontroller for example, handing over a peripheral or a bunch of gpios from soc over to the mcu
apritzel has quit [Ping timeout: 480 seconds]
vagrantc has quit [Quit: leaving]
machinehum1 has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
<ctag>
Is there anything like a github repo with sample files for fel-usb-boot on the opi zero2 / h616?
<ctag>
OK, maybe I'm on track. I got the armbian build script and am running it to try and get a kernel image to use.
machinehum1 has left #linux-sunxi [#linux-sunxi]
machinehum has joined #linux-sunxi
<machinehum>
Has anyone used wifi modules like Rtl8723ds?
<machinehum>
They're commonly paired with allwinner boards
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
Net147 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
bauen1_ has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
<jkm>
machinehum: I use RTL8723DS all the time, just built a kernel module for this :)
NishanthMenon has quit [Write error: connection closed]
palmer has quit [Read error: Connection reset by peer]
palmer has joined #linux-sunxi
NishanthMenon has joined #linux-sunxi
Net147 has quit [Ping timeout: 480 seconds]
electricworry has quit [Quit: Leaving]
warpme has quit []
tnovotny has joined #linux-sunxi
Net147 has joined #linux-sunxi
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #linux-sunxi
JohnDoe_71Rus has quit []
kuba2k2 has quit [Ping timeout: 480 seconds]
<norton>
duclare: i got to the olimage again
<norton>
and I noticed one strange thing
<norton>
u-boot says I have olinuxino lime rev. a
<norton>
that's obviously not true
<norton>
I probably need to reset eeprom of the board
<Jookia>
a lime 1 or lime 2?
<norton>
ID: A20-OLinuXino-LIME Rev.A
<norton>
SN: 00000000
<norton>
MAC: FF:FF:FF:FF:FF:FF
<norton>
what I actually have: A20-OLinuXino-MICRO Rev. G
tnovotny has quit [Ping timeout: 480 seconds]
bauen1_ has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
tnovotny has joined #linux-sunxi
bauen1 has joined #linux-sunxi
warpme has joined #linux-sunxi
vagrantc has joined #linux-sunxi
tnovotny has quit [Quit: Leaving]
<machinehum>
jkm: Nice
<machinehum>
I think I *just* found the proper docs for the module
<machinehum>
Do you use the module or chipscale?
hlauer has quit [Remote host closed the connection]
machinehum1 has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
warpme has quit []
warpme has joined #linux-sunxi
jkm has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
blathijs has quit [Quit: WeeChat 4.0.5]
hexdump01 has quit []
hexdump0815 has joined #linux-sunxi
kuba2k2 has joined #linux-sunxi
warpme has joined #linux-sunxi
<jkm>
Hello friends from PL :D
<gamiee>
Siema
<jkm>
Siemka :D
<jkm>
Anyone going to FOSDEM in February next year?
<gamiee>
Yeah, will be there
<jkm>
Great, me too
<libv>
i'm running another graphics devroom
<libv>
and will probably do video team friday and saturday
blathijs has joined #linux-sunxi
<jkm>
I wonder if Paul will prepare another V4L2 presentation
<jkm>
last year it was great
<jkm>
I mean this year*
<libv>
he will be there, but i do not see a talk in the fosdem scheduling system at this time
JohnDoe_71Rus has quit []
warpme has quit []
kuba2k2 has quit [Ping timeout: 480 seconds]
kuba2k2 has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
I am planning on coming to Brussels as well
<jkm>
great, can't wait to talk to Allwinner guys
<jkm>
I mean sunxi guys
<apritzel>
libv. any recommendations on how to have a sunxi meeting? during the day, outside of some restaurant in town, that is
<libv>
under janson
<libv>
where you can get coffee and things
evgeny_boger has quit [Quit: evgeny_boger]
evgeny_boger has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
<apritzel>
is that this building where you pass through from the food trucks to building K?
<libv>
H building is the 70s brutalist one near the big road
<libv>
attached to that is the big aula called janson
<libv>
janson is between the big road and the parking lot
<libv>
you can get to the cafeteria under janson by either taking the slippery stairs down from the parking lot, or from within the H building, there's a sort of a tunnel at the end of the H building (the furthest away from the info stand in H)
<apritzel>
ah, I see it on the map now
<libv>
this is a semi-circle shape, with big tables
<libv>
so state a time, gather some people, and occupy a table beforehand
<libv>
take a A4/A3 sized sign with sunxi on it
<libv>
as usual, i will likely not make it as i will be doing other things, and i will hopefully get assigned to video in the K building, as i hope that my devroom will be there
<libv>
but if you catch me during the weekend, i usually gather names for a sunday evening dinner at a good restaurant nearby
<libv>
and reserve a table there and have people meet up in the K building and clean up the devrooms there
<libv>
and then head off for food
<apritzel>
Sunday evening dinner will probs be some Carrefour meal deal in the Eurostar for me ;-)
<jkm>
:D
<libv>
always come thursday and leave monday for fosdem
kuba2k2 has quit []
evgeny_boger has quit [Ping timeout: 480 seconds]
machinehum1 has left #linux-sunxi [#linux-sunxi]
machinehum has joined #linux-sunxi
<machinehum>
FOSDEM eh
<machinehum>
I've moving to Switzerland
<apritzel>
so that's basically just downhill from there ;-)