ftg has quit [Read error: Connection reset by peer]
juri__ has joined #linux-sunxi
juri_ has quit [Ping timeout: 480 seconds]
colinsane has quit []
colinsane has joined #linux-sunxi
linkmauve has left #linux-sunxi [Error from remote client]
apritzel has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-sunxi
KREYREN_ has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
diego71 has quit [Ping timeout: 480 seconds]
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #linux-sunxi
KREYREN__ has joined #linux-sunxi
vagrantc has joined #linux-sunxi
KREYREN_ has quit [Remote host closed the connection]
KREYREN__ has quit [Remote host closed the connection]
KREYREN__ has joined #linux-sunxi
KREYREN__ has quit [Remote host closed the connection]
NekoMay has quit [Ping timeout: 480 seconds]
NekoMay has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
tlwoerner__ has quit [Remote host closed the connection]
tlwoerner__ has joined #linux-sunxi
kuba2k2 has joined #linux-sunxi
kuba2k2 has quit [Ping timeout: 480 seconds]
diego71 has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
gsz has joined #linux-sunxi
colinsane has quit [Ping timeout: 480 seconds]
colinsane has joined #linux-sunxi
tnovotny has joined #linux-sunxi
warpme has joined #linux-sunxi
warpme has quit []
tnovotny has quit [Quit: Leaving]
warpme has joined #linux-sunxi
warpme has quit []
bauen1 has quit [Ping timeout: 480 seconds]
linkmauve has joined #linux-sunxi
apritzel has joined #linux-sunxi
kuba2k2 has joined #linux-sunxi
dsimic is now known as Guest10078
dsimic has joined #linux-sunxi
Guest10078 has quit [Ping timeout: 480 seconds]
kuba2k2 has quit [Read error: Connection reset by peer]
kuba2k2 has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
kuba2k2 has quit [Read error: Connection reset by peer]
kuba2k2 has joined #linux-sunxi
bauen1 has joined #linux-sunxi
evgeny_boger has quit [Quit: evgeny_boger]
norton has joined #linux-sunxi
Daanct12 has quit [Quit: WeeChat 4.1.2]
mripard has joined #linux-sunxi
warpme has joined #linux-sunxi
JohnDoe_71Rus has quit []
gsz has joined #linux-sunxi
kuba2k2 has quit [Ping timeout: 480 seconds]
evgeny_boger has joined #linux-sunxi
hallyn has joined #linux-sunxi
apritzel has quit [Remote host closed the connection]
JohnDoe_71Rus has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
Jookia: sorry for the terse and direct tone on my Github comments, but there is just so much in your mail/repo that we need to move stuff out of the way, to get to the core (which is SPL SPI NAND, really)
kuba2k2 has joined #linux-sunxi
kuba2k3 has joined #linux-sunxi
kuba2k2 has quit [Ping timeout: 480 seconds]
evgeny_boger has quit [Ping timeout: 480 seconds]
bauen1 has quit [Ping timeout: 480 seconds]
gsz has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
kuba2k3 has quit [Ping timeout: 480 seconds]
warpme has quit []
vagrantc has quit [Quit: leaving]
apritzel has quit [Ping timeout: 480 seconds]
evgeny_boger has joined #linux-sunxi
colinsane has quit []
colinsane has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
colinsane has quit []
colinsane has joined #linux-sunxi
gsz has joined #linux-sunxi
juri__ has quit [Remote host closed the connection]
juri_ has joined #linux-sunxi
JohnDoe_71Rus has quit []
juri__ has joined #linux-sunxi
juri_ has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
vagrantc has joined #linux-sunxi
cakes has joined #linux-sunxi
cakes_ has quit [Ping timeout: 480 seconds]
macromorgan has quit [Quit: Leaving]
warpme has quit []
<Jookia>
apritzel: Hi there! Thanks for the comments. I appreciate your feedback and it's all very good stuff. I think I should have been a bit more clear: jookia_t113 branch is not intended for merging but is intended to work on my hardware for my purposes. So direct device tree modification and config changes need to get out of this tree and to Buildroot anyway.
<Jookia>
Or are DT overlays kind of the correct way to go instead of overwriting the entire dts in a build system?
<Jookia>
But I am interested in the 'u-boot should pick one console': So is it not intended that people select a console for their specific board/use case?
<Jookia>
UART1 is used by GPIO for one of our boards
<Jookia>
I guess we could just not use that GPIO :)
<Jookia>
For the MQ UART1 is the recommended UART so the UART2 patch is not needed
<apritzel>
Jookia: yes, I understood that this branch is WIP, but that's what up there and I needed somewhere to comment
<apritzel>
as mentioned it's a lot of different stuff that you put up
<apritzel>
and it's kinda hard to address this all in one email reply
<apritzel>
(believe me, I tried)
<apritzel>
that's where the upstream review process shines: small patches, sent inline, so that commenting on the exact spot is easy
<apritzel>
regarding config: one thing to note that the upstream U-Boot *def*config is a template and well, a default, for normal users
<apritzel>
so anyone who has this board, can just get started with the defconfig and gets reasonable results
<apritzel>
as the name defconfig already states: you are free to deviate from that, either by manually overriding this (try scripts/config)
<apritzel>
or by having your own defconfig, for your particular deployment
<Jookia>
This makes sense
<apritzel>
so the MQ schematic mentions UART3 as the console, routed to a header
<apritzel>
however I couldn't spot such a thing on the photos
<apritzel>
so is this some schematic copy&paste hiccup, or did they mix up header with test points?
<Jookia>
Near the LCD connector there are two unpopulated pins labeled 'T' and 'R'- UART1 is ALSO labeled 'R' and 'T' on P3
<apritzel>
oh, I see now
<apritzel>
yeah, that's "great" then
<Jookia>
awboot uses uart1 I believe
<Jookia>
So that's the official UART
<Jookia>
UART2 is next to pins 7 and 8 on P2, but uses a different gpio port to existing UART code and requires that patch
<apritzel>
I don't think the UART2 pinmux selection in U-Boot was put there with a real purpose
<apritzel>
so I'd rather have it you change that instead of #ifdef it
<Jookia>
Change that through a patch or some kind of Kconfig option?
<apritzel>
patch
<Jookia>
Ah ok
<apritzel>
Kconfig is better than hardcoding, but still inferior to "no config needed at all"
<Jookia>
Isn't requiring a third party patch a type of config?
<Jookia>
Or did I misunderstand what you mean
<apritzel>
I mean you should send a patch to change it in mainline
<Jookia>
Ah okay. But how would that work for only this board? Some other UARTs don't use this port
<apritzel>
I don't really remember why we put a value for uart2 there in the frist place, I don't see it really used in any of the mainline DTs
<apritzel>
so it's irrelevant at this point, and changing that should not make a different for existing (mainline) users
<apritzel>
requiring non-conflicting pinmux values is admittedly a shortcoming of U-Boot's sunxi pinctrl implementation
<apritzel>
but one that simplifies the implementation quite a bit
<Jookia>
Oh, you mean for CONFIG_MACH_SUN8I_R528 I should just switch UART2 to port E and send that as a patch?
<Jookia>
(When I do the MQ stuff)
<apritzel>
yes, but foremost change the line in pinctrl-sunxi.c
<Jookia>
Gotcha
<apritzel>
which atm says "7" for PB0-PB1, to say 3 for PE2/3(?)
<Jookia>
yes that makes sense
<Jookia>
I believe it is PE2 and PE3
<apritzel>
another reminder for us to not add pinmux values which are not really in use
<apritzel>
so you should be able to add the bits that allow to select UART1 and UART2 as a console, but in a way that doesn't break the existing setup
<Jookia>
Okay, that's good
<apritzel>
and then just set CONS_INDEX in your downstream config
<Jookia>
I already have a downstream config so that should be easy :)
<apritzel>
boy, both the MangoPi MQ and MQ-R are already discontinued, in both the RISC-V and ARM configs
<apritzel>
does anybody know what this ArtinChip SoC is?
ftg has joined #linux-sunxi
<Jookia>
The MQ-Dual is still bieng sold on aliexpress. Old stock maybe
<Jookia>
ArtinChip? A new RISC-V SoC?
<apritzel>
yeah, that seems hard to tell from this side of the Great Firewall, apparently
macromorgan has joined #linux-sunxi
<apritzel>
yeah, there is one block diagram which says RISC-V, but the peripheral names hint don't match what AW typically uses
<apritzel>
so it might be a different chip, not a relabel
<Jookia>
linux-sunxi wiki says the t113-s4 is known as the artinchip aic600e3 and uses the same die
<Jookia>
But that would be an ARM core
<apritzel>
ah, I knew I heard the name before ..
<Jookia>
I also do plan to write up some notes for SPI NAND in linux-sunxi wiki but I kind of want to read the room on what the direction is in mainline u-boot before I start giving people directions to do X or Y
<apritzel>
well, don't hold your breath on getting a good answer anytime soon
<Jookia>
Haha okay :)
<apritzel>
for a start your email is rather long, and I guess the subject might steer away some people, because it sounds sunxi specific
<apritzel>
where the actual question is how to handle SPI NAND in the SPL. What's the platform and host controller, is then an implementation detail
<Jookia>
Oh I see
<apritzel>
I mean your argument of "you probs have UBI for Linux anyway" is a good one, but I am not entirely sure pulling in all of the UBI source in the SPL is really worth it
<Jookia>
That makes sense yes
<apritzel>
I haven't looked at how complete the UBI SPL implementation is, if for instance we can short-cut things if we just need read operations
<apritzel>
I mean from reading this up in the last 10 mins ;-) it looks like we need just need to scan the header of each UBI block to find the logical block number we are looking for
<apritzel>
which could be optimised like: while searching for the first logical block number, already collect and cache all mappings we will need later and find on the way
<Jookia>
I think it does that already
<apritzel>
yeah, I guess that's obvious ;-)
<apritzel>
but I guess it also contains code to handle all the UBI volume information?
<Jookia>
I think so yes
<apritzel>
I wonder if this could be cut by just putting the logical start block number in Kconfig
<apritzel>
which would map to what we do for instance for MMC
<Jookia>
I think it has an offset to the UBI volume in kconfig, unless you mean something else
<apritzel>
you mentioned a "U-Boot partition", and describe this in the DT
<apritzel>
so is this also information that's stored on the flash
<apritzel>
so to summarise I wonder if we can use UBI, but with somewhat open coding just the bits we need, which is to find logical block numbers
<apritzel>
I mean it would be just like: read the first 8 byte of each block, check for the "UBI#" magic and use the logical block number right after it?
<Jookia>
I'm not sure, I don't know enough about UBI. I'm under the impression the ubispl code is already pretty stripped down
<apritzel>
one would hope so, but you mentioned it requires DM?
<Jookia>
No I don't think so
<Jookia>
It requires the MTD subsystem
<Jookia>
For some code
<apritzel>
I see, then I seem to run of excuses for looking at this in more depth ;-)
<Jookia>
I do have DM_MTD enabled in my config but I'm not sure why
<apritzel>
for the SPL as well?
vagrantc has quit [Quit: leaving]
<Jookia>
Oh, no
<Jookia>
No DM in SPL
<apritzel>
good!
<apritzel>
I remember you mentioned that a while ago, so ...
<Jookia>
Yeah, I spent a while trying to get DM working in SPL for some reason. I don't remember why
<Jookia>
Is it a bad idea to have it enabled in SPL?
norton has quit [Ping timeout: 480 seconds]
<apritzel>
it's a long story... for a start it increases the image size by quite a bit, which is a deal breaker for older SoCs
<apritzel>
so at best we would have to maintain both: non-DM SPL and DM SPL
<apritzel>
also I believe it doesn't give us too much, as a good part of the SPL deals with clock setup and DRAM control, which are not really described in the DT (one of the main reasons to have DM_SPL)
<Jookia>
One reason I looked at SPL DM was some vague hope I could define pinmuxing in the DT, which sadly isn't the case
<apritzel>
another point: the pinmuxing isn't really in the DT, it's in those tables in the code, the DT just contains *strings* (personally I consider this stupid, and am on a mission to change this)