Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2022.04, v2022.07-rc2 are OUT / Merge Window is CLOSED / Release v2022.07 is scheduled for 4 July 2022 / http://www.denx.de/wiki/U-Boot / Channel archives at https://libera.irclog.whitequark.org/u-boot
<NonaSuomy> I don't see anything in there like that but maybe that is not the full datasheet
<marex> you want ... wait ...
littlebobeep has joined #u-boot
<marex> yes
<marex> SRC_SBMR
<marex> read it, then look up in fuse map what BOOT_MODE represents
<marex> 6.2 Boot Modes
littlebobeep has quit [Ping timeout: 240 seconds]
<NonaSuomy> Absoluteaddress(hex) 53FD_0004 SRC Boot Mode Register (SRC_SBMR) so from uboot console: md 0x53fd0004 1 ?
littlebobeep has joined #u-boot
<NonaSuomy> MX50_ARM2 U-Boot > md 0x53fd0004 1
<NonaSuomy> 53fd0004: d8200064 d. .
<marex> so boot_mode=0 ?
<NonaSuomy> Can you break that down for me?
<marex> SRC_SBMR[25:24] = 0
<marex> that's BOOT_MODE[1:0] = 0 ... so chapter 6.2 => BOOT_MODE[1:0]=0 => internal boot
<NonaSuomy> I'm in that section I just don't understand how d8200064 breaks down to that information you are listing
<marex> do you see how SBMR bits 25,24 are 0 in that register ?
<marex> d8200064
<marex> ---^
<marex> that is bits 27..24
<marex> errr
littlebobeep has quit [Ping timeout: 240 seconds]
<marex> d8200064
<marex> -^
<marex> there
<marex> 27 is 1 ... 26..24 all zeroes
<marex> yes ?
<marex> since BOOT_MODE[1:0] is SRC_SBMR[25:24] , BOOT_MODE is 2'b00 ...
littlebobeep has joined #u-boot
<NonaSuomy> ok so 8=28 2=27 0=26 0=25 0=24 6=23 4=22 ?
<marex> d8200064 is a 32bit number, with BIT(0) in LSbit position (rightmost)
<NonaSuomy> So I have it backwards?
<marex> I don't quite understand your notation
<marex> but look at this , assume it was just 0x20 , 8 bit number ... BIT(5) is 1, the rest of the bits is 0
<marex> assume it was just 0x10 , 8 bit number ... BIT(4) is 1, the rest of the bits is 0
<marex> and so on
<marex> 0x50 means BIT(6) and BIT(4) is 1 ...
<NonaSuomy> I took d8200064 and lopped the d off then aligned the values to the first chart on 49.3.2
<marex> the 0xd is the top 4 bits of the register
<marex> bits 31..28
<marex> you have the bit positions above the register layout on page 2910
<NonaSuomy> Ok so 27=8 26=2 etc
<NonaSuomy> my values were 1 number off
<marex> the bits can only be 1 or 0
<NonaSuomy> 27=8 26=2 25=0 24=0 23=0 22=6 21=4
<NonaSuomy> just bare with me till I get this.
<NonaSuomy> (I'm sorry)
<marex> d8200064 = 32'b 1101 1000 0010 0000 0000 0000 0110 0100
<marex> try this
<NonaSuomy> ah ok so you convert the d value to binary first then align it to 2910 chart
<marex> yes, it is 32bit number after all, 32 bits, 32 ones/zeroes
<marex> what u-boot prints is hexadecimal
<NonaSuomy> and you said it's LSB so 1101 is value 0=1 1=1 2=0 3=1 etc...
LinuxHackerman[m has quit [Ping timeout: 240 seconds]
samueldr has quit [Ping timeout: 256 seconds]
JBB[m] has quit [Ping timeout: 240 seconds]
hthiery has quit [Ping timeout: 248 seconds]
<marex> 0xd is MSB
<marex> 0x4 (rightmost) is LSByte
vfazio__ has joined #u-boot
cpackham[m] has quit [Ping timeout: 260 seconds]
MartijnBraam[m] has quit [Ping timeout: 260 seconds]
h_ro[m] has quit [Ping timeout: 252 seconds]
mvaittin has quit [Ping timeout: 252 seconds]
lovesegfault[m] has quit [Ping timeout: 248 seconds]
mripard has quit [Ping timeout: 260 seconds]
jevinskie[m] has quit [Ping timeout: 260 seconds]
kallisti5[m] has quit [Ping timeout: 252 seconds]
wehlutyk[m] has quit [Ping timeout: 260 seconds]
TryzenSlayerAlpe has quit [Ping timeout: 248 seconds]
Tartarus has quit [Ping timeout: 260 seconds]
Domon has quit [Ping timeout: 256 seconds]
jenneron[m] has quit [Ping timeout: 256 seconds]
vfazio_ has quit [Remote host closed the connection]
<NonaSuomy> 31=1 30=1 29=0 28=1 27=1 26=0 25=0 24=0 23=0 22=0 21=1 20=0 19=0 18=0 17=0 16=0 15=0 14=0 13=0 12=0 11=0 10=0 9=0 8=0 7=0 6=1 5=1 4=0 3=0 2=1 1=0 0=0
<NonaSuomy> Correct?
<marex> looks like it
<NonaSuomy> I may be slow but I arrive.
<marex> when in doubt, use
<marex> 11011000001000000000000001100100
<marex> echo "obase=2; ibase=16; D8200064" | bc
<marex> that will spit the binary
<NonaSuomy> very nice thank you.
<NonaSuomy> So as you said 00 Internal Boot
<NonaSuomy> Is that the eMMC?
<NonaSuomy> Or some part of memory that the processor has inside the package?
<marex> 6.5 Boot Devices (Internal Boot)
<marex> 6.5.3 Expansion Device Support
<marex> seems like eMMC normal boot
<marex> so it likely loads U-Boot from raw eMMC offset 2 sectors from the start (?)
hthiery has joined #u-boot
<NonaSuomy> Ok so I remember someone saying that there is a raw partition at the start of the eMMC so when I deleted the partitions one by one I probably just never hit that raw section
<NonaSuomy> There was 10 partitions and deleted them backwards 10,9,8,etc
<marex> this is not a partition
<marex> there is raw u-boot.imx written at some offset
<marex> on imx5 it was I think 2 sectors (offset 1kiB from start of storage)
samueldr has joined #u-boot
<NonaSuomy> I'm meaning unpartitioned space at the start of the eMMC
JBB[m] has joined #u-boot
<marex> try ... uh ... dd if=/dev/mmcblkX bs=512 skip=2 count=1 | hexdump -vC , I think there should be the imx header there
<marex> 6.6.1 Image Vector Table and Boot Data see here
<NonaSuomy> I currently only have access to uboot on the device
<marex> help mmc , is there mmc read ?
<NonaSuomy> yes
<marex> use it to read sector 2 to DRAM and then md the address
<marex> you should see the U-Boot there
<marex> err, the imx header there, the U-Boot is a bit further past that
LinuxHackerman[m has joined #u-boot
<NonaSuomy> mmc mmc read <device num> addr blk# cnt [partition]
MartijnBraam[m] has joined #u-boot
<marex> mmc read 0 $loadaddr 2 1 ; md $loadaddr 0x80
h_ro[m] has joined #u-boot
cpackham[m] has joined #u-boot
<NonaSuomy> MX50_ARM2 U-Boot > mmc read 0 $loadaddr 2 1 ; md $loadaddr 0x80
<NonaSuomy> imx_esdhc.c bus_width 0x1
<NonaSuomy> imx_esdhc.c bus_width 0x1
<NonaSuomy> imx_esdhc.c bus_width 0x4
<NonaSuomy> MMC read: dev # 0, block # 2, count 1 partition # 0 ...
<NonaSuomy> imx_esdhc.c bus_width 0x4
<NonaSuomy> SD set clock 50MHz
<NonaSuomy> Is that what you were expecting to see?
<NonaSuomy> If I just do the last part I see this:
wehlutyk[m] has joined #u-boot
mvaittin has joined #u-boot
Tartarus has joined #u-boot
TryzenSlayerAlpe has joined #u-boot
<marex> the 0xe59ff01c is branch instruction, so the first 8 are exception table maybe ?
<marex> maybe this board uses some custom preloader
TryzenSlayerAlpe has quit [Ping timeout: 250 seconds]
samueldr has quit [Ping timeout: 250 seconds]
wehlutyk[m] has quit [Ping timeout: 240 seconds]
mripard has joined #u-boot
Domon has joined #u-boot
thopiekar has quit [Ping timeout: 252 seconds]
thopiekar has joined #u-boot
jenneron[m] has joined #u-boot
lovesegfault[m] has joined #u-boot
jevinskie[m] has joined #u-boot
kallisti5[m] has joined #u-boot
samueldr has joined #u-boot
TryzenSlayerAlpe has joined #u-boot
wehlutyk[m] has joined #u-boot
vagrantc has quit [Quit: leaving]
ilunev has joined #u-boot
ilunev has quit [Quit: Textual IRC Client: www.textualapp.com]
NonaSuomy has quit [Ping timeout: 260 seconds]
mrnuke has quit [Quit: ZNC 1.8.2 - https://znc.in]
mrnuke has joined #u-boot
mrnuke has quit [Read error: Connection reset by peer]
mrnuke has joined #u-boot
akaWolf has quit [Ping timeout: 260 seconds]
akaWolf has joined #u-boot
guillaume_g has joined #u-boot
<hanetzer> hrm. for some reason I'm getting an error redefinition of clk_get_by_name_nodev and clk_release_all, but none of the code I've written even makes reference to that.
<hanetzer> in clk-uclass.c
prabhakarlad has joined #u-boot
mlaga97 has joined #u-boot
<hthiery> does anyone know if the HAB API on imx8 will work when using the upstream TF-A firmware. We see e.g. hab_auth_img command fails . The same works without issues when using downstream TF-A from NXP.
<hanetzer> ah, the problem arises when SPL_CLK is selected, hrm.
<crb> where does the ioAlign efi parameter get set?
camus has quit [Remote host closed the connection]
monstr has joined #u-boot
camus has joined #u-boot
<hanetzer> anyone know offhand where in the rockchip (rk3288 or rk3399) boot path tthe cru/clock hw is instantiated? having trouble finding it
mmu_man has joined #u-boot
<hanetzer> ohhh. from the looks of it, its indirectly called from the ram init?
jimpo has quit [Quit: ZNC 1.8.2 - https://znc.in]
jimpo has joined #u-boot
adeepv has quit [Quit: %exit%]
adeepv has joined #u-boot
NonaSuomy has joined #u-boot
<NonaSuomy> Can I boot uboot from uboot?
<NonaSuomy> without modifying the original uboot that is normally pointed at a linux kernel?
<hanetzer> I mean, you can load it to ram and go addr
sszy has joined #u-boot
ilunev has joined #u-boot
torez has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
NonaSuomy has quit [Ping timeout: 246 seconds]
NonaSuomy has joined #u-boot
<rfs613> NonaSuomy: does the existing u-boot also reset after 30 seconds?
<NonaSuomy> yes
<NonaSuomy> was going to try to compile this flag into uboot #define CONFIG_I2C_MULTI_BUS 1
<NonaSuomy> then quickly boot that then paste the i2c watchdog debug command we spoke about
<NonaSuomy> Not sure I will have enough time but eh something to try.
<rfs613> yup, understand the idea... however you might have some challenges to "restart" uboot from the beginning. For example it normally starts to initialize DDR and then copy itself there (relocation).
<hanetzer> yeah. theres a lotta fuckery involved.
<rfs613> that's a good way to put it ;-)
<NonaSuomy> What would you suggest?
<hanetzer> I'm neck deep in fuckery myself tbh :P
<hanetzer> trying to get enough of clockshit done enough to get uart output on this device :P
<hanetzer> plls are fun.
<NonaSuomy> How do I compile select the config I modified make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j8 mx50_arm2
<NonaSuomy> ?
<NonaSuomy> make: *** No rule to make target 'mx50_arm2'. Stop.
<rfs613> NonaSuomy: first you configure, then you build.
<rfs613> do you have configs/mx50_arm2_defconfig in your tree?
<NonaSuomy> mx50_arm2.h
<rfs613> thats include/configs/mx50_arm2.h, which is not the same as the defconfig
<rfs613> (but both contain various settings)
<NonaSuomy> where is this second configs folder?
<rfs613> at the top level, "configs", it contains a whole bunch of *_defconfig files
<hanetzer> rfs613: think thye're using old vendorboot, not mainline.
<rfs613> older than 2014 ?
<NonaSuomy> yes
<NonaSuomy> 2009.08
<rfs613> wow ;-)
<rfs613> i forgot how it worked back then ;-)
<hanetzer> yeh.
<rfs613> though it is cool that you have source code at all!
<hanetzer> I had to get my source from taobao lmao
<NonaSuomy> Yeah weird that sony did the right thing
<NonaSuomy> And that it's still there.
<rfs613> so the README in that u-boot does talk about using _defconfig, but they are called _config
<NonaSuomy> How do I compile select the config I modified make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j8 mx50_arm2_config?
<rfs613> it seems you just need to do "make mx50_arm2_config"
<rfs613> (along wiht your cross-compiler and ARCH settings)
<rfs613> it shoudl print "Configuring for mx50_arm2 board..."
<NonaSuomy> make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -j8 mx50_arm2_config
<NonaSuomy> Configuring for mx50_arm2 board...
<NonaSuomy> nice
<rfs613> then do it again without mx50_arm2_config, that should build default target (which is u-boot.bin probabl)
<NonaSuomy> arm-none-linux-gnueabi/4.4.1/armv4t -lgcc -Map u-boot.map -o u-boot
<NonaSuomy> arm-none-linux-gnueabi-objcopy --gap-fill=0xff -O binary u-boot u-boot.bin
<NonaSuomy> arm-none-linux-gnueabi-objcopy -O srec u-boot u-boot.srec
<rfs613> what, it just compiled on 1st try? Take the rest of the day off! :P
<NonaSuomy> haha
<NonaSuomy> so if I toss this on the root of the sdcard what would I need to tell the original uboot to swap to it?
<rfs613> well just like loading a kernel or anything else, you can get the existing u-boot read it into memory, and then jump to it.
<rfs613> but this will almost certainly not work, because of the previuosly mentioned complications, the new u-boot will attempt to reconfigure DDR (where it is located)
<rfs613> along with numerous other things, such as enabling caches
<rfs613> can you pastebin a full boot (u-boot and kernel, as far as it gets)?
<NonaSuomy> It's above if you still have log
<rfs613> and there's no output after "starting kernel" for 30 seconds?
<NonaSuomy> the 30 seconds includes the uboot loading.
<rfs613> ok, but if you stop u-boot at its prompt, and let it sit there, does it reset after 30 seconds?
<NonaSuomy> yes
<rfs613> so that means u-boot has either disabled watchdog, or it is kicking the watchdog periodically.
<NonaSuomy> sorry I'm saying that if you do anything in U-boot console it still resets no matter what you are doing in that time frame.
<NonaSuomy> you can be mid command typing and poof restart
<rfs613> oh gotcha
<rfs613> in normal boot though, the kernel must get loaded, and start executing (including triggering the watchdog) before 30 seconds have elapsed.
<NonaSuomy> I believe so you can see watchdog messages in the console when the stock os booted before
<NonaSuomy> They probably gave it just enough time for their kernel to boot and that is it.
<NonaSuomy> you can see a stock boot here
<NonaSuomy> When I messed with the uboot setenv to get it obooting from sdcard I got this output
<rfs613> that looks like it may be replaying an earlier boot log that it stored in RAM
<rfs613> but let's back up a moment.
<rfs613> the earlier log, you loaded the stock kernel (I think) but no ramdisk
<rfs613> there was no output after 'starting kernel' which is odd, but, this kernel will for sure hang/crash becase it has no rootfs. So it will just sit there and watchdog would reset the board.
<rfs613> now when you booted SD card, we can see some stuff including "MXC WatchDog Driver 2.0"
<NonaSuomy> So if I had a rootfs for my custom kernel I probably wouldn't be in this fight with the watchdog.
<NonaSuomy> ?
<rfs613> sort of... the existing kernel evidently has driver support for the watchdog, and the rootfs seems to start up some program to keep the watchdog happy.
<NonaSuomy> The first log is when I tried to boot my custom kernel the second is a stock boot and the third is a stock boot but from the sdcard where the console is always 4 instead of 2 so you get more information.
<NonaSuomy> and yes that was what I was trying to show you with the watchdog message that takes over.
<rfs613> and your idea of disabling watchdog in u-boot is good, but difficult because u-boot only talks one I2C bus, and its' the wrong one.
<NonaSuomy> correct
<rfs613> so does your custom kernel include a driver for the watchdog chip?
<NonaSuomy> my custom kernel is the stock kernel + busybox compiled into it as I was just trying to get a cli prompt
<rfs613> ok, fwiw, I would just try booting with init=/bin/sh as a first step, that might get you a cli using stock rootfs
<rfs613> (and it would probably reset after 30sec because there is nothing feeding the watchdog)
<NonaSuomy> I had to pare it down to 2.1M as it was 3.5M or around there after busybox was compiled in.
<NonaSuomy> I was doing this dd if=uImage of=/dev/mmcblk0 bs=512 seek=2048
<NonaSuomy> and then telling env to boot from there.
<rfs613> my concern is with you custom kenrel, there seems to be no output at all, so we dont' know what it is doing
<rfs613> wheras the stock one is at least printing lots of boot messages
<NonaSuomy> Agreed so after that I tried to compile in earlyprintk into the kernel but that code is broken in 2.6.35.3
<NonaSuomy> I'm sure it needs rootfs to process properly
<NonaSuomy> as you said.
<rfs613> you should have kernel boot messages regardless of rootfs
<NonaSuomy> ok one moment
<rfs613> but for the watchdog, normally there is a userspace program ("watchdogd") that runs and periodically makes a call to the kernel's watchdog driver, which then kicks the actual hardware so it won't reset the CPU.
<NonaSuomy> so this was what I was getting before when I still had a rootfs in place.
vagrantc has joined #u-boot
<NonaSuomy> and all the eMMC partitions
<NonaSuomy> it would then watchdog after Initialize a static memory for mix_logger.
<rfs613> so this shows the early boot
<NonaSuomy> What does that mean?
<rfs613> but it seems that after switching bootconsole to ttymxc2, you are not seeing normal kernel messages anymore.
<rfs613> there are a few more prints (not sure where those are coming from), but typically there are many more kernel drivers that probe, and eventually, you will see it preparing to switch to userspace (VFS mounted root)
<rfs613> compare it with the SD boot log you posted earlier.
<NonaSuomy> I think we tried to change this to console=ttymxc4 like what happened with the ext sd boot above but I can't remember if it just got stuck at the same message
sszy has quit [Ping timeout: 260 seconds]
<rfs613> you should see a lot more output (like the SD boot)
<NonaSuomy> Do you think it will be possible to boot from the SDCard again with no internel eMMC partitions?
<rfs613> can't say for sure, but the SD boot log looks encouraging.
<rfs613> the SD boot looks fairly complete, the only think missing is a login prompt. (Maybe it is on ttymxc2 instead of mxc4)
<rfs613> you could try init=/bin/sh trick to bypass that, this would give you a limited shell directly on the boot console
<NonaSuomy> setenv bootargs 'console=ttymxc4,115200 init=/bin/sh bootdev=0 rawtable=0xF40000' ?
<NonaSuomy> Let me reflash this sdcard I just keep seeing 2.1M instead of the stock 2.2M kernel.
<NonaSuomy> There is a 25MB unalocated disk space at the start of the drive is this a common practice?
sobkas has joined #u-boot
<marex> why dont you just boot Linux and let it ping the WDT ?
<marex> (you can always try and poke the I2C controller registers using 'mw' command and trigger transfer to the WDT that way too)
<NonaSuomy> So the only way to get a proper console on this device was to load a custom sd recover image that required you to hold home + menu on the device. Since I broke the eMMC partitions I can no longer get it to see this recovery card as I think it needed the eMMC recover partition to tell it how to handle this sd recovery.
<marex> which is probably something handled in $bootcmd, no ?
<NonaSuomy> I'm willing to try anything with thought the first step may be to see I Can get this stock image booting again from the SDCard. The external watchdog will basically reset the device after 30 seconds so whatever your thoughts are would have to be completed in that time frame unless we know how to pet it.
<rfs613> NonaSuomy: let me know if init=/bin/sh works... you may not get much time, but let's see if you get a shell prompt appearing.
<rfs613> marex: question for you about adding RZ/N1 clock driver... I plan to add it to drivers/clk/reneasas, with a new CONFIG_CLK_R9A06G032 symbol obviously.
<rfs613> There's a small problem, in order for makefile to recurse into drivers/clk/reneasas, I have to define CONFIG_CLK_RENESEAS, which cause renesas-cpg-mssr.c to be compiled
<rfs613> I don't really need that file, but the real issue is the renesas_clk_remove() function in there, has base address TMU_BASE which is platform specific I think
<NonaSuomy> This board has an 8bit reneasas microprocessor on it.
<NonaSuomy> I'm not sure what it does it's beside the SDCard slot
<NonaSuomy> I hope that is not the watchdog.
<NonaSuomy> do you think init=/bin/sh will work with no kernel booting?
<NonaSuomy> 3 more mins for the stock sd image flash
<NonaSuomy> Data Size: 2288064 Bytes = 2.2 MB
<NonaSuomy> I'm not sure what it wants now.
<NonaSuomy> I don't remember that XIP Kernel Image message when it used to boot properly
<rfs613> so back to no output at all
<NonaSuomy> Yes I'm not sure really how to load it without those eMMC partitions properly
<NonaSuomy> maybe I can get something to happen with home + menu I remember some more output
<NonaSuomy> ## Booting kernel from Legacy Image at 70800000 ... Image Name: Recovery Kernel
<marex> rfs613: the u-boot clock are modeled after the linux clock, so whatever linux does for rzn1, do it in u-boot the same (or similar_ way
<NonaSuomy> endless kernel panic repeat at the end there.
<rfs613> NonaSuomy: the kernel command line was changed to root=/dev/mmcblk2p1 rootfstype=ext4 rw rootwait init=/linuxrc console=ttymxc4,115200 bootdev=2 rawtable=0xF40000
guillaume_g has quit [Quit: Konversation terminated!]
<NonaSuomy> Not sure how to prevent init= from changing that while it switches to the recovery kernel from holding those buttons.
<NonaSuomy> Maybe while holding I can still trigger the hit any key to stop autoboot: 0
<NonaSuomy> then add it back then it boots the recovery kernel
<rfs613> NonaSuomy: i wonder if it is doing somethign else besides changing the commandline. Because all of the root-related parameters only come into play later in the boot (eg. you should get some kernel messages regardless), the only one that matters at the beginning is console=
<rfs613> marex: in linux drivers/clk/renesas is recursed unconditionally, and the renesas-cpg-mssr.c file depends on its own config symbol (CONFIG_CLK_RENESAS_CPG_MSSR)
<NonaSuomy> seems to ignore the serial terminal input while I'm holding the home + menu key on the device so it just goes past that hit any key prompt.
<NonaSuomy> This is the guy that I got the SDCard boot process from
<marex> rfs613: see ;-)
<NonaSuomy> If it sheds any light
<NonaSuomy> In his python script you can see him setting the env
<NonaSuomy> I wonder if the recovery kernel is disabling the watchdog some how.
<NonaSuomy> as it just sits there panicing forever after that point
<rfs613> NonaSuomy: this is the classic "VFS cant find root filesytem" problem
<rfs613> booted with root=/dev/mmcblk2p1 on kernel commandline
<rfs613> but there is no such device found when kernel finishes its boot
<rfs613> it only found a bunch of mmcblk0 partitions (likely the eMMC)
<rfs613> it also detected mmcblk2 but there are no partitions on there
<NonaSuomy> Yes mmcblk0 is the eMMC and mmcblk2 is the sdcard slot
<rfs613> mmcblk2: mmc2:0001 SEM02G 1.82 GiB
<rfs613> mmcblk2:
<rfs613> so there's a device, without any recognized partitions, and this asking to boot mmcblk2p1 cannot work
<rfs613> earlier, you were booting from SD and getting further (to userspace)
<NonaSuomy> before I corrupted the eMMC I was able to get this SDCard stock image to boot yes after that no go.
<NonaSuomy> I just flashed it fresh to the sdcard again now as It was looking like I modified it as it was showing the kernel as 2.1M which was the one I built before the stock kernel is 2.2M which it is reporting now.
<NonaSuomy> If I look at the SDCard I see all the proper partitions
<NonaSuomy> I think recovery mode (Home+Menu) doesn't know where to point proper to the SDCard partitions now.
<rfs613> that would be rather odd and unusual. The partition information is typically stored on the first block of the device (the SD card itself).
vagrantc has quit [Quit: leaving]
___nick___ has joined #u-boot
<NonaSuomy> The only step I can't complete now is where he copies u-boot from the sd image over top of the eMMC u-boot partition.
ilunev has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<NonaSuomy> that is how it started to boot properly before from SDCard
___nick___ has quit [Client Quit]
<rfs613> it looks like he's copying the uboot *env*
<NonaSuomy> yes sorry
___nick___ has joined #u-boot
<NonaSuomy> If we could do that now it would boot the sd but alas no terminal any more.
<rfs613> well, maybe just see what is actually different in the env
<rfs613> i'm not really convinced this will matter, it seems to be about enabling ADB
<rfs613> 353kB of html+javascript, says "The file you requested has been deleted" (I miss the old 404 not found...)
<rfs613> anyhow, the env files are basically just null-terminated strings. You can use "strings" command to extract those, then compare using your favourite tool (meld, kdiff, vim, etc)
<rfs613> same. Seems they don't like your files ;-)
<NonaSuomy> Wow their retention policy is nuts haha
<rfs613> it's how you make money. Upload is free. Download requires one-million-dollars mwuhahahaha
<NonaSuomy> first is new 2nd is old
<NonaSuomy> It probably does the same thing as his python script in the first post unless he typo'd something in the first post.
monstr has quit [Remote host closed the connection]
<rfs613> yep, changes bootdev from 2 to 0
<rfs613> and bootcmd loads from different partition and offsets
<NonaSuomy> So I'm guessing his python script is leaving out a few things
<NonaSuomy> New +HÆXstdin=serial stdout=serial stderr=serial ethact=FEC0 loadaddr=0x70800000 loadaddr_ramdisk=0x70C00000 rawtable=0xF40000 bootargs=console=ttymxc2,115200 init=/init bootdev=0 rawtable=0xF40000 bootcmd=mmc read 0 ${loadaddr} 0x800 0x1400;mmc read 0 ${loadaddr_ramdisk} 0x2800 0x258;bootm ${loadaddr} ${loadaddr_ramdisk} bootdev=0
<NonaSuomy> Old ­K&stdin=serial stdout=serial stderr=serial ethact=FEC0 loadaddr=0x70800000 loadaddr_ramdisk=0x70C00000 bootdev=2 rawtable=0xF40000 bootcmd=mmc read 2 ${loadaddr} 0x800 0x1400;mmc read 2 ${loadaddr_ramdisk} 0x2800 0x1F4;bootm ${loadaddr} ${loadaddr_ramdisk} bootargs=console=ttymxc2,115200 init=/init bootdev=2 rawtable=0xF40000
<NonaSuomy> His python script only does this
<NonaSuomy> # To boot recovery from SD card
<NonaSuomy> slowsend("setenv bootargs 'root=/dev/mmcblk0p1 rootfstype=ext4 rw "
<NonaSuomy> + "rootwait init=/linuxrc console=ttymxc4,115200 bootdev=2 rawtable=0xF40000'\r\n")
<NonaSuomy> # To boot normal system from SD card
<NonaSuomy> # slowsend("setenv bootargs 'console=ttymxc4,115200 init=/init bootdev=0 rawtable=0xF40000'\r\n")
<NonaSuomy> time.sleep(1.0)
<NonaSuomy> slowsend("boot\r\n")
<rfs613> here is the difference betweent old and new: https://gist.github.com/rfs613/4748de818addc9020df7b64fd549997a
<NonaSuomy> So maybe I'm backward 0 is the SD and 2 is the eMMC
<NonaSuomy> That would make sense why it couldn't find partitions on blk2 and recommended blk0
<NonaSuomy> So can we load all of that into the setenv?
<rfs613> you could, but the only real difference is in bootcmd, when it uses "mmc read" to get kernel and ramdisk. Old loads from device 2 and new loads from device 0.
<rfs613> (and the size of ramdisk is slightly bigger in the new one)
<NonaSuomy> setenv bootargs 'console=ttymxc2,115200 init=/init bootdev=0 rawtable=0xF40000 bootcmd=mmc read 0 ${loadaddr} 0x800 0x1400;mmc read 0 ${loadaddr_ramdisk} 0x2800 0x258;bootm ${loadaddr} ${loadaddr_ramdisk} bootdev=0'
<NonaSuomy> would that work?
<rfs613> no, not as part of bootargs
<rfs613> when you type "boot", u-boot executes $bootcmd. Which causes it to do "mmc read 0 ${loadaddr} 0x800 0x1400".
<NonaSuomy> I think they do have a typo there in that python script shouldn't this bootdev=2 be bootdev=0 ?
<rfs613> well we should figure out which is which... 0 and 2, one is SD, one is eMMC
<NonaSuomy> how do we decypher that from uboot?
<rfs613> let's just experiment... you can call "mmc read 0 ${loadaddr} 0x800 0x1400", that reads from device 0.
<rfs613> if you unplug the SD card, and run the command again, it should fail (if it was reading from SD)
<rfs613> i suspect that 2=eMMC and 0=SD, so this guy is just changing the default env so that it boots from SD.
<NonaSuomy> Your assumption is correct
<hthiery> hi .. is anyone around who has experience with imx hab?
<NonaSuomy> How do you edit $bootcmd?
<NonaSuomy> oh my it worked!
<marex> setenv bootcmd foo bar baz
<marex> see => help
<marex> and => help <command> , like ... => help setenv
<NonaSuomy> Thank you marex
<rfs613> NonaSuomy: great! do you get a login prompt?
<NonaSuomy> Nope
<NonaSuomy> but it's an active console
<NonaSuomy> that just keeps spamming mxc_rtc alarms after 180 sec
<NonaSuomy> so I know it's still alive.
<NonaSuomy> (no watchdog)
<rfs613> yep, that's good
<NonaSuomy> I'm sure if I plugged the screen in I would see the reader interface.
<rfs613> or a recovery process of some sort?
<NonaSuomy> maybe it's very janky setup so I can't really look
<rfs613> you could now try keeping everything the same, but change init=/linuxrc to init=/bin/sh in the bootargs
<rfs613> this might give you a shell prompt (but watchdog will kick in after 30sec elapsed)
<rfs613> alternatively, you could try editing what happens during startup, that is, start with /linuxrc on the 1st partition of the SD card.
<rfs613> the /linuxrx might be a shell script, or a symlink to /bin/busybox perhaps
<rfs613> haha that's not at all janky, just normal day at the office! :P
<NonaSuomy> haha
<NonaSuomy> I know there is a not every tool busybox in the stock image so I'll try both
<rfs613> you could check if /etc/inittab exists on that SD partition, and have it launch getty/mingetty or similar on /dev/ttymxc4
<rfs613> basically, follow the boot up process, get it to put a login prompt on your serial port
<NonaSuomy> Also I noticed I have ADB console now
<NonaSuomy> via usb
<NonaSuomy> I'll see if adb shell works
<rfs613> that could work too
<NonaSuomy> adb shell is working
<rfs613> got root? :P
<NonaSuomy> I don't think so how would I check
<NonaSuomy> I remember trying to change permissions and getting access denied
<rfs613> maybe try "id"
<NonaSuomy> # id
<NonaSuomy> uid=0(root) gid=0(root)
<rfs613> that looks promising
<NonaSuomy> BusyBox v1.17.4 (2010-12-13 13:27:50 JST) multi-call binary.
Gravis_ is now known as Gravis
___nick___ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
littlebobeep has quit [Remote host closed the connection]
___nick___ has joined #u-boot
littlebobeep has joined #u-boot
apritzel has joined #u-boot
___nick___ has quit [Ping timeout: 256 seconds]
<NonaSuomy> marex: do you have further information about running icache to speed up booting etc?
<marex> see cmd/cache.c
<marex> and => help icache
<NonaSuomy> cmd_cache.c
<marex> maybe that is what it was called ages ago, yes
<NonaSuomy> How would I know if it is already enabled? via source?
<marex> help icache
<marex> run that command
<marex> or check the u-boot board config in include/configs/yourboard.h for CONFIG_CMD_CACHE
<NonaSuomy> via source code
<NonaSuomy> ok
<NonaSuomy> Yah not enabled
<NonaSuomy> would there be any reason they wouldn't do that or just not knowing optimal practices?
<marex> back in the day, not all systems even implemented cache ops
<NonaSuomy> Like on the silicon?
<marex> line in u-boot from a decade ago
<marex> the common cache ops were implemented in like 2011 or so
<marex> so if your platform does not implement custom ones, maybe thats why caches are flat off
<NonaSuomy> i.mx508
<NonaSuomy> At the top of mx50_arm2.h it says Copyright (C) 2010 Freescale Semiconductor, Inc.
<NonaSuomy> at the top of cmd_cache.c it says * (C) Copyright 2000
<NonaSuomy> If you enable cache in uboot does it signal to the kernel to use it as well or is it stricly to speed up the uboot process?
<Tartarus> So, you're on 32bit ARM, so the first applies
littlebobeep has quit [Ping timeout: 240 seconds]
littlebobeep has joined #u-boot
sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
GNUtoo has quit [Ping timeout: 240 seconds]
littlebobeep has quit [Ping timeout: 240 seconds]
littlebobeep has joined #u-boot
GNUtoo has joined #u-boot
torez has quit [Quit: torez]
<NonaSuomy> Would #define CONFIG_CMD_CACHE 1 turn the cache on or just the option to use it at the uboot console?
sobkas has quit [Quit: sobkas]
apritzel has quit [Ping timeout: 240 seconds]