<Soupborsh>
<apritzel> "soupborsh: I doubt you can enter..." <- Hello, thank you for response. Do you know how to identify this pads if they exist? There are a lot of pads, I think only UART ones are labeled.
<Soupborsh>
<apritzel> "if the reader uses "secure boot"..." <- I did try with SD card regularly but didn't try to do with TOC0 image.
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
warpme has joined #linux-sunxi
colinsane has quit []
colinsane has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
warpme has quit []
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
Soupborsh: Hi, yeah, I saw quite some pads on your picture in the Wiki, but there is no safe way to identify them, really. In this tablet of mine it was actually labelled "FEL".
<apritzel>
for creating a FEL TOC0, try: make fel-sdboot.bin; mkimage -A arm -T sunxi_toc0 -a 0x20060 -n FEL-SDBoot -d fel-sdboot.bin fel-sdboot.toc0
<apritzel>
(in a checked out sunxi-tools repo, but using mkimage from U-Boot's tools/ directory)
<parthiban>
Adding A133's display pipeline. That's the idea.
<Jookia>
i have confirmed that removing the mixer dt and disabling the clock does help- in some cases. but not all
<Jookia>
it seems when mixer1 is disabled the t113 will still tint the screen in some cases
<parthiban>
True. But mixer1 is for DE0 if am not wrong. We don't have info for DE1 right?
<parthiban>
Back to A133, my question is. DE's memory map is at 0x06000000. But am expecting to read 0's, but not super random values https://pastebin.com/raw/yju1wU9Q. What am I missing?
<Jookia>
hmm, am i conflating mixer1 and DE1? are there chips with two DEs inside?
<parthiban>
That was my question as well earlier this week.
<Jookia>
have you looked at allwinner's bsp code?
<parthiban>
A133's vendor bsp says there are DE0 and DE1. With each 1 mixer. 2 x TCON TOP, 2 x LVDS OR 1 x LCD (24 bit), 1 x DSI.
<parthiban>
DE_PORT_SELECT_REG is used to select it over DE0 and DE1. This is how I see it. But only ref we have is R40 in my end.
<parthiban>
Btw, my knowledge about sunxi platforms and A133 is less then 1 month. Am new here, so I might be wrong as well. Sorry!
<Jookia>
i don't see anything in the A133 manual about the DE1
<Jookia>
i'm currently the anycubic ace person in 3d printer land
<parthiban>
"Back to A133, my question is. DE's memory map is at 0x06000000. But am expecting to read 0's, but not super random values https://pastebin.com/raw/yju1wU9Q. What am I missing?" Any ideas?
<Jookia>
hmm. is there a device tree for the sonic pad?
<MasterR3C0RD>
The vendor device tree is in its repo; I have the beginnings of a device tree but there's still some regulator oddities going on
<MasterR3C0RD>
Half of the regulator definitions are wrong or missing, especially in regards to the MMCs
<Jookia>
i think ./lichee/linux-4.9/arch/arm64/boot/dts/sunxi/sun50iw10p1.dtsi would be a good reference
<MasterR3C0RD>
But I've been able to figure some of them out with both trial-and-error and guesswork
dsimic is now known as Guest8848
dsimic has joined #linux-sunxi
<Jookia>
since that does have two disps, disp and disp1. but it also has an iommu handle
<Jookia>
maybe you need to set some iommu flag to actually see the de?
<MasterR3C0RD>
Also, parthiban: I don't think there is a second DE; I would assume that if there were, there'd be a second clock you'd have to ungate to use it
Guest8848 has quit [Ping timeout: 480 seconds]
<MasterR3C0RD>
It might have been a case where they added a "dummy" DE because their driver was written with the expectation of having two DEs
<MasterR3C0RD>
There are other vestigial devices that the device tree suggests it has but doesn't, like a CRTC
<parthiban>
IOMMU flags? Is there a driver for it in upstream?
<apritzel>
drivers/iommu/sun50i-iommu.c
<Jookia>
it seems like the h6 dts also specify the iommu flag
<apritzel>
it is my understanding that this is optional, though, mostly to create the illusion of consecutive physical memory for the video codecs (scatter/gather)
<Jookia>
i think it would be something like iommus = <&iommu 0>;
<Jookia>
not sure
<Jookia>
the bsp calls sunxi_enable_device_iommu(DE_MASTOR_ID, true);
hipboi has quit [Quit: hipboi]
<Jookia>
i think the address is right, the dt says 0x06000000 is for de0 and 0x06800000 is for de1
<Jookia>
it also says 'iommus = <&mmu_aw 0 0>;'
<apritzel>
well, we had H6 graphics support working for quite a while before the IOMMU driver was added
<apritzel>
it *is* the right think to connect the DE to the IOMMU, but I guess the default config for the IOMMU is bypass mode?
<apritzel>
I guess you could stitch together the framebuffer from non-consecutive memory as well, but this is not so much of a problem as it is for the video encoders/decoders
<parthiban>
cross checked the register values. default seems bypass mode. But "IOMMU Enable Register" is enabled and write doesn't change it as well.
<Jookia>
ah, so maybe not that
<Jookia>
are those register values really random btw?
<parthiban>
wait, enable register is not really enabled. I couldn't change it as well.
<jakllsch>
are your clocks and resets right?
<parthiban>
For the DE, yes
<apritzel>
just checking: did you change the ownership of SRAM C from the CPU to the DE?
warpme has joined #linux-sunxi
<Jookia>
maybe the DE is at 0x06800000 ?
<parthiban>
values are random for sure
<Jookia>
the device tree seems to imply its built with CONFIG_INDEPENDENT_DE which reads DE1
<parthiban>
Wow, values are clean at 0x06800000.
<parthiban>
So I need to use DE1?
<Jookia>
i don't know. maybe give it a try to see if it'll work with the de at that address?
<parthiban>
"just checking: did you change the ownership of SRAM C from the CPU to the DE" apritzel: no. Why is this related? How to do that as well?
<apritzel>
SRAM C is used by the DE (for some tables IIRC?). At boot SRAM C is accessible only by the CPU, so we use it as desperately needed memory for early firmware
<parthiban>
Well, still I have the other parts of display pipeline is middle of something. Strange part is the LVDS PHY. It's shared with DSI and the registers are placed in DSI block. So enabling LVDS PHY needs enabling DSI.
<parthiban>
Anyways I will try using the DE1
<apritzel>
after boot you are supposed to switch ownership to the DE, which makes it inaccessible from the CPU, but allows usage by the DE
<apritzel>
this is done in the "SRAM controller driver"
<parthiban>
A64 right? I checked that. But do I need that for A133?
<apritzel>
drivers/soc/sunxi/sunxi_sram.c
<apritzel>
the manual seems to suggest so, read 3.5.2.1 SRAM
<parthiban>
ok, So I need the bus driver for that as well. Using drivers/bus/sun50i-de2.c
<apritzel>
and we had this in the other SoCs as well, H6 and H616
<parthiban>
I see the reference in A64 and H6.
<warpme>
apritzel : maybe you will some hints:i have h313 box (tx1, pcb2.0). I'm entering fel mode; execute uboot then box hangs. nothing on uart. As uart is total silent - it is possible that box has secure boot activated? FYI: some basic queries of box sunxi-fel: https://gist.github.com/warpme/9d1773d9be591b7695737192864052f1 At bottom i compared decompiles dt from working tx1 and from non-working tx1. pls look at L38.....
<Jookia>
in the bsp drivers/clk/sunxi/clk-sun50iw10.c has the de1 clk, located at 0x0604 offset in the ccm
<parthiban>
yeah, I did check that.
<parthiban>
But didn't expect de0 fails to read in the register level.
<Jookia>
it seems like to use de1 you have to enable the de1 clock and clk_dpss_top1. not sure. its also unclear if de1 even works?
<apritzel>
parthiban: in general the bus clocks and resets need to be enabled to access the respective peripheral's registers
<Jookia>
almost all the bsp code implies that there is a DE1 and it's just located at a different memory address with different clocks, and the tcon lets you select which to use
<Jookia>
this makes me think this tint comes from the tcon being copy pasted to the t113 and trying to read from a non-existant de1?
<Jookia>
but it wouldn't explain why you're reading garbage where the DE0 is suppose to be
<parthiban>
True
<parthiban>
Question again, assume there exists DE1 + TOP1 + mixer1, I will be able tie this pipeline to LCD0 right?
<Jookia>
yes
<parthiban>
By changing DE_PORT_SELECT_REG DE0 to TV0 or so and use the DE1 for LCD0?
<Jookia>
yes i think so
<Jookia>
changing the dt address and clocks and port select reg would be a good way to check this
paulk has quit [Read error: Connection reset by peer]
paulk-bis has joined #linux-sunxi
<Jookia>
it seems like this DE1 is unique to and required by SUN50IW10
bauen1_ has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
<apritzel>
warpme: "entering fel mode; execute uboot then box hangs"> is that the sunxi-fel behaviour? So does it continue loading a whole U-Boot payload, and then hangs?
<apritzel>
FEL mode one a secure boot box is initially non-secure, which means we cannot switch the AArch64, and even if, other things wouldn't work, like the GIC
<apritzel>
but on most SoCs this can be fixed by doing an "smc" call, which returns in secure mode
<apritzel>
warpme: ah, I just see we are missing the bit in soc_info.c for the H616, that would enable that. I personally didn't encounter a secure H616 device before, I think ...
<apritzel>
and since the H616 lacks secure SRAM, it's not as easy to check whether we need it
<apritzel>
warpme: let me have a think about how we could check for this, then I could make a patch for sunxi-fel
<apritzel>
warpme: "burn_secure_mode = <0x01>;" seems indeed to indicate a secure boot device
<warpme>
this uboot spl works well on on another tx1
<Jookia>
parthiban: after looking at the sunxi bsp source code it looks like whats happened is that instead of having a DE with two mixers they've made two DEs with one rtmx/smbl/vsu/wb each. it looks like maybe this was done so you can have two WBs
<Jookia>
o
<Jookia>
oops
<Jookia>
wrong window
<Jookia>
so it looks like a working patch will probably need to actually set proper values based on the pipeline
<Jookia>
assuming de1 actually works for you :)
<parthiban>
Jookia: DE1 is used by default in the bsp vendor?
<Jookia>
i'm not sure
<parthiban>
Which file/line referring to?
<Jookia>
for which part? its spread over multiple files. but if you grep for CONFIG_INDEPENDENT_DE you can see most the pain points
<MasterR3C0RD>
You should take a look at the "INDEPENDENT_DE" code; that's defined in a header specifically for sun50iw10
<Jookia>
yeah
<apritzel>
warpme: right: the first thing that the SPL does is to switch to AArch64, which requires being in secure state
<Jookia>
if everyone's on the same page about this i'll write down my findings as a reply to my patch thread
<parthiban>
Sure.
<Jookia>
parthiban: do you plan on testing the de1 today? should i hold off on emailing until you have results? :)
<parthiban>
am tweaking the same dts with address changes. Shouldn't take long. Give me few
<Jookia>
no pressure!
<apritzel>
warpme: I think there is a proof-of-concept hack which you could use to get it going anyway ...
<parthiban>
TCON_CLK_GATE_AND_HDMI_SRC_SEL doesn't have LCD0 clk gating. It doesn't need one?
<warpme>
ah perfect! i'm all ears now :-)
<apritzel>
warpme: if you add ".needs_smc_workaround_if_zero_word_at_addr = 0x10000," to the H616 entry in soc_info.c, it would always assume secure mode, and would always issue the smc
<apritzel>
this would even trigger of non-secure devices, so it's not a proper solution, but would prove that this is your issue
<Jookia>
there's so many manuals and source code trees x_x
<apritzel>
warpme: yes, exactly
<Jookia>
parthiban: i believe the ccu has a lcd gate/reset
<Jookia>
but i dont think the tcon has one
<warpme>
well - this not helps. i'm getting exactly the same behaviour (usb_bulk_send() ERROR -7: Operation timed out) - but now also on another, working tx1 box
<warpme>
btw: this non-working tx1 is a bit unusual. It has i.e. different emmc layout so i.e. attempt to read dram para from eGON fails. infact emmc.bin don't have any string "eGON"....
<apritzel>
warpme: yes, because secure boxes use the "TOC0" boot image format instead of eGON
<warpme>
indeed - i see TOC0 here.
<apritzel>
if it would have an SD card, all you would need to do is to set CONFIG_SPL_IMAGE_TYPE_SUNXI_TOC0=y in the U-Boot config
<apritzel>
but we both know that this TX1 is a neat challenge in this regard ;-)
<warpme>
oh - this is tx1 so indeed no sd card
Schimsalabim has quit [Ping timeout: 480 seconds]
<apritzel>
yeah, I was already scratching my head about how Jon Doe would bootstrap this box, outside of toothpick & USB-A - USB-A cable ;-)
Schimsalabim has joined #linux-sunxi
<warpme>
so building uboot with CONFIG_SPL_IMAGE_TYPE_SUNXI_TOC0=y and use fel to uplad then boot will not help?
<apritzel>
no, sunxi-fel would reject the image anyway, it requires egon
<Jookia>
apritzel: sunxi-fel can't be used to handle TOC0?
<Jookia>
secure boot on the t113 is on my list of things to do
<apritzel>
it would not help anyway, since eGON vs TOC0 is just a BootROM requirement, for FEL booting we dissect the image anyway, and upload the separate components
<Jookia>
doesn't the boot rom do FEL? so if you send it a TOC0 over FEL it would boot wouldn't it?
<apritzel>
I have some patches to let sunxi-fel dissect a TOC0 image, but it's just convenience, so that you can use the same image file for SD and FEL
<apritzel>
Jookia: the BROM expect eGON or TOC0 on media, so SD card, eMMC, SPI flash. FEL mode is completely separate, there is no image format involved from the BootROM side
<Jookia>
so secure boot disables FEL?
<apritzel>
FEL just offers to upload, download, execute. Where and what is up to the host
<apritzel>
Jookia: somewhat ;-)
<Jookia>
somewhat?
<warpme>
i suspect there must be way to boot secured devices for case when device is bricked and don't have sd card ////
<apritzel>
Jookia: as warpme demonstrated, they enter FEL in non-secure mode, which doesn't give you much
<Jookia>
non-secure mode can't boot u-boot or something like that?
<warpme>
and we are not aware (yet) how to do this....
<apritzel>
non-secure mode prevents switching to AArch64, among other things
<Jookia>
would it prevent access to reading efuses?
<Jookia>
i would assume so
<apritzel>
even if, eventually you won't be able to use Linux, because the GIC is borked, without something having it set up on the secure side
<apritzel>
but:
<apritzel>
there is this "smc" backdoor, so to speak
<apritzel>
if you issue a simple "smc" instruction, it goes to the BROM exception handler, which conveniently returns to FEL, but with the SCR_EL3.NS bit cleared this time
<apritzel>
so you are in secure state now, and can run things
<apritzel>
but I don't know if this still works if you have burned an actual ROTPK hash, which all of the boxes we have seen so far have NOT
<warpme>
apritzel "issue a simple "smc" instruction" - in sunxi-fel ?
<apritzel>
so "secure boot" is somewhat pointless, since you just need a TOC0 image signed with *any* key
<apritzel>
warpme: well, on the device, so sunxi-fel uploads that instruction and a "ret", then triggers the execution on the device
<warpme>
i'm a bit lost here: only way for me to "speak" to device is sunxi-fel cmd line....
<apritzel>
warpme: the FEL protocol works, you just cannot run all code on the device, or access secure memory (which I think the H616 does not actually have)
<apritzel>
so in your case I guess the SPL gets uploaded, and the first instructions (which are AArch32) get executed, but then it hangs when it want to access a secure register
<apritzel>
some even contain some annotated disassembly
<Jookia>
hmm, no rom for the t113
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
<apritzel>
Jookia: but you should be able to dump it easily, just read the first 64K of physical memory?
<Jookia>
hmm, i'll try some dumping when its time
<Jookia>
i vaguely hope allwinner has disabled loading unauthenticated code over FEL on the t113. but...
<apritzel>
on devices with the secure fuse burnt, or on all devices?
<apritzel>
in general: if you want to use bullet-proof boot checking, go shop somewhere else
<apritzel>
bauen1_ once found a BROM (stack overflow?) bug in the H6 that would allow loading any code even on properly secured devices (with a ROTPK hash set)
<Jookia>
on devices with the fuses burned/etc
<Jookia>
in this case i'm not looking for bullet-proof boot checking, i'm just more interested in slowing down people
<Jookia>
it might be worth documenting the secure boot process too
<apritzel>
yeah, I was thinking about creating a wiki page named "Secure boot"
<apritzel>
I think the facts are already in the wiki, but sprinkled and well hidden on several pages
<Jookia>
yeah i mean a more step by step guide of 'how to secure boot on the t113'
<Jookia>
i also found something vaguely interesting: the t113 supports egon images > 32K
<apritzel>
most "newer" SoCs do, actually, starting with the H6, I think
<apritzel>
I think TOC0 never really had this limitation, I dimly remember people loading larger TOC0 images on the A64
<Jookia>
the only thing i can think of is clocking, maybe you need to enable the dpss clock for DE0
<Jookia>
or gating
<Jookia>
it is weird to get random data though...
<parthiban>
I have the tcon_top configured and also the driver is probed. Values in the tcon_top is fine. This means the bus and mod clock of dpss is enabled IMO
<Jookia>
i'm going to go afk for a while, good luck
linkmauve has left #linux-sunxi [Error from remote client]
linkmauve has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
parthiban has quit [Quit: Leaving]
aggi has quit [Quit: backup time]
mripard has quit [Quit: WeeChat 4.4.2]
<ity>
Hello, have there been any updates on obtaining electrics info needed to make a PCB for (such as pinouts) the A523 ? We remember someone emailing Allwinner about it but might as well ask :)
<smaeul>
apritzel/warpme: can you access eMMC from non-secure FEL? if so, you could bootstrap by using FEL to run a program that writes a TOC0 to eMMC
apritzel has joined #linux-sunxi
<smaeul>
I've tested the mkimage TOC0 code on H616, so if the ROTPK hash is blank, you'll be able to run U-Boot SPL that way (or some arbitrary test program wrapped in a TOC0)
<smaeul>
IIRC we determined that the smc hack didn't work on H616, but that was a couple of years ago
<smaeul>
parthiban: If you are struggling to get a non-blank screen, I would suggest working your way backward from the physical interface step by step
<smaeul>
both the TCON and the mixers have built-in color or test pattern generators
<smaeul>
there's also LCD_LVDS_DEBUG_MODE in the LVDS PHY
<apritzel>
smaeul: ah, hi, thanks for chiming in!
<apritzel>
smaeul: the problem with the Tanix TX1 is that it has no SD card :-(, so FEL is the only easy way in
<smaeul>
but it does have eMMC?
<smaeul>
so if there's no way to go from FEL -> secure, the only way to get secure mode is to write a valid TOC0 to some boot device
<apritzel>
yes, that's the other way, I guess, but if first requires to root the Android
<smaeul>
why not drive the eMMC from FEL?
<apritzel>
well, even xfel doesn't support this, right?
<theslowcoder>
Haha, I'm sort of having the same issue. sunxi-fel can boot spl+uboot from RAM. Once in uboot, you can do a lot more
<smaeul>
I don't know, I would guess not
bauen1 has joined #linux-sunxi
<apritzel>
so maybe a 32-bit U-Boot build would work, but I don't even know how far you come
<theslowcoder>
Neither sunxi-fel nor xfel can read/write to eMMC or SD-card
<apritzel>
writing CNTFRQ_EL0 for instance would fail, I think
<theslowcoder>
Does anyone know if recent (2024+) uboot supports USB gadget on sunxi? Having issues on a T113..
<apritzel>
theslowcoder: oh dear, sad story, you need some config hacks, but it should work, I think?
<apritzel>
iscle: did you get anywhere with your MMC sunxi-fel code?
<theslowcoder>
apritzel: Any idea where I could find a config I could reference? Having issues figuring out which drivers should be compiled in. MUSB, DWC2, DWC2-new, etc
<theslowcoder>
apritzel: Found the Olimex A20 defconfig, but my uboot wont even link with just CONFIG_USB_MUSB_GADGET enabled (like the A20 config)
<apritzel>
for reasons you need both MUSB and EHCI/OHCI, I'd copy from the OrangePi Zero3
<apritzel>
there were patches on the list to improve the situation, but I think they were stuck, because of some rework
<apritzel>
(changes elsewhere, which required adapting the patch)
<apritzel>
smaeul: btw: I see the same secure FEL problem with my secure A133 tablet: the SMC actually returns, but is still in non-secure state :-(
<apritzel>
although the BROM suggests that it should work: unless r0 has some specific value, it should return right away, with .NS cleared
<theslowcoder>
apritzel: Thanks for the hints. At least it builds now. Complains about "Controller uninitialized" though. I'll dig into that one tomorrow.
<MasterR3C0RD>
theslowcoder: I had trouble getting gadgets working too; make sure you have Driver Model disabled for both USB and Gadgets. MUSB is incompatible with DM at the moment
<MasterR3C0RD>
(believe these would be CONFIG_DM_USB and CONFIG_DM_USB_GADGET, but I'd have to double check
<MasterR3C0RD>
Also for whatever reason it seems like you need the Ethernet gadget enabled. Really weird dependency, but couldn't figure out how to get it working otherwise
tokyovigilante has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
ftg has joined #linux-sunxi
tokyovigilante has joined #linux-sunxi
<Jookia>
theslowcoder: you might need a patch for gadget to work on the T113
<Jookia>
though it's been outdated a bit, I think I fixed the code in a merge on my branch
<apritzel>
Jookia: since you are here ;-) Can someone please look at this seriously and fix it for good? I think I commented on the latest mainline patch, and pointed out this it's broken, due to reworked code elsewhere.
<Jookia>
apritzel: i didn't understand your email reply to it and i'm a little shy at this point about sending off more patches to u-boot
<Jookia>
i also will have to go back and port the uart to DM for DM SPL in u-boot too
<apritzel>
why exactly?
<Jookia>
DM SPL is required for secure u-boot
<Jookia>
cryptographically signed FITs
<apritzel>
regarding DM-MUSB> I think there was some other email, maybe in another thread, that pointed out the conflict. I think a solution was not complicated, but not trivial either
<Jookia>
i don't understand what's wrong with my solution tbh
<Jookia>
this is what other drivers do i think
<apritzel>
well, did you try it on mainline?
<Jookia>
yes, my branch tracks mainline
<Jookia>
i can't actually run mainline on my board
<Jookia>
well i could, it would just be not useful since i would have to go back to playing with SD cards
<Jookia>
i'm fairly sure none of my patches make it act different to mainline in this case aside from this one
<apritzel>
I had a different impression back then, I think in my testing it broke something, or I had to unbind the Ethernet gadget first
<Jookia>
i think you're not using DM though?
<apritzel>
IIRC it's working fine for me without DM, and it's not working the same with DM, at least not with that patch
<Jookia>
yes, the patch is to make it work with DM
<Jookia>
it will work fine without DM
<apritzel>
did you enable the Ethernet gadget in your config?
<Jookia>
no. what would that do?
<apritzel>
that's enabled by default in most defconfigs, and makes using other gadgets problematic
<Jookia>
that sounds like a separate issue to the DM support
<apritzel>
because it grabs the MUSB, and you need to unbind that first
<apritzel>
yes, and that's what I meant with needs to be fixed first
<Jookia>
why does it need to be fixed first if it's a separate issue?
<apritzel>
because it would create a regression
<apritzel>
at the moment things work, without DM, but that's not of a particular interest to users
<Jookia>
wouldn't that regression already exist on other boards/platforms that use DM?
<Jookia>
this patch wouldn't break non-DM support
<apritzel>
outside of sunxi, you mean?
<Jookia>
yes
<Jookia>
the new code is gated behind CONFIG_IS_ENABLED(DM_USB_GADGET)
<apritzel>
well, this is maybe the misunderstanding: we should not support both
<apritzel>
ditching non-DM is the right way, and we should do it
<apritzel>
but we need to maintain feature parity
<apritzel>
so if a normal config has Ethernet and UMS working without issues (with DM), I am more than happy to apply this
<Jookia>
did you want the non-DM code removed?
<apritzel>
yes
<apritzel>
those DM vs non-DM is not a board choice
<Jookia>
wouldn't that break existing configs?
<Jookia>
ethernet and UMS don't work without issues on gadget for me, but i don't know if that's a sunxi thing or DM thing
<apritzel>
it's a platform decision, and non-DM support is just here to give time for the transition, and to not break things
<Jookia>
usb gadget support has always been poor for me
<apritzel>
well, maybe, but it works, at least in my testing
<apritzel>
and I guess some people use it this way
<apritzel>
just to clear: a user (or you) should not select/de-select DM vs. non-DM
<Jookia>
ah
<apritzel>
that's something for Kconfig, to select purely based on the state of the transition
<apritzel>
so eventually we should convert any drivers not supporting DM over. I think MUSB is one of the last ones
<apritzel>
we cannot ditch non-DM completely, because we need it for SPLs
<Jookia>
i'm planning to move to a SPL DM for secure boot purposes
<Jookia>
i don't think space is a concern on the t113
<apritzel>
and I am not a big fan of enabling DM-SPL, as this would break older boards, and having to support both sounds troublesome
<apritzel>
as in: now some SoCs use DM, others don't: that just increases the test matrix
<apritzel>
and I am pretty sure we cannot enable DM-SPL on older board, due to lack of SRAM
<Jookia>
well there's not much other choice if you want secure boot
<apritzel>
i.MX ;-)
<apritzel>
given that secure boot is not really secure on most Allwinner chips ...
<Jookia>
so it's the policy that secure boot will not be supported in mainline u-boot?
<apritzel>
that's a separate discussion, we should focus on the DM-MUSB here, really
<apritzel>
there is no such policy, I just don't see the benefits, given you are the first one to really ask for it
<apritzel>
I had several people in the last years investigating secure boot on AW chips: they all gave up eventually, because the hardware is lacking
<apritzel>
we know for sure of a BROM bug in the H6 BROM, and then there is the FEL question (even if it's non-secure)
<Jookia>
is the BROM bug documented somewhere
<MasterR3C0RD>
It might have been mentioned earlier today if I'm remembering correctly; buffer overflow in BROM allows for secure boot bypass?
<apritzel>
yeah, this was years ago, here in the channel, but on freenode
<Jookia>
it's hard to know if the bug still exists if there's no write-up/report of it
<Jookia>
or a poc to try
<apritzel>
pretty sure it's still in the Boot*ROM* ;-)
<Jookia>
of newer boards?
<Jookia>
uh, chips
<apritzel>
yes, it's in the SoCs itself, and this was sufficiently late in the H6 life cycle, so I doubt they fixed it
<Jookia>
i mean like the T3 and newer chips
<apritzel>
I even doubt they know about it or care, tbh
<Jookia>
T113*
<apritzel>
I don't know, it just doesn't give me high confidence
<Jookia>
did this get a write-up anywhere? or testing to confirm it's a real bug?
<MasterR3C0RD>
We can't know without getting into the weeds, but IMO it calls into question the security of the implementation generally; even if they did fix it, from at least my experience over the past month getting into these chips, Allwinner code is... not very good or well tested
<Jookia>
it's not a very convincing argument to say it's broken or insecure without showing that it's broken or insecure, right now the only issue i see is FEL
<Jookia>
so if i discover that the FEL bug is fixed, the secure boot looks actually secure
<Jookia>
apritzel: looks like that branch also bumps the SPL size to 64K
<Jookia>
FWIW i don't take secure boot in general very seriously, but yeah allwinner does not give me any confidence if they decide you can just run code without authentication at all
<MasterR3C0RD>
>This PoC exploits the sbrom trusting the length in the toc0 before verifying the signature, allowing the stack to be overwritten.
<apritzel>
Jookia: we try to put only good and validated info in the wiki, there is already enough nonsense out there. So it should be clear or validated.
<Jookia>
apritzel: i have no way of knowing or verifying the max SPL size per chip
<Jookia>
the existing description says 32KiB without validation
<Jookia>
maybe it's worth removing that
<apritzel>
my *hunch* is that it affects any NCAT SoCs, but then there is little rhyme or reason in AW's product policy
<Jookia>
should i just write that the T113 supports a 48K SPL?
<apritzel>
I know for sure about H6 and H616
<Jookia>
so... H6, H616 and T113 support SPL > 100K?
<apritzel>
I have some script/code somewhere to artificially blow up the SPL, just for testing this
<apritzel>
so you could try to find the limit yourself, I guess it's related to the SRAM size listed in soc_info.c
<apritzel>
I think the AW BSP uses a 64K boot0 on H616 boards?
<apritzel>
so it's a least that there
<MasterR3C0RD>
I can confirm boot0 is 64K on the A133 at least
<Jookia>
i'll just put 'H6 and newer chips may support larger sizes'
<apritzel>
yes, that's at least better than listing just 32k
<Jookia>
i really don't want to turn what was intended as a wiki hint to try larger SPLs on newer boards in to a documentation of allwinner SPL sizes
<apritzel>
well, I think that's exactly what we need ;-)
<apritzel>
(a table with known limitations)
<Jookia>
someone in a better position to make that list than me should start it then
<Jookia>
i only have one allwinner chip
<apritzel>
you could start with one row ;-)
<apritzel>
I am happy to add to this
<Jookia>
if you start the table and explain how to check things i'll add to it
<Jookia>
for now i've just made that little edit
* apritzel
now needs to turn his attention to his A523 DT binding patches, they need to be made Krzysztof-proof ;-)
<Jookia>
i'll do a re-documented spin of the TCON workaround patch next week
<apritzel>
thanks!
<Jookia>
i'm not sure fixing it properly is worth the effort at this point for a few reasons, and i'll explain those in the new email
<Jookia>
(reason one being that i can't test it)
<MasterR3C0RD>
I should get back to A133 land myself, I believe I got crypto working on Wednesday (appears to match H616 perfectly!) so next step is SPI. Also need to get the MMC NO_REPARENT fixes submitted to stable
<Jookia>
nice!
<Jookia>
i have a slow plan on cleaning up my variable clocking + variable audio clocking patches
<MasterR3C0RD>
TrimUI console should hopefully arrive sometime next week, so I'll get UART on that and look at seeing what LEDC and ADC will look like