<smaeul>
and while they're not wrong, unless we plan to change the pinctrl and CCU drivers to use hwspinlocks, I don't see a use for the driver
<montjoie>
someone already send hwspinlock in the past. I was sure it was merged already
<smaeul>
hwspinlocks might be helpful for people using the AR100 to do stepper motor control or other real time GPIO (there are some examples floating around), but crust doesn't need them
<mripard>
smaeul: debugging crust over the same UART seems useful too?
<smaeul>
you mean wrap puts() in a spinlock?
<smaeul>
there's a certain skill to reading interleaved log messages :)
<mripard>
yeah, that's what I meant :)
<mripard>
I'm not even sure the realtime stuff you mentionned would use it, taking a lock seems pretty bad if you care about latency
<smaeul>
I suppose uart locking would be nice as a patch for debugging, but I wouldn't want to impose that cost all of the time
<mripard>
but I totally expect at some point to have CCU / pinctrl support of hardware spinlocks
<mripard>
I'm kind of expecting to have the same bunch of issues with that driver than the one you encountered with the mailbox with the resets and clocks
<smaeul>
yeah, that would fail hard, since reading a 0 means "try again"
<smaeul>
oh, actually I have that backwards. turning off the device would make all locks read as free
<smaeul>
mripard: when you say "at some point", what do you think the motivation would be?
cmeerw has joined #linux-sunxi
<mripard>
I don't know, but there's a lot of creative people out there (yourself included) :)
<mripard>
sharing a GPIO for something to toggle an LED or something would be a pretty trivial usecase I guess?
<smaeul>
yes, there definitely are usecases. but so far, nobody's showed up with an AR100 firmware that actually does any of that (thus "I wrote this driver but I have no way to test it")
<smaeul>
my experience is that mainline linux(-sunxi) prefers native drivers over firmware drivers wherever possible, so I try to do as little as possible while Linux is running
rreignier has joined #linux-sunxi
<smaeul>
oh wow I didn't see that there was a fourth(!) driver submission
<smaeul>
the real news is that Allwinner makes a SoC with an Xtensa processor in it... I wonder which one that is
<mripard>
smaeul: yeah, it raised my eyebrow too :)
<mripard>
and for the general preference, I don't know if it's a strong preference
damex has quit [Ping timeout: 256 seconds]
<mripard>
crust is definitely a good thing to have
<mripard>
but only a (decent) fraction of the SoCs have the AR100, so if we have a driver in crust, we'll have to have a driver in the kernel for it anyway
<mripard>
(and firmware is harder to update by distros, so it's harder to get rid of potential bugs one might have there)
ldevulder_ is now known as ldevulder
<libv>
firmware is just software that the creator does not want changed or be looked into, so it has, per definition, more issues and bugs than open code
<libv>
and instead of fixing issues in the hardware, you get to work around both the issues in hardware and firmware together.
<mripard>
crust or u-boot seems to be the opposite of "software that the creator does not want changed or be looked into" though
<libv>
if you think that allwinner's own u-boot/kernel code is bad, think about what it looks like in the bits that they think should not be visible to all
<mripard>
this is not really the topic here
<libv>
ok
dev1990 has joined #linux-sunxi
apritzel has joined #linux-sunxi
ElBarto_ has quit [Quit: leaving]
ElBarto has joined #linux-sunxi
florian_kc has joined #linux-sunxi
florian_kc is now known as florian
afaerber has quit [Remote host closed the connection]
<bauen1>
apritzel: that is good to hear
<apritzel>
bauen1: so thanks for your help on that. For the H6 those registers are in the RTC?
<bauen1>
yes
<bauen1>
i think so let me check
<bauen1>
yes
<apritzel>
and this BOOT_CPU_HP_FLAG_REG gets the magic?
<bauen1>
since the sid seems to load the efuse contents into memory on reset i think pointing CPU_SOFT_ENT_REG0 towards that and using the 0x20 - 0x30 bytes as encryption key or as secrets could work
<bauen1>
then burn a bit of code into the sid that copies the sbrom e.g. into some SRAM (e.g. CSI SRAM) and then patches the memcmp8 functions that verify the magic to also set the toc0 header length to a fixed value might work
<bauen1>
and then you could also store a replay counter in the rtc too
<bauen1>
at least i think the sbrom is fully relocatable
cnxsoft has quit [Read error: Connection reset by peer]
\\Mr_C\\ has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
Ashleee has quit [Remote host closed the connection]
Ashleee has joined #linux-sunxi
s_frit has joined #linux-sunxi
bitdefect has left #linux-sunxi [#linux-sunxi]
daregap has quit [Quit: daregap]
nashpa has quit [Quit: Going away]
nashpa has joined #linux-sunxi
damex has joined #linux-sunxi
<apritzel>
wens: thanks! kudos go to bauen1 for mentioning the "hotplug" BROM facility
<bauen1>
apritzel: nice
<apritzel>
but that means more work, because I now need to revive and polish my hacked sunxi-fel FIT image support patch ...
<bauen1>
apritzel: by the way are you doing this in your free time or at work ? (looking at your arm.com email address)
<apritzel>
bauen1: in my spare time, it's merely tolerated at work
<apritzel>
bauen1: we don't want to give the impression that missing engagement from a SoC vendor is compensated by Arm
<apritzel>
but it's company policy to use the work email address for projects that you contribute to also officially
<libv>
apritzel: yet the copyright goes to the company?
gaston1980 has joined #linux-sunxi
<apritzel>
libv: sure, that means I don't need to defend that legally myself
<apritzel>
and the license covers the practical part
<libv>
the license covers almost everything
<libv>
and you will find that a corporate overlord will not care much if it you do think it needs defending
<bauen1>
apritzel: nice, i heard the part about the engagement somewhere before
<apritzel>
libv: they surely care more than I do
popolon has joined #linux-sunxi
<libv>
ok
<apritzel>
and since Arm is a legal company with attached engineering, they are in a much better position for those kind of affairs
<ElBarto>
apritzel: hi, I recall in one of your fosdem talk that you said that a64 could boot with a gpt scheme if u-boot was placed at some other location (and maybe splitted)
<ElBarto>
apritzel: is it doable with current mainline u-boot ?
<apritzel>
ElBarto: yes, that works now
<ElBarto>
oh awesome
<apritzel>
just copy the whole file to 128K instead of 8K
<apritzel>
everything else is taken care of
<ElBarto>
let me try that now !
<ElBarto>
if I can swithc all the aarch64 freebsd release to gpt that would be way easier for me
<apritzel>
yes, GPT was the main driver for pushing this
<mripard>
ElBarto: it was working before as well, you just needed a slightly non-standard GPT
<ElBarto>
mripard: yeah which I wanted to avoid
<mripard>
fortunately it can be flashed by u-boot straight away
<ElBarto>
apritzel: awesome it works
<ElBarto>
well, let me test with a gpt scheme too :)
<mripard>
(gpt write mmc 0 $partitions)
<apritzel>
ElBarto: the only thing to keep in mind is that some SPL at 8K takes precedence
<ElBarto>
yeah
<apritzel>
so if someone accidentally put some eGON magic at 8K, the BROM will try to use that
<ElBarto>
that make sense, it's only a fallback at 128k
<ElBarto>
it's not a problem for the release image that we provide
<ElBarto>
I just have to warn users who wants to migrate
<apritzel>
yeah, and if someone smears some data into the middle of the partition table you have other problems, I guess
<ElBarto>
ok cool, works well with a gpt table too
<ElBarto>
that's awesome, it will make my life way easier
<ElBarto>
thanks
ldevulder has quit [Quit: Leaving]
<apritzel>
ElBarto: you can even have a firmware partition in your GPT, covering the area that U-Boot occupies
<apritzel>
which makes this safer, but also allows to update the firmware by just dd'ing to this partition, without magic offsets
<ElBarto>
firmware partition ?
<ElBarto>
is there an uuid for them ?
<apritzel>
I think so
<ElBarto>
I see a bios-boot type in our tools with an uuid of !21686148-6449-6E6F-744E-656564454649
<ElBarto>
that's not a bad idea to add that to our images, I'll have a closer look
<apritzel>
yeah, that one
cnxsoft1 has quit [Quit: cnxsoft1]
<apritzel>
I think it was for legacy grub, which also lives in the "gaps"
<ElBarto>
yeah our manpage talk about grub2 for this type
JohnDoe_71Rus has joined #linux-sunxi
ldevulder has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
lkcl has quit [Ping timeout: 260 seconds]
matteoelimo has joined #linux-sunxi
lkcl has joined #linux-sunxi
fl_0 has quit [Quit: STRG + Q]
rreignier has quit [Ping timeout: 272 seconds]
fl_0 has joined #linux-sunxi
diego71 has quit [Ping timeout: 260 seconds]
diego71 has joined #linux-sunxi
tuxd3v has joined #linux-sunxi
kaspter has quit [Read error: Connection reset by peer]
camus1 has joined #linux-sunxi
camus1 is now known as kaspter
ddlstwrr has quit [Quit: Leaving.]
victhor has quit [Ping timeout: 256 seconds]
eduardas has quit [Quit: Konversation terminated!]
<wens>
apritzel: IIRC this only works on the newer SoCs?
<apritzel>
wens: yes, it didn't work when testing on the A20, but H3 was fine
<apritzel>
I don't have anything "in between" to draw the line
putti_ is now known as Putti
ldevulder has quit [Quit: Leaving]
florian has quit [Quit: Leaving]
rreignier has joined #linux-sunxi
apritzel has quit [Ping timeout: 272 seconds]
tnovotny has quit [Quit: Leaving]
PineN00b has joined #linux-sunxi
PineN00b has quit [Remote host closed the connection]
PineN00b has joined #linux-sunxi
apritzel has joined #linux-sunxi
PineN00b has quit [Remote host closed the connection]
* psydruid
wonders if we might see HDMI audio support for Allwinner SoCs in the mainline kernel in the course of next year, particularly for A64
gaston1980 has quit [Quit: Konversation terminated!]
<psydruid>
apritzel, I tested the allwinner_hdmi_audio_v4 branch recently, but I see there is now an allwinner_hdmi_audio_v10 branch, which I will try soon
<psydruid>
I'm on 5.9.6 now
rreignier has quit [Quit: WeeChat 3.0]
luke-jr has quit [Read error: Connection reset by peer]
luke-jr has joined #linux-sunxi
<apritzel>
psydruid: actually it looks like those patches have been pulled into -next already, so they would be part of v5.11
<bauen1>
before i remembered that i can just hook the power up to the uart usb i tried taping some wires to a coin battery that i've salvaged from the motherboard that was in the 1u firewall appliance that i want to turn into a "case" for the h64 and a64 once i don't need direct access to them anymore
<apritzel>
bauen1: lol, this is my plan for years, but this "don't need direct access to them anymore" point just doesn't want to come ;-)
<jernej>
psydruid: those patches will not land as-is, I'm working on hdmi audio card driver, which will connect i2s and hdmi together
<jernej>
however, they should work if you need hdmi audio now
<apritzel>
jernej: stereo! That sounded great back when I only had a SoundBlaster 2.0 ;-)
<bauen1>
KotCzarny: my end plan is to buy an actual rack (somthing like 12u) just so i can keep all my hardware and networking stuff somewhat tidy
<jernej>
apritzel: I made some progress with h616 dram driver, I just need sanity check - if board has 8x 4-bit DDR3 chips - is that 32-bit single rank or 16-bit dual rank? or could be both?
<bauen1>
KotCzarny: haven't really figured out what i can do with the h64 and a64, but i'll probably hook them up to an hdd or ssd and use them as servers for stuff with low requirements and maybe as build server
<jernej>
apritzel: don't worry, multi-channel is wip, I just have to find some time to get back on that
<KotCzarny>
bauen1: yup.
<jernej>
however, it won't land in 5.11
<KotCzarny>
bauen1: in my case they also server as a audio player
<KotCzarny>
on top of home 'server' tasks
<apritzel>
jernej: no clue about the ranks. So since I got my OPi Zero 2 today, does your updated github branch contain the fixes?
<jernej>
let me push very latest fixes
<apritzel>
jernej: I wanted to start cleaning up and splitting up the patch, if you don't have anything (and don't plan to do that)
<KotCzarny>
bauen1: best part is low power usage, so they can be on 24/7 without me noticing anything on the bill
<bauen1>
KotCzarny: yeah i have an r710, but a) it's a bit too loud (but i think that is the hdds fault at this point) and b) it uses >= 110W
<bauen1>
apritzel: it has 4 leds i think, the green always on power led, 1 blue led and apparently another 2 that i haven't used yet
<jernej>
now it correctly detects ram size, but trainings/calibrations fail for some reason and I didn't implemented bit delay compensation yet
<apritzel>
jernej: cool, thanks!
<bauen1>
apritzel: actually the green one might be controllable too
<apritzel>
bauen1: the old Pine H64 I have has an insanely bright white power LED, looks like TL Lim saved on the resistor
<bauen1>
20v will fix any bright led
<jernej>
I believe this was engineering sample, I have such pineh64 too
<bauen1>
the power led on this one is green
<apritzel>
jernej: only legit with that purple patch cable and the useless (and even wrongly connected) mini PCIe slot
<jernej>
yeah, I have that board too
<KotCzarny>
why nuking the led when you can just paint it over
<jernej>
I remove leds sometimes - super bright blue led on car phone charger is super annoying when driving at night and no amount of tape helped
<bauen1>
apritzel: there are 3 leds (can't seem to control the "white link led" on PL3 yet)
<bauen1>
but that one might be connected to the emac phy in some way which isn't enabled
<bauen1>
all at the back and quite bright
<bauen1>
it's such a shame that the h64 doesn't have a (functional) mini pcie slot
<apritzel>
bauen1: that's not the H64's fault, the PCIe controller in the H6 SoC is broken beyond repair
<apritzel>
that's why TL Lim removed it from revision B of the board
<bauen1>
yes
<bauen1>
i know
<bauen1>
still a mini pcie slot makes a board a lot more useful (but might also be another security nightmare)
<apritzel>
not sure why some many SoC vendors are so miserly on assigning MMIO address *space*
<bauen1>
apritzel: what do you mean ?
<apritzel>
bauen1: they gave the whole PCI root complex exactly a 64K MMIO window
<apritzel>
so *everything* has to be funnelled through this: config space, MMIO, DMA, I/O ...
<apritzel>
which means you have to constantly remap everything, which Linux does not support (for good reasons)
<KotCzarny>
64K should be enough for everyone!
<juri_>
I recently saw ben heck do a youtube review of my first computer. I mention it because the machine had 256 Bytes of ram.
<apritzel>
KotCzarny: even him was an order of magnitude more generous ;-)
<KotCzarny>
does mapping more mmio require more address lines or anything in soc?
<bauen1>
juri_: i've build a 65c168 (like the 6502) sbc that has ~32kb of ram but due to lack of components no io or rom apart from an atmega that does uart and exposes a whole 8 bytes of rom
<bauen1>
or maybe 32 bytes
<bauen1>
it's enough to load another stage over a (simplified) serial interface lol
<apritzel>
KotCzarny: yes, but it stays all in the silicon (it's a Soc!), so it's just a matter of clicks in your design tool
<juri_>
yeah. my point is hardware is hardware. 64k sounds small, but that virtualization hack made it usable, right?
Ntemis has joined #linux-sunxi
vagrantc has joined #linux-sunxi
<karlp>
apritzel: what are the "good reasons" ? other than, "we don't do it like that" ?
<karlp>
I mean, sure, it's another layer of indirection and omg perf, but the whole "we just don't do it at all" ? I've never followed why that was not allowed?
<jernej>
I heard that Linux once had accessor methods for PCIE but they removed that and replaced with direct access
Ntemis has quit [Read error: Connection reset by peer]
<jernej>
or maybe DRAM issue, not sure if SPL uses DRAM from that point on
victhor has joined #linux-sunxi
<bauen1>
interesting there's actually a bunch of references to the cpu0 boot hotplug register magic value all over the sbrom, that might be worth investigating
lurchi_ is now known as lurchi__
<apritzel>
jernej: yes, for .BSS (interestingly)
<apritzel>
jernej: the SPL MMC driver already uses DRAM
<apritzel>
karlp: so what do you do with MMIO BARs larger than the window?
<apritzel>
karlp: and with multiple CPUs accessing potentially different devices at the same time?
<apritzel>
karlp: all of that is not really a problem for anyone, expect for those botched devices
<jernej>
apritzel: but that part shouldn't be active when booting through fel, right?
<apritzel>
jernej: not the MMC driver, no, but other parts that use BSS variables
<apritzel>
jernej: IIRC printf was such a candidate, under some circumstances
<apritzel>
karlp: and you would need to modify all *PCI device* drivers, since they believe they can access those mapped MMIO regions at any time, using some DMA controller, for instance
<karlp>
ok, that's a _good_ reason.
<karlp>
ther others still sort of sounded like, " you'll never get the performance you expect, so we're just not goign to let you"
<apritzel>
performance is not the issue
<KotCzarny>
i wonder if writing some virtual pcie host that could act as a proxy might work
<apritzel>
but what do you with that 128K packet buffer window my Ethernet card requests
<karlp>
deny it?
<apritzel>
meaning the device won't work?
<karlp>
well, I had _assumed_ they would try smaller sizes, but like I said, that's a reason I can understand at least :)
<apritzel>
KotCzarny: what do you mean with "virtual"
<KotCzarny>
apritzel: sw one, not real hw
<apritzel>
to be clear here: config space accesses are not really the problem, because they are well isolated, through wrappers already, and follow strict device memory semantics, with only certain access sizes
sunshavi has quit [Ping timeout: 256 seconds]
<apritzel>
KotCzarny: but how would a virtual PCI controller solve the MMIO problems?
<KotCzarny>
emulate it?
<karlp>
so, this AW device isn't the only one with a "too small" pcie window then right?
<karlp>
how does this normally happen? does it work on other systems for other "reasons" ?
<apritzel>
karlp: a good question. I guess it works if you just connect a single WiFi chip in your deeply embedded device, and don't care about upstream (or Linux at all)
<apritzel>
karlp: I heard about a Realtek (SoC) implementation recently with just a 4 K window ;-)
<karlp>
hrm, out of my depth, but address spac eis cheap, what could possibly motivate such a thing?
<bauen1>
hrmp, doesn't look like the h64 fancies executing things inside the rtcs address space
<bauen1>
is there some kind of reason why you couldn't execute mmio space =
sunshavi has joined #linux-sunxi
<bauen1>
or maybe my code is just broken
<apritzel>
bauen1: IIRC there are architectural restrictions on where the CPU can fetch instructions from (but I can't find that right now)
<bauen1>
turns out i just can't use sunxi-fel write to write to device memory
<bauen1>
that's even documented somewhere
<jernej>
by device memory you mean mmio or dram?
<apritzel>
bauen1: but "writel" would work for that?
<bauen1>
yes
<bauen1>
./sunxi-fel -v -p writel 0x07000100 0xe59f0010 writel 0x07000104 0xe59f1010 writel 0x07000108 0xe5801000 writel 0x0700010c 0xe3a01080 writel 0x07000110 0xe5801010 writel 0x07000114 0xeafffffe writel 0x07000118 0x07022000 writel 0x0700011c 0x17777777 writel 0x070001b8 0xFA50392F writel 0x070001bc 0x07000100 # program hotplug and gp regs with led demo
<bauen1>
for h64, as long as the rtc has power resetting won't boot anything but just enable the blue led
<apritzel>
jernej: "device memory" is the opposite of "normal memory", typically it's MMIO semantics vs. DRAM, respectively
<jernej>
ok, sram falls into normal memory category?
<apritzel>
jernej: but without the MMU you can't set different types for certain regions, so you get the strictest type, which is Device_nGnRnE
<apritzel>
jernej: that depends on the actual SRAM controller, but SRAM, by it's very nature, has memory semantics
<apritzel>
so you can merge accesses, reorder them, cache them
<apritzel>
the reason is that ARM does not have MTRR registers, which solve this problem on x86
<apritzel>
once you have page tables, you set the memory type and attributes in the PTE (as you can do on x86 as well: PAT)
cmeerw has quit [Ping timeout: 260 seconds]
<apritzel>
(and that's also the reason we need to enable the MMU to enable the data caches, see U-Boot or even the BROM for some older SoCs in FEL mode)
<apritzel>
bauen1: don't know from the top of my head how sunxi-fel's "write" is implemented, but those registers might only be accessible by <=32 bit writes, for instance
<bauen1>
they might just be accessible to exactly 32 bit writes, but what ever, a bit tedious but it works
<bauen1>
moves the stack to the end of SRAM A2 and then "returns" to the sbrom, resulting in the 128kb attack image no longer working
<apritzel>
bauen1: but if you go crazy large with your image, can't you still reach the end of SRAM A2?
<apritzel>
bauen1: or is there some limit on the image size?
asdf28 has quit [Ping timeout: 260 seconds]
<bauen1>
apritzel: there is none
<bauen1>
apritzel: so my goal is to copy the sbrom code to SRAM A2, slightly patch it to limit the total size and then execute it
ldevulder has joined #linux-sunxi
<bauen1>
apritzel: as a PoC it needs to fit into the 0x30 bytes i get from the RTC, but the end goal would be to burn that code into the sid, point the hotplug entry to the sid sram and store a secret key in the rtc registers
<bauen1>
apritzel: so if you try to remove the rtc power the secrets get erased
<bauen1>
apritzel: while not loosing boot functionality
<bauen1>
maybe not the most practical since having any issues with the rtc power supply will erase the secrets, but it would be the most secure
<apritzel>
bauen1: so you can verify your "really secure" boot later on? By checking the secret in the RTC register? And when you find it, you know that you must have booted through your patches SBROM?
<bauen1>
(if you ever need to change the rtc battery you can do that while normal power is applied i think)
<bauen1>
apritzel: even better you use the secret in the rtc as a decryption key for your real secrets (that are probably bigger than 0x30 bytes)
<bauen1>
apritzel: just checking the bytes could be circumvented, but you can't easily fake the >256 bits of an encryption key
<bauen1>
apritzel: and as i've mentioned it gets even better since you can now store a few bytes of replay counters in the nvram ; that makes implementing a secure TEE easier
<bauen1>
anyway i need to figure out how to do that and see if i can't make a little demo with it