zamon has quit [Remote host closed the connection]
hentai has quit [Ping timeout: 480 seconds]
ftg has quit [Read error: Connection reset by peer]
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
hexdump02 has quit [Ping timeout: 480 seconds]
Kirby64 has joined #linux-sunxi
zamon has joined #linux-sunxi
<Kirby64>
Hi folks. I've got a weird question I'm trying to figure out: is there a way to compile u-boot with some extreme minimal always compatible RAM settings?
<Kirby64>
I've got an unknown system with an MR813 (A133, basically) with LPDDR4 RAM, and I can't get it to compile properly
<Kirby64>
I don't have a firmware image to compare against, and I'm hoping I can get u-boot into RAM so I can actually dump said firmware image...
<Kirby64>
No serial either on the image, and u-boot boots immediately.
<Kirby64>
I've tried compiling MasterR3C0RD's u-boot variant and tinkering with the DRAM setting to no avail. Always fails the 'DRAM simple test'
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
<dlan>
I think you need SPL image which usually comes small and fit with sram size
JohnDoe_71Rus has joined #linux-sunxi
bauen1 has joined #linux-sunxi
Kirby64 has quit [Ping timeout: 480 seconds]
gsz has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
junari_ has quit [Remote host closed the connection]
bauen1 has quit [Ping timeout: 480 seconds]
chewitt has quit [Read error: No route to host]
chewitt has joined #linux-sunxi
gsz has joined #linux-sunxi
chewitt has quit []
bauen1 has joined #linux-sunxi
apritzel_ has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<montjoie>
apritzel_: you could add my tested-by on your a527 branch
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
apritzel_ has left #linux-sunxi [Leaving]
hexdump0815 has quit [Read error: Connection reset by peer]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
apritzel has joined #linux-sunxi
zamon has quit [Remote host closed the connection]
zamon has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
zamon has quit [Read error: Connection reset by peer]
zamon has joined #linux-sunxi
Schimsalabim has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
<apritzel>
zamon_: please don't use explicit load addresses unless you know what you are doing. We defined known good values in the U-Boot config, so use: $kernel_addr_r, $ramdisk_addr_r, $fdt_addr_r when you want to load a kernel, ramdisk, DTB
<apritzel>
as an added bonus, those variable names are actually generic to all U-Boot platforms
JohnDoe_71Rus has joined #linux-sunxi
<apritzel>
zamon: ^^^^
bauen1 has joined #linux-sunxi
<apritzel>
also: you don't need to load a DTB, just use U-Boot's copy: $fdtcontroladdr. That removes the board specific part of the load sequence, making it even more generic
<apritzel>
Lightsword: the T507 manual documents PortA, but I checked the values there already some times ago, they match your values
benettig has quit [Read error: Network is unreachable]
benettig has joined #linux-sunxi
zamon has left #linux-sunxi [#linux-sunxi]
zamon has joined #linux-sunxi
<zamon>
apritzel: Got it, thanks. I just copied the command from wiki for quick testing previously.
<Lightsword>
apritzel, hmm, so if the PWM registers are correct, anything else you can think of that I should be looking at?
<dlan>
apritzel: do you have any idea how can I check cldo4 from software? on A527, I have problem to get emac1 up, and from hw it seems VCC3V3_PHY1 isn't up
<apritzel>
Lightsword: so most of the AC200/AC300 bits are one-time setup-only, so maybe it helps to hack things up in U-Boot (like forcing PWM by-pass mode), then NOT exposing it in the DT at all
<apritzel>
dlan: which board again? The Radxa? And what do you mean exactly with "getting emac1 up"? That's a different IP, not compatible to EMAC0, so requires more love (a different MAC driver)
<apritzel>
Lightsword: and I dimly remember that some Allwinner BSP code (not sure which SoC) used bitbanging I2C for some reason
<apritzel>
Lightsword: there is generic Linux support for this, just announce it in the DT, and assign the right GPIOs: Documentation/devicetree/bindings/i2c/i2c-gpio.yaml
<dlan>
right, radxa a5e, junari gave patch for emac1, I'm trying it.. but constantly get "Cannot attach to PHY" err
<Lightsword>
apritzel, oh, think bitbanging the i2c would get it unlocked?
<apritzel>
Lightsword: I don't know, but it's worth a try at this stage, I guess. "lock" typically means that the other end holds a line down (SCL, mostly)
<apritzel>
dlan: you can always check regulator status by reading /sys/kernel/debug/regulator/regulator_summary
<dlan>
ok, still have problem although see cldo4 is claimed
<apritzel>
dlan: have you checked PJ16 (PHY reset)
<paulk>
zamon: support for the A523 is still WIP, it probably doesn't support USB yet
<paulk>
you should see in the U-Boot log if it tries to scan usb devices or notr
<Lightsword>
apritzel, so would I use i2c-gpio instead of the normal i2c driver?
<apritzel>
paulk: zamon: USB host support definitely works, just use "usb reset" after you plugged in a USB stick, and you can load images from there (load usb 0:1 $kernel_addr_r Image-6.15-rc1.gz)
<apritzel>
Lightsword: yes, the idea is to use pure software bitbanging using the generic Linux driver, completely ignoring Allwinner IP
<apritzel>
zamon: for USB device support, you would need to add CONFIG_USB_MUSB_GADGET=y to the defconfig (that's indeed missing), then you should be able to use the Ethernet gadget or fastboot to upload images
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
Kirby64: I guess you cannot use the booted vendor system to dump registers (requires root access)?
<apritzel>
Kirby64: otherwise I see two possibilities: you hack mainline SPL to skip DRAM init and dump sectors from the eMMC(?), to get access to boot0 and its DRAM parameters
<apritzel>
code to read from SD/eMMC is in the SPL already, so far it just relies on DRAM for buffers. The A133 has quite some SRAM, so you could re-purpose that. So you just read sector 16ff., hexdump that and take it from there
<apritzel>
requires quite some hacking of the SPL, though, but should be doable, and doesn't need to be pretty for this exercise
<apritzel>
the other solution is to use FEL, if you can access that. There was someone in here end of last year (IIRC) to have some early MMC access code in sunxi-fel, so you could dump sectors directly via a USB cable
<apritzel>
I don't remember exactly how far this came, but I think they saw some early success, might be enough for what you need
zamon has quit [Remote host closed the connection]
<Lightsword>
FYI sunxi BSP's typically have a special driver that allows for dumping of arbitrary registers even if /dev/mem is disabled, it's at /sys/class/sunxi_dump/dump
paulk has quit [Ping timeout: 480 seconds]
zamon has joined #linux-sunxi
Kirby64 has joined #linux-sunxi
paulk-ter has joined #linux-sunxi
<apritzel>
yes, but that typically requires root access as well. Lightsword, curious: does your board feature this special file, and can you use it? You said your device is pretty much nailed down?
<Kirby64>
apritzel: unfortunately not. Vendor system has serial/uart not connected, and no root or USB access. It does, conveniently, have a FEL button and UART and FEL-USB pinouts, though, hence how i've ben tinkering with u-boot
<Lightsword>
apritzel, yes, mine has it, /dev/mem is disabled on mine but /sys/class/sunxi_dump/dump is not, I've used it to dump pwm registers, but yeah I have root access via various exploits, mine has extensive lockdown techniques implemented but I'm able to bypass virtually all of them in various ways
<Kirby64>
and you're correct, it's eMMC I'm trying to dump here. If I could get boot0, yea, I could get boot params. But I also can't find a firmware image of this system anywhere online
<Lightsword>
Kirby64, what system is it btw?
<Kirby64>
It's a Segway Navimow i105. Robot lawn mower
<Kirby64>
Might be another attack vector, honestly, but would require quite a bit more hardware hacking than I'm interested in. Seems like it has numerous open serial ports connected to other stuff... but I doubt any of them have shells
<Lightsword>
Kirby64, you try MITM attacking the network connections?
<Kirby64>
They use an annoying custom certificate pinning on their Android app and I've been too unmotivated to reverse that out
<Lightsword>
Kirby64, try GPL requesting the vendor?
<apritzel>
Kirby64: so do you boot via FEL at the moment?
<Kirby64>
It's Ninebot who makes these technically, I'd rather not let this thing sit for... who knows how long?
paulk-ter has quit [Ping timeout: 480 seconds]
<apritzel>
Kirby64: and do you feel comfortable to hack the SPL? For a first step you could skip the DRAM init, or at least the verification step, and then see whether it returns to FEL
<Kirby64>
apritzel: I can boot the stock firmware normally; loading the u-boot attempts are via FEL right now. The FEL button does not load boot1 obviously or if it did I'd just dump boot1 via FEL directly
<apritzel>
yes, the FEL button is probably a proper hardware one, that's checked in the BootROM
<Kirby64>
apritzel: I'm willing to try, but honestly not sure where to start. Seems pretty low risk at the moment obviously
<apritzel>
yes, there is really little risk. AFAIK the SPL MMC code is read-only anyway, and unless you mess up the PMIC setup there is really nothing that could blow up or anything
aggi has quit [Quit: update]
<Kirby64>
Yeah, and the PMIC on this thing is actually the 'dumb' one that should be in a safe state from POR I believe. It's a AXP305B
<apritzel>
Kirby64: at the end of board/sunxi/board.c:sunxi_board_init() there is the call to sunxi_dram_init()
<Kirby64>
It's a very weird combo of parts: MR813, AXP305B PMIC, and 2GB of LPDDR4 RAM
<apritzel>
yeah, indeed, but that's not really a problem for mainline, as we have (some) support for all of that
<Kirby64>
This might be a question to ask: should I be using true mainline at this point, or would the BrokenR3C0RD branch be better? I didn't see specific LPDDR4 A133 tests in mainline, but I might be overlooking them
<Kirby64>
and yea, I probably just need to get the params correct.
<apritzel>
Kirby64: use BrokenR3C0RD's branch for now, I am in the process of preparing the DRAM patch for mainline
<Kirby64>
(I've been using the branch, and making some attempts at guessing parameters based on some older IRC discussion passed. Obviously to no avail)
<apritzel>
yes, this can be tricky, and we really don't know enough to give some guidance. So the only ways are either reading the values from an image file, or dumping the registers after the BSP has init'ed the DRAM
<Kirby64>
alright, so commenting out DRAM init (replacing it with just 0) removes the output about DRAM testing, then just ends with '### ERROR ### Please RESET the board ###
<Kirby64>
'
<Kirby64>
Does not appear to return to FEL, as operations time out
<Kirby64>
honestly I'm halfway tempted to pull the eMMC and dump it directly, but I'd rather not add to cost and risk of reballing it :/ and sure feels like this should be possible if I can get u-boot running
<apritzel>
ah, you are on a very different skill level then ;-) I already had trouble soldering an SOIC8 NOR flash :-D
<Kirby64>
Oh I'm not saying I'd be successful. I'm just a EE by trade, so that's my forte. Plus you get some nicer tools over time
<Kirby64>
Taking the eMMC off is honestly the easy part. It's putting it back on that is harder.
<Lightsword>
heh, most I've managed to do is soldier on a missing 0603 resistor on a board, removing emmc sounds scary, lol
aggi has joined #linux-sunxi
<Kirby64>
Eh, a bit of hot air and some patience. No problem at all
<apritzel>
but the part you are after is towards the end, so I guess it's not super helpful
<Kirby64>
Yeah, I'm with you hacking code is more extensible. Certainly cheaper from materials standpoint too.
<apritzel>
and I never came around to deliver on that "(see below)" promise :-(
<apritzel>
Kirby64: if you use "readelf -s spl/u-boot-spl | sort -k2" you will see some symbols already point to DRAM, as they are not supposed to be used before the DRAM init routine. So you would need to tweak them
<apritzel>
Kirby64: so start with letting CONFIG_SPL_BSS_START_ADDR point to some free SRAM, say 0x2c000 or 0x30000
aggi has quit [Ping timeout: 480 seconds]
<Kirby64>
looks like all the items pointed to >26ff8 is stdio, init, and mmc?
<Kirby64>
easy enough to modify that though. A133 has a lot of SRAM.
<apritzel>
exactly
<apritzel>
you should be able to litter the code with printf's, to guide you and give you some info
<apritzel>
it's all within BSS, so just one change, and you can verify this by using readelf on the newly compiled image already
<Kirby64>
hm, well that worked. Move all those functions to 0x30000
<apritzel>
I *think* the MMC code uses some kind of heap for sector buffers, but don't know much about the MMC core code
<apritzel>
so you might need to move the SPL heap location as well
aggi has joined #linux-sunxi
<apritzel>
"grep ADDR .config" gives some more clues, so you would need to change the "relocated stack" as well
<Kirby64>
so you think the method here is just to compile u-boot and then just execute the spl by itself, with some hacked up code to dump just the boot0 from emmc to sram?
<Kirby64>
then fish it out with FEL?
<apritzel>
or just hexdump the sectors on the UART and fish it out from your terminal program log
<apritzel>
which wouldn't require a successful FEL return (which might be tricky)
<apritzel>
but yes, that was my plan
<Kirby64>
yeah, that might be easier I guess since I definitely am getting UART to work
<Kirby64>
also, do I want boot0 for dram stuff or boot1? it seems like the FEL pages imply DRAM init is done in boot1
<apritzel>
this is all outdated stuff from the Wiki, we haven't seen boot1 in the last ten years or so
<Kirby64>
ah
<apritzel>
you want boot0, which is like 32-48KB
<apritzel>
and has that eGON header, nicely recognisable in a hexdump:
<apritzel>
00000000 16 00 00 ea 65 47 4f 4e 2e 42 54 30 6a 72 dc 35 |....eGON.BT0jr.5|
<apritzel>
that's typically situated at sector 16 (8KB) of the boot device, eMMC in your case
<apritzel>
you would need to hack sunxi_get_boot_device(), which at the moment tells the SPL that it's booted from FEL
<apritzel>
force it to return BOOT_DEVICE_MMC2
<apritzel>
that should lead the code to read something from the eMMC. I think you need "CONFIG_MMC_SUNXI_SLOT_EXTRA=2" in your defconfig for that to work
<Kirby64>
Wait, do I just need to see 'eGON.BT0' ?
<Kirby64>
I was doing FEL hex dumps earlier, and I dumped some junk from the SRAM stack that had that in it
<apritzel>
well, that's the header of the boot0 signature that the BROM looks for
<apritzel>
you might be able to hack my tool to ignore an invalid checksum or length, and continue anyway
<Kirby64>
it's possible this was related to when I was messing around with trying to load the dust livesuit images too
<apritzel>
or you just decode which offsets it dumps, though that could be more tedious
<Kirby64>
which likely would have shoved a bunch of stuff into sram
<Kirby64>
but they were for DDR4 based devices and didn't work
<apritzel>
as said, this eGON header is the BootROM signature required by every image to be booted, so it's everywhere in Allwinner images
<Kirby64>
Right. Yeah, I'm just trying to make sure I know if this is coming from the actual NAND or not
<apritzel>
you would need to right image for your device, of course, which the safest location to get from is indeed the eMMC
<Kirby64>
Let me actually just re-do a dump of the SRAM here and see what I get
<apritzel>
is it actually raw NAND flash, controlled by the SoC's NAND flash controller, or eMMC? We don't support the former ...
<Kirby64>
it's eMMC
<apritzel>
good
<Kirby64>
I'm pretty sure I found the design it's based off of too, there's an Alibaba reference design card that has the same eMMC, RAM, and an A133 haha
<Kirby64>
Sadly no firmware image available for that card I could find
<apritzel>
the DRAM parameters would be specific to the DRAM chips used, the frequency, and the PCB layout, plus some secret sauce provided by Allwinner
<apritzel>
(which my hunch is mostly copy&paste, wild guesses and trying something till it works(TM))
<Kirby64>
Yeah. Plus a little bit of it is just 'how much performance do you need'
<apritzel>
so the most reliable way is really dumping the eMMC, if you cannot find an (update) image
<apritzel>
performance? Allwinner? that combination does not parse ;-)
<Kirby64>
alright so dumping 0x0 -> 0xC000 the SRAM has multiple entries of the eGON.BT0 string
<Kirby64>
no idea if that's just the BROM code trying to match for the magic header though
<apritzel>
yes, could be
<Kirby64>
or if I actually am loading boot0 into SRAM heh
<apritzel>
look for the branch instruction (xx 00 00 ea) at offset 0 and the size (something between 32 and 64KB in little endian) at offset 16
<Kirby64>
which wait I guess if I was initializing DRAM I could read 0x4000 0000
<Kirby64>
and I cannot
<apritzel>
well, sure, sunxi-fel uploads your provided SPL image into SRAM, so you would find it there somewhere, if it did return to FEL
<Kirby64>
okay. I figured out what I did
<Kirby64>
if I let it boot normally
<Kirby64>
then reboot using the reset button (with FEL held) on the board (with power connected) into FEL then the SRAM holds a bunch of other stuff
<Kirby64>
I have no idea if this is useful though. I can tell you from the hex dump it's running U-boot 2018.05 though haha
<apritzel>
ah OK, there might indeed be a chance that the boot0 image is still there
<Kirby64>
as per branch instruction, sure looks like its there: 1D 00 00 EA 65 47 4F 4E 2E 42 54 30
<Kirby64>
(65 47 4F 4E... is 'eGON.BT0')
<apritzel>
good, now look at the next line, that should be the size
<apritzel>
probs starts with "00 c0 00 00"
ftg has quit [Read error: Connection reset by peer]
<apritzel>
then at offset 0x38 there is the DRAM frequency word, follow by the DRAM type (08 00 00 00 for LPDDR4) in the next word
<Kirby64>
hmmm, so this is either at a very weird offset or something else
<Kirby64>
let me just dump this into a pastebin. Might be easier if you can stare at what I'm staring at
<apritzel>
yes, please
<apritzel>
the rest might have been overwritten, though
<Kirby64>
okay, here's a bit of it. I dumped the first 1MB 0x0->0x10240