<parthiban>
apritzel: I have tested with A133 based development board. What do you mean by integrate into H6 platform?
Robot_ has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Danct12 has quit [Ping timeout: 480 seconds]
Danct12 has joined #linux-sunxi
Danct12 has quit [Quit: WeeChat 4.6.3]
Danct12 has joined #linux-sunxi
hexdump01 has quit []
hexdump0815 has joined #linux-sunxi
radxanaoki has joined #linux-sunxi
<hexdump0815>
just fyi for anyone in the eu looking for a cheap allwinner a523 tablet to play around with for mainlining: on ali the teclast p26t is going very cheap right now (just a bit above 40 euros with regular coupons) shipped from spain - perfect hacking toy maybe :)
radxanaoki has quit []
funderscore has quit [Ping timeout: 480 seconds]
luka177 has joined #linux-sunxi
<luka177>
Hi, i was checking tv encoder on t113 and seems like its fairly different from whats currently supported, did anyone work on that? any experimental patches? I did try to get it to the point of plug detection but so far it claims unconnected
bauen1 has quit [Ping timeout: 480 seconds]
bauen1 has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
parthiban: I meant that A133 and H6 are very similar (you probably copied many files?), so we were working based on the idea to use plat/allwinner/h6, and just special case the A133
<apritzel>
(plat/allwinner/sun50i_h6, I mean)
<apritzel>
I have quite some refactoring of the PMIC code lying around, we need that anyway because H6 needs I2C, too, so that part won't be different anyway
<parthiban>
apritzel: Yes copied and modified to accommodate PMIC related. And also A133 is not using per cluster registers.
<parthiban>
Refactor in a way to handle multiple SoC into one directory or something and controlled with Kconfig like?
<apritzel>
we already handle A64 and H5 in one directory, because they are very close
<apritzel>
the big point is that the memory map is basically the same
<apritzel>
the refactor is about the PMIC code detecting I2C vs RSB and the PMIC model at runtime, like the H616 does already
<parthiban>
Yes, but A133's SRAM didn't work and H6's one magically works, which I still don't know how.
<parthiban>
"PMIC model at runtime" -> by reading the dt compatible?
<apritzel>
yes, we do this for H616 already
<apritzel>
regarding the per cluster registers: we have an oracle function, so just use read_soc_id() in there solves that problem
<parthiban>
I also used fdt_node_offset_by_compatible in the A133. But your point is valid to avoid duplicate code.
<parthiban>
Clubbing H6 and A133 is ok, but I only have A133 based devices with me to test it.
<apritzel>
that's fine, I can test against H6
<apritzel>
parthiban: I will try to post my H6 PMIC refactoring in the next days, maybe you can then build on that
<parthiban>
Sure. I will wait. To add, A133 changes are very simple to accommodate.
<parthiban>
Quick question about the SRAM, A1 region is 16KB and NOBITS section couldn't fit there. Tried using DRAM, but that didn't work as well. What am I missing?
notfunderscore has joined #linux-sunxi
<apritzel>
nothing, it's a nasty problem. I think we "accidentally" used part of SRAM C (as the SPL does), but that won't fly anymore as soon as we get graphics support
<parthiban>
"Borrow VE 112K, DE 20K, supports Byte operation, clock source is AHB1"-> Understood. We are using VE's SRAM part. But display engine should be no problem right?
<apritzel>
I need to think about that, and see if we can save some memory, or move the NOBITS region somewhere else
<apritzel>
well, people will want to use the VE at some point, so we have to find a solution. And I am not even sure that the VE uses exactly the *first* 112K
jernej- has joined #linux-sunxi
<parthiban>
Looking ar current dts, "de2_sram" uses the base i.e VE's one. Not sure 20K if enough for DE. I can test that change as I have the working display pipeline.
<parthiban>
Btw, I have "A133 User Manual(Revision 2.1)" from Allwinner under NDA with watermark all around. Not sure if there is a way to open it for public view.
<parthiban>
"Revision 2.1 December 4, 2024"
jernej has quit [Ping timeout: 480 seconds]
<apritzel>
the 20K are not for the framebuffer, but just for some extra memory the DE need, don't know exactly what. Maybe something with tables for colour conversion or so?
parthi has joined #linux-sunxi
parthiban has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<apritzel>
parthi: are there any interesting differences or additions compared to the v1.1 version of the manual?
parthi has quit []
parthiban has joined #linux-sunxi
ungeskriptet has joined #linux-sunxi
parthiban has quit [Remote host closed the connection]
parthiban has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
parthiban has quit []
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit [Remote host closed the connection]
<iscle>
apritzel: I'm designing a board similar to the SDWire (https://shop.3mdeb.com/shop/open-source-hardware/sdwire/) but instead of using a card reader IC, I'm using a CH32V305 MCU which has high-speed USB2 as well as UART and SDIO peripherals. The plan is to have it controlled by the computer and be able to write the sd card image automatically and then boot from it and switch to uart mode automatically (using the MCU's own UART
<iscle>
I'm doing it on EasyEDA with LCSC components so that the entire assembly can be done by JLCPCB, in case it works and you're interested I think it will be quite cheap (like 30 USD per 2-3 boards), my plan is to do something easy that can be ordered to them directly by those interested
<iscle>
dlan: yeah, I had seen those. The main difference is that those don't allow you to write the SD card without removing it from the device itself, and also require a separate UART to USB converter. My solution unifies all that. The CH32V003, for example, does not have a high-speed USB PHY
<iscle>
Fun fact, I ordered a CH32V305 dev board 2 years ago, never used it. Now that I need it, I can't find it...
<apritzel>
iscle: yes, some cheap SDwire/SD USB mux would be very nice. It makes little sense to get 100$ SD muxer for a 30$ board, at least for hobbyists
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
<iscle>
apritzel: indeed! the sdwire board is too expensive for what it does. my calculations for the one I'm building are around 30USD with much more features. Mainly being able to flash the image to the SD card directly, acting as USB-SERIAL and also I'm planning to add a couple extra pins to reset the MCU automatically and select boot mode (or FEL)
<iscle>
30USD for 2-3 boards, the BOM is not too much, most of it is for the board production itself
<apritzel>
iscle: so your board would be able to switch/mux PF2 and PF4 to the MCU's UART pins, and expose that via USB to the test host?
<iscle>
The board will have the PF2 and PF4 pins connected to the MCU's SDIO peripheral pins, as well as the MCU's UART peripheral pins. The UART peripheral pins will be disabled (high impedance) while the board is in "SD Card" mode, and then when it switches to UART mode (after the firmware has been loaded), the UART peripheral will be switched on, and SDIO switched off
<apritzel>
so the MCU has both an SDIO *peripheral* port, as well as an SD card host port?
<iscle>
apritzel: The SDIO interface does not differentiate between host/device like USB does, it's just depending on how you wire it up. It can work both ways. However, in this case, the board has a real SD card muxed between the MCU (to flash it via USB) and the SUNXI SOC (for runtime). At the same time, the PF2 and PF4 pins are always connected to the MCU's UART pins
paulk has quit [Ping timeout: 480 seconds]
<iscle>
When the SUNXI SOC is reading the SD card there's little we can do as UART will be disabled, but after it finishes we can start reading UART directly like you are doing now with A733, but automated via software
<apritzel>
ah, so you still have some mux IC, to switch the SD card around? So the novelty here is to add the UART muxing?
<iscle>
There are multiple solutions that could also be implemented with the board like: 1. If SD Card is in 1-bit mode, we can use other pins to bit-bang uart and always get output. 2. Have the UART peripheral always listening, but only print characters after a real start sequence is detected (something we decide on, which means our payload is ready)
<iscle>
apritzel: yes, we still have to mux the sd card around. but we can have uart directly without having to fiddle with external usb converters, exactly
<iscle>
but since everything will be defined by software, I'm sure we can still improve it, like triggering the reset pin after the sd card is ready
<iscle>
the MCU could theoretically also emulate the SD card, and for example read directly from an image in the computer without having to transfer it, but it would introduce a lot of latency and would not reach very high speeds
<iscle>
I need to find the development board I had laying around, I can test this without any external hardware with what I have
<apritzel>
iscle: yeah, I heard years ago that this is actually tricky, due to strict timing demands of the MMC protocol, which makes it hard to emulate/bitbang
wingrime-ww has joined #linux-sunxi
<iscle>
apritzel: indeed. In this scenario we wouldn't have to bitbang anything, as the MCU has all the required hardware peripherals, but the delay between the computer reading the file and transfering it all the way could be an issue
<iscle>
still, I will give it a go when I find the dev board
ftg has quit [Read error: Connection reset by peer]
<apritzel>
for the switch between SD/serial: I wonder if you could snoop the SDC0_CLK pin (which is also UART TX), to detect SoC SD activity, and switch to serial (after a small timeout), when CLK stops to toggle?
wingrime1 has quit [Ping timeout: 480 seconds]
<iscle>
apritzel: If I'm not mistaken, the UART pull up is done by the transmitter, right? In that case, we could always be listening to UART until something meaningful is seen at the expected baudrate. It should not affect SD card data transfers
<apritzel>
yes, or that. Don't know the MCU's UART, but I think you would get frame errors for garbage on the UART pin?
<iscle>
I'd have to try it but I think that we can catch them indeed! file:///home/iscle/Downloads/CH32FV2x_V3xRM.PDF