Hi @zoenggit,
Thank you very much, is very interesting about T113. I need to deep dive into this variant.
Hi @zoenggit,
Thank you very much, is very interesting about T113. I need to deep dive into this variant.
Hi @zoenggit
According this discussion issue in TinyUSB. User @robots created repo for Allwinner T113 chip. Is ARM core but peripherals looks absolutely the same as D1H RISC-V.
Is repo is bare metal experiments with T113 and FreeRTOS also contains Doom. So author decide to deactivate USB EHCI and use only OHCI. Also for USB descriptors used memory section with direct mapping.
I try to do the same:
rt-thread/bsp/allwinner/d1s_d1h/packages/TinyUSB/rt-thread/bsp/sunxi_D1/drv_tinyusb.c
volatile uint32_t *portsc = (uint32_t * ) (EHCI1_BASE + 0x054); //E_PORTSC
*portsc |= BV(13);
static void gtd_init(ohci_gtd_t* p_td, uint8_t* data_ptr, uint16_t total_bytes)
{
...
rt_hw_cpu_dcache_clean_and_invalidate_local(data_ptr, total_bytes);
}
MEMORY
{
SRAM : ORIGIN = 0x40300000, LENGTH = 4M
DMA : ORIGIN = 0x40700000, LENGTH = 16M
HEAP : ORIGIN = 0x41700000, LENGTH = 16M
}
SECTIONS
{
.usb :
{
. = ALIGN(4);
} > DMA
Init MMU with different sections in rt-thread/bsp/allwinner/d1s_d1h/board/board.c:
struct mem_desc platform_mem_desc[] = {
{KERNEL_VADDR_START, 0x40700000 - 1, (rt_size_t)ARCH_MAP_FAILED, NORMAL_MEM}, //KERNEL
{0x1000, 0x3ffff000 - 1, (rt_size_t)ARCH_MAP_FAILED, DEVICE_MEM}, //IO
{0x40700000, 0x40700000 + 0x1000000 - 1, (rt_size_t)ARCH_MAP_FAILED, DEVICE_MEM}, //DMA
{0x41700000, 0x40700000 + 0x4000000 - 1, (rt_size_t)ARCH_MAP_FAILED, NORMAL_MEM}, //HEAP + HW PAGE
};
rt-thread/bsp/allwinner/d1s_d1h/packages/TinyUSB/src/portable/ohci/ohci.c
CFG_TUSB_MEM_SECTION TU_ATTR_ALIGNED(256) static ohci_data_t ohci_data;
Run board.
Looks like USB device start to do something new, but all data transfers did not produce any results, all of it STALLED or FAULT:
[0:0] Open EP0 with Size = 8
Get 8 byte of Device Descriptor
[0:0] Get Descriptor: 80 06 00 01 00 00 08 00
on EP 00 with 8 bytes
on EP 80 with 8 bytes
[0:0] Control STALLED, xferred_bytes = 8
[0:0] Get Descriptor: 80 06 00 03 D0 03 08 00
on EP 00 with 8 bytes
on EP 80 with 8 bytes
[0:0] Control STALLED, xferred_bytes = 8
[0:0] Get Descriptor: 80 06 00 02 18 08 08 00
on EP 00 with 8 bytes
on EP 80 with 8 bytes
[0:0] Control STALLED, xferred_bytes = 8
[0:0] Get Descriptor: 80 06 00 02 58 0C 08 00
on EP 00 with 8 bytes
on EP 00 with 4294964828 bytes
Set Address = 1
[0:0] Set Address: 00 05 01 00 00 00 00 00
on EP 00 with 0 bytes
[0:0] Control STALLED, xferred_bytes = 0
[0:0] Set Address: 00 05 01 02 00 00 00 00
on EP 00 with 0 bytes
on EP 00 with 2088 bytes
[0:0] Get Descriptor: 80 06 00 01 00 00 12 00
on EP 00 with 8 bytes
[0:1] Control FAILED, xferred_bytes = 8
So did not lead to success with USB again.
Need to dive deeper into EHCI/OHCI, maybe some one can advice please ?
Finnaly !
When press the keys “Hello !” on the USB keyboard, I see it In RTT console:
HID device address = 2, instance = 0 is mounted
HID Interface Protocol = None
HID has 4 reports
msh />
H
e
l
l
o
!
How did I manage to do this ? Surprisingly, but with the help of:
Is hand-made ham radio transceivers from one guru guy
Thanks @zoenggit for the tip about T113. Based on this I found it.
This project supports many chips: ARM, RISC-V, ATMEGA, and many peripheries. And is support Allwinner F133 aka D1s. On this radio Allwinner USB works perfectly. Why ? Because it just has a proper implementation of EHCI/OHCI stack and that is.
Ham radio uses hftrx_tinyusb fork of TinyUSB with several changes from guru. I just little changed it for support RT-Thread. Figure out that it is necessary to configure MMU and linker sections for USB to work from SD card.
The next step is routing the keyboard to the console pipe and LCD frame-buffer and we will have a fully portable RT-Thread device !
Images in repo @jusentari could I kindly ask you to try it in uConsole if you have time please ?
Also @jusentari about lcd_dclk_freq change from 62 to 67 to uConsole. I still worry about LCD affects.
I sent email to display supplier Shenzhen tianxianwei Technologyit about it is safe to change 62 to 67, and they answered:
lcd_dclk_freq(像素时钟)=67Mhz,对应的刷新率为65Hz,
大批量做货可能会掉数据出现黑屏、花屏、闪屏;
建议按我们的刷新率=60Hz来调试。
Believe it means:
lcd_dclk_freq (pixel clock) = 67Mhz, the corresponding refresh rate is 65Hz.
When producing large quantities of devices, data may be dropped, black screens, blurry screens, and flickering screens appear;
it is recommended to debug according to our refresh rate = 60Hz.
Looks like they did not say LCD could be damaged but recommended not changing the frequency.
Also, they sent the recommended parameters:
Resolution:720x1280
External system porch setting: VS=2 ,VBP=16 ,VFP=8 , HS=20 ,HBP=20 ,HFP=30
Frame rate:60.10HZ
Pixel Clk:61.90Mhz
MIPI CLK:372Mbps(MIPI通道速率)
dsi.PLL_CLOCK:186Mbps(MTK平台速率)
Power:VCI=2.8V, IOVCC=1.8V RESET=1.8V
In Shenzhen answer HBP and VBP are quite different from our ClockworkPi driver:
lcd_hspw = <20>;
lcd_hbp = <40>;
lcd_ht = <790>;
lcd_vspw = <2>;
lcd_vbp = <18>;
lcd_vt = <1306>;
Can’t test it as I didn’t have uConsole.
If you have time maybe you could try these parameters and lcd_dclk_freq = 62Mhz on uConsole please?
Should say I created a true bare-metal library for D1 on ClockworkPi.
No OS, no hidden libs - only minimal low-level stuff. I know you are interested about it.
Is already working with USB.
I need some time to clean up this and figure out about the display and I can present.
Thanks
@ylyamin,
Nice job!! Very cool that ham radio of all things would have the answer here.
I can confirm that the USB driver is working on my uConsole as well! I was able to type with the keyboard and have it show up in the RTT console.
However, I couldn’t get the LCD screen parameters to work. I changed lcd_hbp to 20 & lcd_vbp to 16 in cwu50_config.c and the screen didn’t respond. Interestingly, the console stopped taking input as well (although it still outputted data over UART) unless I built with lcd_hbp = 40.
When lcd_hbp = 40, lcd_vbp = 16, and lcd_dclk_freq = 62, there was a faded outline when using lcd_draw_point, but it definitely didn’t look right.
I’ve been tweaking the settings a bit and I’ve gotten something on the screen at lcd_hbp = 30, lcd_vbp = 8, freq = 62, but I’ll need to mess around with the settings some more to get it right.
I’m thinking I’ll need to dig through the Clockwork code to find the values for the screen back porch to maybe tweak the ht/vt values according to this diagram:
Great job with the USB!!
HI, @jusentari
Thanks for testing the USB in uConsole.
Oh, this LCD work is very mysterious to me. I appreciate your support.
Hi Guys, @jusentari @zoenggit
Just in case you still interesting. I stopped with RTT and continue with bare-metal library for R-01, USB work but LCD is not as usual. R-01 library for small OS