05:28 <gamiee> iscle : doesn't DMA need some for of align / padding?

07:46 <MasterR3C0RD> Hi; I recently bought a Creality Sonic Pad, a "3D printing pad" running Tina Linux on an R818 with pre-installed Klipper. There's a project by someone else that uses the 4.9.119 Allwinner kernel to boot Debian on said device, but I wanted to look at getting something a little newer running. I applied a few of the patchsets linked in the wiki to sunxi-next, and have been working on porting the dev

07:46 <MasterR3C0RD> It looks like there's no support in U-Boot or ATF for the R818/A100 series yet, so I presume I'd need to do a bit of patching there? It also appears that sunxi-tools doesn't recognize the R818's chip ID.

10:15 <Florianclume> iscle: I want to boot something over USB OTG to make a backup of the stock OS first and then try to run another OS on the tablet.

10:15 <Florianclume> I've tried to retrieve data over USB in FEL mode like mentioned in the wiki: https://linux-sunxi.org/Retrieving_device_information#Retrieving_data_over_USB_in_FEL_mode

10:15 <Florianclume> But I have this error: `libusb usb_bulk_send error -7` wich according to the wiki: https://linux-sunxi.org/FEL#Reading_over_USB_fails means that boot1 is not initialized

20:40 <apritzel> MasterR3C0RD: for sunxi-tools there is https://github.com/apritzel/sunxi-tools/commits/a133-wip/

20:40 <apritzel> for U-Boot I once made: https://github.com/apritzel/u-boot/commits/a133-WIP/, which I guess is quite dated by now, but should give you some ideas

20:42 <apritzel> Florianclume: those instructions in the Wiki are very old, and Allwinner changed their firmware layout quite significantly since then, so there is no boot1 anymore

20:43 <apritzel> Florianclume: unfortunately the B300 is very unsupported, I don't think we even have a "user manual" (aka datasheet)

20:44 <apritzel> so any kind of support outside of AW's rotten BSP is quite far away, I'd say

20:46 <apritzel> it's an interesting challenge to figure things out, and we have some tools and experience from other SoCs to piece things together, but it requires some experience and involves some tedious work

20:48 <apritzel> quad A7 from that time frame suggests some similarity to say the V833/V851/V5 and friends, but there is probably still a lot of unknowns

20:49 <MasterR3C0RD> apritzel: Thanks! I was just digging around some of the released SPL code trying to find the offsets needed for sunxi-tools; I did find what appears to be the sid sections map in the Linux sources (appears to be similar to the t7 map)

20:49 <apritzel> Florianclume: do you get that thing into FEL mode at all? Some hidden FEL button? Boot with fel-sdboot.sunxi dd'ed to an SD card?

20:50 <apritzel> MasterR3C0RD: well, the SID sections are not very important, at least not until very late in the game :-(

20:51 <apritzel> MasterR3C0RD: I think I had *some* success with my A133 with that branch, but the secure boot on my tablet spoiled quite a lot, that's why I didn't send a PR

20:53 <MasterR3C0RD> I don't think my device has secure boot, but I suppose I'll find out once I get u-boot sent over to the device. No SD card on this device, so USBBoot it is

20:54 <apritzel> well, problem is we don't have DRAM init code for the A100, so you won't get very far :-(

20:55 <apritzel> a trick I typically pull is trying to re-use some of the BSP DRAM init code, for instance by uploading a boot0.bin, extracted from some vendor image

20:55 <apritzel> though this requires some hacking to get it back to FEL, after the DRAM init

20:56 <apritzel> sometimes it works to just put the sole boot0.bin on an SD card, with nothing else on it: some boot0's then give up and drop to FEL mode, allowing you to upload U-Boot proper

20:56 <apritzel> but that depends on the particular boot0

20:57 <apritzel> you can use https://github.com/apritzel/sunxi-fw/commits/main/ to extract boot0 from an image

20:57 <MasterR3C0RD> Does it help that there's a BSP source drop for my device? https://github.com/CrealityTech/sonic_pad_os

21:00 <MasterR3C0RD> I presume I should be able to find the DRAM init code somewhere in there; it seems like there's arisc source code

21:00 <apritzel> MasterR3C0RD: depends on whether there is a libdram in there or not. The only DRAM *source* we have ever seen is very old, I think, but some times libdram.a files with debug symbols surface

21:01 <apritzel> they can be shoehorned into something bootable, with a lot of squinting, but this remains a hack, since we cannot link a proprietary binary into GPL U-Boot

21:06 <Florianclume> apritzel: Yes, I did enter FEL mode on my tablet by sending '2' on the UART while booting... but then I don't know what to do

21:08 <apritzel> Florianclume: I am not sure this UART triggered thing is proper FEL mode, but in any case try running "sunxi-fel ver" on your host, and see if it detects anything

21:09 <apritzel> the SoC ID reported would be some start, that sometimes helps to put that SoC into the vicinity of other SoCs, to check which generation it is

21:12 <apritzel> MasterR3C0RD: I don't feel like cloning this whole crap, but see some mentioning of init_DRAM() in lichee/brandy-2.0/spl/fes/main/fes1_main.c

21:12 <Florianclume> apritzel: lsusb shows me `Allwinner Technology sunxi SoC OTG connector in FEL/flashing mode`, `sunxi-fel version` returns `Warning: no 'soc_sram_info' data for your SoC (id=1755) AWUSBFEX soc=00001755(unknown) 00000001 ver=0001 44 08 scratchpad=00007e00 00000000 00000000`

21:16 <MasterR3C0RD> apritzel: Seems like it is in fact compiled into `lichee/arisc/ar100s/library/liboem/sun50iw10p1/libar100s.a`. Doesn't seem to be stripped on first glance though

21:21 <apritzel> MasterR3C0RD: that's indeed a close hit, but seems just for the DRAM standby control (put it into self-refresh and such), but I don't see anything initDRAM related in there?

21:22 <apritzel> Florianclume: that's good info, thanks. 1755 is in quite some gap, between the H6 and the V536(?), so there might be dragons :-(

21:23 <apritzel> Florianclume: I think we could wildly guess the parameters for soc_info.c in there, but that still leaves quite some unknown, like all the clocks (hopefully something close to a modern CCU)

21:24 <apritzel> Florianclume: and even in the best case you would find yourself in the same boat as MasterR3C0RD and would be looking for the DRAM init code

21:32 <Florianclume> apritzel: have I gone too _low level_? maybe I could just hack the stock android but i'm afraid of breaking everything

21:33 <Florianclume> I've soldered wires to the tablet but I'm much more afraid of flashing a dodgy TWRP found on GitHub...

21:37 <apritzel> Florianclume: yeah, flashing something is always quite a risk, I would only do that at a last resort

21:38 <apritzel> some of the devices are shockingly open, as in: give you a (root) shell on the debug UART. Sometimes it's not a root shell, but "su" fixes that

21:42 <Florianclume> sadly, I can't write anything on the UART once it's booted (it is not echoing)

21:42 <Florianclume> `adb` does not give me a root access neither

21:43 <apritzel> Florianclume: do you *see* any messages on the UART?

21:43 <apritzel> because in this case there is this: https://linux-sunxi.org/Eachlink_H6_Mini#Adding_a_serial_port_.28might_void_warranty.3F.29

21:45 <Florianclume> Yes, it is speaking a lot: https://linux-sunxi.org/Bookeen_Notea#Serial_output

21:46 <apritzel> ah yes, just saw that ;-)

21:51 <apritzel> Florianclume: does it go further than that, e.g. show a prompt? If not, maybe try 1,500,000 bps, some newer BSPs switch to this baudrate at some point

21:54 <Florianclume> apritzel: Nope, after `[ 0.000000] bootconsole [earlycon0] enabled` nothing shows up anymore... :(

21:54 <Florianclume> Oh yes, I could try switching baudrate, but if it was just that, wouldn't there be some weird characters displayed?

21:55 <apritzel> depends on the ratio of the two baudrates

21:55 <apritzel> some combinations don't "make sense at all", so it shows nothing

21:56 <apritzel> MasterR3C0RD: it looks like lichee/brandy-2.0/spl/board/sun50iw10p1/libsun50iw10p1_fes.a contains initDRAM and its requirements

21:57 <Florianclume> apritzel: Okay, I'll try that right now ;)

22:00 <MasterR3C0RD> apritzel: Awesome, I'll take a look at it in R2

22:04 <tokyovigilante> apritzel: regarding the 4x, it's just not used in the audio driver, so doesn't need to be defined in the device-tree bindings

22:04 <tokyovigilante> Good to have correct in the CCU driver though

22:06 <tokyovigilante> Just testing your suggestions for the HS clock definition

22:08 <apritzel> tokyovigilante: "not used in the audio driver" means the audio code never requests a frequency that couldn't be realised with the 2x or 1x as the parent?

22:09 <Florianclume> Well, changing baudrate didn't help :c

22:09 <tokyovigilante> apritzel: that is my (eventual) understanding, yes

22:12 <tokyovigilante> sun4i_codec_get_hw_rate() just has (fractional) multiples of the 22.5792 or 24.576 Mhz 1x clock (ie 44.1Khz audio is 22.5792MHz / 512 etc) and all the other frequencies are integer multiples or fractions, (22.05KHz, 88.2Khz, 176KHz etc, and then 24/48/96/192 KHz for the 24.576 MHz setting)

22:12 <apritzel> Florianclume: too bad! I guess there is no chance you could influence the command line? But maybe you can somehow see what it is?

22:13 <tokyovigilante> Which must be true for the other audio codecs in the sun4i driver, because the 4x clock was not in the devicetree binding previously

22:13 <tokyovigilante> (and makes sense given the commonly used audio frequencies being based on either 44.1 or 48 Khz)

22:13 <apritzel> tokyovigilante: yeah, that's my understanding as well, but we try to not make too many assumptions in the clock driver, instead just to try to copy what the manual describes

22:14 <apritzel> I mean the DT isn't just for Linux, and who know, in the future there might be some other use case?

22:14 <tokyovigilante> sure, so will fix up the clock driver as per the manual. My personal feeling is less is more with the DT binding changes, they seem to be the most controversial :)

22:15 <tokyovigilante> sun4i_codec_get_mod_freq() makes it even more explicit

22:17 <apritzel> yes, but that's the *current* *Linux* implementation

22:17 <apritzel> what binding changes are you talking about? You just touch the clock driver, right?

22:19 <tokyovigilante> correct, but the vendor H616 DTS codec node defined the 4x clock, so I was obliged to add a binding doc patch for it. But subsequent testing has shown that 4x clock is not used in the codec driver, so doesn't acutally need to be in the DTS, and therefore doesn't need a binding update.

22:21 <tokyovigilante> There is a binding change required because the H616 is output-only, and has a single line-out route defined, and have some feedback from Krzysztof on that

22:22 <tokyovigilante> *referenced in the DTSI, not defined

22:22 <apritzel> tokyovigilante: ah, I see now, it's not mentioned in the binding header, only in the private one

22:23 <apritzel> though this is not a big problem, since the number is assigned anyway, and does not conflict or anything

22:24 <tokyovigilante> My thinking it that its better to basically not touch anything I don't have to :)

22:24 <apritzel> and I think that clock is internally referenced only anyways, as a parent for the various audio clocks?

22:24 <apritzel> tokyovigilante: good idea ;-)

22:24 <tokyovigilante> yeah that's correct, the 1x is the important one which the audio freqs are derived from

22:25 <tokyovigilante> always good when the patch gets smaller as it is revised

22:25 <apritzel> oh yes, love those ;-)

22:25 <apritzel> regardless, I think it's mostly a question of whether you use 2, 4, 8 as dividers or 1, 2, 4, right?

22:27 <tokyovigilante> correct, so just building a test with 1/2/4 now, which should work with the extra HS divider as suggested

22:33 <Florianclume> apritzel: I don't know, I am lost, I don't have any clue on what to try

23:44 <MasterR3C0RD> At the moment, it appears the DRAM code is closer to that of the h6, at least from a glance. SUNXI_CCM_BASE appears to be the same (0x03001000), and `mctl_sys_init` seems to be fairly close

23:45 <iscle> apritzel: can you provide some link to a a133 or a100 boot0 image? I want to throw it in ghidra

23:47 <MasterR3C0RD> iscle: https://github.com/CrealityTech/sonic_pad_os/blob/main/lichee/brandy-2.0/spl/board/sun50iw10p1/libsun50iw10p1_fes.a has the DRAM init code, alongside a few other things. There's source for other parts of the SPL there as well, though some of the structs are wrong (`dram_para_t` is definitely incorrect)

23:47 <MasterR3C0RD> It says .a, but it's a .o file

23:48 <iscle> great, thanks!

23:50 <MasterR3C0RD> UART boot log for reference as well: https://gist.github.com/BrokenR3C0RD/2d9c8ca1d6ae82d957e96d5c46c445df

23:53 <iscle> It looks quite easy to reverse engineer, doesn't it? Of course we don't get register names but looking at other SoC's code they could be inferred

23:53 <iscle> for reference: https://github.com/szemzoa/awboot/blob/main/arch/arm32/mach-v851s/dram.c

23:54 <iscle> Last week I received an A133 device which I'd like to boot mainline on, so I'm quite interested in reversing this and having a complete uboot spl

23:58 <MasterR3C0RD> Yep, it doesn't seem too difficult. On second glance there's a few other things that don't quite match up with the H6, but overall the decomp's clean for me in Binja