<smaeul>
I wonder if we should try a different approach, or a different timer
<anarsoul>
different timer sounds better
<anarsoul>
there's sun4i-timer in A64
<anarsoul>
why not to use it?
<smaeul>
it's definitely an option. downsides are 1) setting a timer spins for 3x 24MHz cycles, 2) it is not per-cpu
MoeIcenowy has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
MoeIcenowy has joined #linux-sunxi
<apritzel>
the Generic Timer is mandatory in ARMv8, and arm64 Linux relies on it
<apritzel>
smaeul: what does the parallel counter test do, exactly?
warpme___ has quit []
<apritzel>
smaeul: found it, so it just runs in parallel, but each test is independent
<apritzel>
and you filter out what's covered by the workaround?
<anarsoul>
apritzel: OK, any suggestions?
<apritzel>
anarsoul: declare the A64 broken? ;-)
<anarsoul>
OK :)
<apritzel>
we could try a more costly workaround
<apritzel>
didn't the Freescale workaround work as well?
<smaeul>
apritzel: yes, each test is independent and bound to a specific CPU
<smaeul>
the filtering in the tool is not relevant because the workaround is enabled, so the kernel is already filtering (and is stricter)
<anarsoul>
I really wonder why allwinner needed to make changes to generic timer :\
<smaeul>
the "read twice and compare" strategy works as long as you provide a large enough tolerance for when the CPU itself is running at 24 MHz
<apritzel>
anarsoul: they didn't, but they messed up the connection between the Generic Timer clocksource (which must be provided by the SoC vendor) and the Cortex counter block
<apritzel>
anarsoul: maybe an issue with not atomically promoting the required 64-bit value?
<anarsoul>
but how did it pass quality control?
<smaeul>
I was/am concerned about getting two consecutive bad reads, but we may be able to prove that the timing prevents that from happening
<smaeul>
anarsoul: do you mean before or after it was taped out?
<smaeul>
who knows? maybe the timing in the FPGA version was different enough that they didn't notice
<smaeul>
or maybe there was a manager with a deadline and engineer who got to say "I told you so" ;-)
<apritzel>
or they where happy with some kernel workaround ;-)
<anarsoul>
apritzel: you mean "The value on the CNTVALUEB[63:0] bus is required to be stable whenever the internally registered version of the CNTCLKEN clock enable is asserted. CNTCLKEN must be synchronous and balanced with CLK and must toggle at integer ratios of the processor CLK."?
<apritzel>
exactly
<anarsoul>
*sigh*
<apritzel>
smaeul: isn't it only the counter going backwards that is a problem now? So we can just check 2nd read >= 1st read?
<smaeul>
it jumps both directions
<smaeul>
including in the log I linked
<apritzel>
smaeul: yes, but is a forward jump such a problem?
<apritzel>
I mean it's rare, especially in real life (TM)?
<smaeul>
yes, because a forward jump followed by a CPU migration can cause a backward jump
<smaeul>
and unless you remember the previous read, every forward jump is followed by a backward jump of equal magnitude :-)
<apritzel>
was just thinking about "remembering the previous read", is that an option?
<smaeul>
it is indeed an option: CLOCKSOURCE_VALIDATE_LAST_CYCLE
<NekoMay>
Oh, they had another one that used it too
<NekoMay>
Sorry
<NekoMay>
They also have their Fire3 that uses the same chip in an RPi0-style board
<apritzel>
all equally broken ;-)
<NekoMay>
Yep, doomed like so many to an ancient vendor kernel that can't be replaced....
<apritzel>
I was still hoping to find that hidden bit that makes the arch timer tick, but apparently no one has it working
<NekoMay>
It's probably just outright broken, and since their kernel worked on it, that was "good enough"
<NekoMay>
S5P has some really nasty hack to emulate the timer, but it's suboptimal
<NekoMay>
Probably just enough to run Android or whatever
<apritzel>
according to the maintainers, a non-working arch timer is a showstopper for upstreaming
<apritzel>
for arm64
<apritzel>
you can hack it to use another timer, but would lose at least KVM on the way, and other things as well
<NekoMay>
Yeah, that's what the vendor kernel did
<NekoMay>
Shifting to on-topic; Wow, the F1C100s/200s is getting even more popular
<NekoMay>
I suspect that it's used in custom-marked chips in countless handheld emulation/famiclone devices, and there's a bunch of Taobao shops selling them
<NekoMay>
Mainline on that would be a real boon, it'd open them all up wide
<NekoMay>
Is anyone working on the G2D in those and the D1/F133?
<maz>
there is a minimal bar for what we want to support upstream.
<apritzel>
ARM9 should rest in peace these days
<NekoMay>
When a chip costs a couple dollars US *in singles* it's hard to ignore, and it's wide out there in hundreds of devices, like it or not
<NekoMay>
I'll be getting some F1C100s and F1C200s stuff in soon
<apritzel>
NekoMay: the A64 was reportedly 5US$ only as well, so "just cheap" won't cut it
<NekoMay>
I'll see what I can do to help out (I've also got a number of the emulation boxes)
<NekoMay>
Cheap and widespread. Hobbyists like it, and so do the companies cranking out cheap game devices; it's more attractive than the Actions MIPS stuff they used to use.
<NekoMay>
ARM926EJ-S pushed to 700MHz is actually not a slouch, surprisingly enough
<NekoMay>
The emulation is surprisingly good for the core, some of the devices with community support can even do the lower-spec Playstation games
<apritzel>
I was actually hoping we could leave ARMv8.0 behind, but not by going back to ARMv5 ;-)
<NekoMay>
lol
<NekoMay>
Cheap but capable finds its niche
<karlp>
apritzel: that patchwork link requires login?
<NekoMay>
I know the people hacking on the ones like the BittBoy would love upstream support, would let them finally dump the vendor kernel
<NekoMay>
The chips are funny; it's an old ARM926EJ-S core, but it's a lot of fancy stuff around it, like H.265 decoding in the F1C800s
<NekoMay>
lol
<NekoMay>
And Allwinner will supoosedly fab anything you want if you buy at least 10k
<valdikss>
Why do they do that, any ideas? Dirt-cheap licensing?
<NekoMay>
More than likely, their chips are all the cheap cores
<NekoMay>
ARM926EJ-S, Cortex-A7, Cortex-A53
<NekoMay>
And I think they're not paying a hell of a lot for Xuantie X906, either
<NekoMay>
*C906
<valdikss>
I don't understand the reason behind making new SoCs with older architecture when they already have the license for newer architecture.
<valdikss>
AFAIK ARM licensing is one-time payment
<NekoMay>
I believe it's a one-time plus a small royalty per core
<NekoMay>
Though some cores they
<NekoMay>
ve dumped the one-time
<NekoMay>
But the royalty is apparently rather low, and the lower spec the core, the lower the royalty payment is
<NekoMay>
Softbank never really saw them as something to wring as much money as possible out of
<NekoMay>
Which is one of many reasons the Nvidia buyout attempt is worrying
<valdikss>
Do armv5 cores capable of booting themselves?
<NekoMay>
Of course, they're full microprocessors. All of them have been, since the original prototype
<NekoMay>
StrongARM, a very popular ARM core from the past was ARMv4
<NekoMay>
Was used in a few tiny computers and a massive number of PDAs
<NekoMay>
Eventually went to Intel and became XScale, which was ARMv5T, IIRC
<NekoMay>
Dominated the PDA market for years
<NekoMay>
ARMv5TE
<NekoMay>
ARM926EJ-S is ARMv5TEJ
<karlp>
J is jazelle right? does it really have that?
Mangy_Dog has joined #linux-sunxi
<NekoMay>
Yes, it is, and yes it does
<NekoMay>
But the Jazelle docs were kept strictly confidential
<karlp>
always seemed like such a waste that "no-one" ever got to use those parts :|
warpme___ has joined #linux-sunxi
cnxsoft1 has quit [Ping timeout: 480 seconds]
<valdikss>
NekoMay: armv7 can't boot itself
<NekoMay>
Are you basing this off the Raspberry Pi?
<NekoMay>
Because that has a bizarre bootflow
<NekoMay>
karlp: If you had a featurephone in the mid-00s, you probably used Jazelle
<valdikss>
All armv7 cores as far as I know
Benjojo_ has quit []
<NekoMay>
valdikss: [citation required]
<valdikss>
there's a small cortex-m in every armv7 SoC to boot ARMv7 core
Benjojo has joined #linux-sunxi
<valdikss>
the bootrom is executed on this m core
<karlp>
[citation needed]
<NekoMay>
Yeah, I need a reliable source for this
<NekoMay>
Like, not "Big Jim's House of ARM"
<NekoMay>
Preferably ARM themselves
<NekoMay>
No offense, but exceptional claims require exceptional proof and all
MoeIcenowy has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
MoeIcenowy has joined #linux-sunxi
<valdikss>
can't find anything right away
<apritzel>
valdikss: sorry, but what does "boot itself" mean?
<valdikss>
The SoCs I dealt with all had cortex-m core and armv7-a core. Cortex-m was only for booting armv7-a (and for mailbox), v7-a core did not have a bootrom etc. The person who is involved in ARM processors development told me that ARMv7-a cores can't boot themselves, that's why a small m core is installed in soc to boot it. Is that incorrect?
<apritzel>
yes
<apritzel>
according to the ARM ARM, an ARMv7 core starts execution at 0x00000000 or 0xFFFF0000, or at an IMPDEF address
<apritzel>
put some ROM there and you are ready to go
<MoeIcenowy>
Allwinner SoCs just boot from directly Cortex-A
<apritzel>
exactly
<MoeIcenowy>
because they have BROM at 0xffff0000 historically, 0x00000000 currently
<apritzel>
what you cannot do with most cores is to properly shut them down on their own, you need another core or a mgmt core for that
<apritzel>
shutting down in a way where you can safely bring them up again, that is
<apritzel>
you could gate your own power, but that's not safe
<valdikss>
I see
<NekoMay>
Yeah, the MCUs that are tossed in are typically used for power management
<NekoMay>
But sometimes you'll get extra ones, or special ones for doing hard realtime stuff
Mangy_Dog has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
megi4 has quit []
megi has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
cnxsoft has quit []
MoeIcenowy has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
MoeIcenowy has joined #linux-sunxi
jernej_ is now known as jernej
<jernej>
apritzel: re: "ARM9 should rest in peace these days" 8051 ISA is still alive and kicking after 40 years :)
<apritzel>
sure, but it's an ISA, not a micro-arch. And it's for very specific applications.
<apritzel>
I just want Allwinner to make a SoC with A76s, or at least some big cores ...
<buZz>
allwinner x86-64
<buZz>
:D
<maz>
apritzel: you realise that even if they license a76, they're likely to screw up the integration just like they did with any other CPU, right? specially considering that newer cores have more complex interconnect requirements and all that...
<apritzel>
maz: yeah, I know :-( ... but then I can complain about that! ;-)
<maz>
apritzel: shades of N1SDP...
<apritzel>
and I wonder what happens if they realise that their BootROM (and boot0 and U-Boot and ...) needs to be AA64
<apritzel>
maz: but the latest roadmap just shows A73 anyway, I guess because they liked the timer implementation
<maz>
it's the bestest.
Daanct12 has joined #linux-sunxi
Danct12 has quit [Ping timeout: 480 seconds]
Daanct12 is now known as Danct12
<MoeIcenowy>
well, Allwinner always integrates IP cores with "fortune"
<MoeIcenowy>
e.g. a PCIe controller that is not connected to CPU's main data bus (H6)
<apritzel>
MoeIcenowy: but they saved so many cables by doing so! ;-)
<MoeIcenowy>
well I think calling on-chip things wires is more appropriate
<MoeIcenowy>
and I doubt what did they save... an output of bus interconnect?
<apritzel>
sure, I was just trying to find a reason for that ;-)
<apritzel>
it doesn't cost anything to tick the right boxes in the integration tool
<MoeIcenowy>
BTW I have the feeling that D1 does not integrate C906 well
<MoeIcenowy>
FEL behavior is just cursed
<MoeIcenowy>
(it's why I didn't continue on my sunxi-fel D1 hack
<apritzel>
MoeIcenowy: could it be the BROM? I mean they couldn't reuse their ancient AArch32 code ...
<MoeIcenowy>
well maybe, but I think the BROM should be C now?
<MoeIcenowy>
the BROM behavior is just consistent on D1 and other ARM SoCs
<MoeIcenowy>
I doubt it's bus coherency issue
<MoeIcenowy>
(or cache issue)
<MoeIcenowy>
BTW BROM enables extended funtionalities of C906
<apritzel>
the MMU "extension"?
<MoeIcenowy>
and extended insturctions
<MoeIcenowy>
the extended instructions are also enabled by a bit in mxstatus extended csr
<MoeIcenowy>
BTW D1 uses a much older version of C906 than what's released by openC906 project
<apritzel>
like what they did with the AR100
<apritzel>
I guess they wanted to be quick
<MoeIcenowy>
well digital chip design needs much time after RTL freeze
<MoeIcenowy>
so a newly released chip must have a much older RTL
<MoeIcenowy>
(I remembered that Kendryte K210 has also a bug that is fixed in newer RTL
<apritzel>
sure, that's why proper companies respin the silicon at some point, but if you can hack the kernel badly instead, it's much cheaper
<MoeIcenowy>
btw I am just now cursed enough that I'm trying to adapt openC906 on my FPGA
<MoeIcenowy>
what will happen if v7 debug memory map is selected?
<MoeIcenowy>
(spotting this let me remember of my previous failure on debugging A64 in 64-bit mode...
<MoeIcenowy>
(with OpenOCD
<apritzel>
MoeIcenowy: I don't know, but I guess it's just a matter of configuring your tool accordingly
<gamiee>
is there some special configuration needed in OpenOCD to get JTAG working on any AW SoC?
<apritzel>
I don't think it's about 32 vs 64bit, it's more about different offsets
prefixcactus has quit [Ping timeout: 480 seconds]
<jernej>
gamiee: did you have a chance to test HDMI CEC support in Crust?
<jernej>
gamiee: please also open PR for BPi M2 Zero defconfig, this is the only missing one in LibreELEC
tnovotny has quit [Quit: Leaving]
apritzel has quit [Ping timeout: 480 seconds]
<gamiee>
@jernej: hi, still not yet, I was not working on the project for longer time, but I will need to do CEC and other tests ASAP, just need to finish something before
<gamiee>
Also, I don't have M2 Zero, only M2 PLus
<jernej>
ah, sorry for mixup
<jernej>
anyway, let me know how it goes
<jernej>
currently it's a bit annoying that every source change wakes/powers up the board
<jernej>
because CEC controller in automatic mode doesn't check physical address
<jernej>
so, if you open netflix app or dlna source in webos, board wakes up
<jernej>
anyway, board for signal sniffing is almost here, so I could investigate this soon
<gamiee>
Yes, will let you know :) hmm it's interesting that even things as opening Netflix app wakes it up. I wonder what information it sends to the device
<jernej>
maybe I'm remembering it incorrectly, but I didn't connect any other device
JohnDoe_71Rus has quit []
<jernej>
smaeul: is there any possibility for some kind of configuration interface in Crust? like some nvmem storage, RTC scratch registers or even vendor scpi commands (if that even exists)?
<jernej>
I imagine that some people will love HDMI CEC wake up but others will hate it
<jernej>
and I don't want to provide two images for each board
<buZz>
CEC is userland anyway, isnt it?
<buZz>
oh, from sleep? gee
<jernej>
buZz: yeah, it's possible now that your TV wakes up AW boards :)
<jernej>
very useful for multimedia center type of use cases
<buZz>
my TV doesnt do any CEC i think
<jernej>
hm... even 10+ years old TV has it
<jernej>
but it's usually hidden under TV manufacturer brand name, like simplink, easylink, bravia link, viera link, etc
<buZz>
this is a samsung 'hd ready' 32" that i dumpsterdived
<buZz>
had a sticker 'broken!' on it, tried, worked directly, never any issues
<buZz>
maybe just no CEC for power? not sure
<jernej>
Samsung CEC trade name is anynet+
<buZz>
this samsung 32" isnt 'smart'
<buZz>
just a plain tv, even has SCART inputs :)
<buZz>
and just -1- hdmi input, hahaha
<jernej>
sure, plasma TV from my parents have scart, it's not smart, but still has HDMI CEC support
<valdikss>
apritzel: it should work, I basically did the same. If you want, I'll compile and test.
<apritzel>
valdikss: if you say you had something the same, that's fine for me
<valdikss>
my variant returned -ENODEV, not the result of sun4i_usb_phy_vbus_detect (which should be 1)
hlauer has joined #linux-sunxi
<apritzel>
well, -ENODEV is wrong
<apritzel>
this function is called g_dnl_board_usb_cable_connected(), so we *want* VBUS to be detected
<apritzel>
I think this code was blindly copied from drivers/usb/musb-new/sunxi.c, where we want the exact opposite
<apritzel>
it would just be great if someone could confirm this
<valdikss>
apritzel: works fine, just tested.
<apritzel>
valdikss: thanks!
renze_ has joined #linux-sunxi
renze has quit [Ping timeout: 480 seconds]
hlauer has quit [Ping timeout: 480 seconds]
<smaeul>
jernej: all of those are options, but I would like to avoid any custom message passing if possible, because the I have to implement/maintain the client side too :)
<smaeul>
so my ideal way of enabling/disabling CEC wakeup would be to look at how the hardware is configured (e.g. is the IRQ enabled?)
<smaeul>
my reasoning is that anything that should wake from s2idle must have a wake-enabled IRQ on the Linux side anyway
<smaeul>
and then you can use the normal sysfs attributes to control it from userspace
<smaeul>
the limitation is that it only works for on/off choices, not "which CEC messages to listen for" (or "which IR scancode to listen for")