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
vagrantc has quit [Quit: leaving]
qschulz has quit [Remote host closed the connection]
qschulz has joined #u-boot
mmu_man has quit [Ping timeout: 240 seconds]
thopiekar has quit [Ping timeout: 276 seconds]
thopiekar has joined #u-boot
_whitelogger has joined #u-boot
Gravis_ has joined #u-boot
Gravis has quit [Read error: Connection reset by peer]
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
mckoan|away is now known as mckoan
frieder has joined #u-boot
guillaume_g has joined #u-boot
pbergin has joined #u-boot
gsz has joined #u-boot
zibolo has joined #u-boot
mrnuke has quit [Ping timeout: 246 seconds]
mrnuke has joined #u-boot
hthiery 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.
gsz has quit [Quit: leaving]
sszy has joined #u-boot
monstr has joined #u-boot
tnovotny has joined #u-boot
prabhakarlad has joined #u-boot
sszy has quit [Ping timeout: 240 seconds]
mmu_man has joined #u-boot
zibolo_ has joined #u-boot
sszy has joined #u-boot
tnovotny has quit [Quit: Leaving]
torez has joined #u-boot
sszy has quit [Ping timeout: 240 seconds]
sszy has joined #u-boot
sszy has quit [Ping timeout: 240 seconds]
sszy has joined #u-boot
sszy has quit [Quit: No Ping reply in 180 seconds.]
sszy has joined #u-boot
<hanetzer> blerg... workign out pll clock drivers is *fun*
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
vagrantc has joined #u-boot
<hanetzer> y'think it would be useful to have a definition for MHz/KHz in some common location instead of defining it in every clock.h header?
gsz has joined #u-boot
pbergin has quit [Quit: Leaving]
<derRichard> hey, i have a question on drivers/bootcount/rtc.c. it seems to assume that rtc_write16() will give you access to the internal eeprom. but actually rtc_write* will just talk to the rtc itself. so it will only work for very simple/stupid rtcs. i have a rtc on my desk where you need to use more sophisticated i2c commands to read/write the internal eeprom
<derRichard> how to deal with such an rtc?
<Forty-Bot> what model rtc?
<derRichard> rv3028
<derRichard> in the linux driver you can see what commands you need to read/write the eeprom
<derRichard> adding a custom driver into drivers/bootcount/ should be easy, just want to make sure i don't oversee something :D
<Forty-Bot> well, there is only one existing board with that rtc
<Forty-Bot> and it doesn't use rtc_read* in its board code
<Forty-Bot> so you should be fine changing it
<derRichard> so, the goal of rtc_read*() is reading from the internal eeprom and not reading from a rtc i2c register?
<derRichard> ...which means u-boots rv3028
<Forty-Bot> I believe so
<derRichard> 's rtc_read/write are plain wrong?
<derRichard> :(
<Forty-Bot> well, if that isn't the case
ilunev has joined #u-boot
<Forty-Bot> you can always add a UCLASS_MISC child device
<derRichard> sadly the doc string in rtc_ops on read/write is close to useless :-(
<Forty-Bot> well, it does mention "registers" a lot
<Forty-Bot> which seems like it's meant for raw access
<derRichard> so drivers/bootcount/rtc.c is wrong because it assumes rtc_ops->read/writes gives access to the internal eeprom
<Forty-Bot> test/dm/rtc.c seems to imply raw register access
<derRichard> yeah, i'd also guess so
<Forty-Bot> but tbh I think this API is weird
<Forty-Bot> since usually you shouldn't care about doing raw access
<derRichard> we could add a new set of function to rtc_ops which allow access to the internal eeprom. e.g. ->eeprom_read/write, if these are NULL the caller is allowed to use the raw access functions
<Forty-Bot> I'd rather not proliferate read/write functions if possible...
<Forty-Bot> I think it should be OK to change the semantics of this API
<Forty-Bot> as there appear to be around 4-5 users total
<Forty-Bot> and most should be unaffected
NonaSuomy has joined #u-boot
<NonaSuomy> If u-boot is compiled for android could you still replace the kernel on the eMMC and then boot a random linux build instead of android?
<hanetzer> I mean. if you have a working bootloader of some sort you can prolly even run bsd with the right massaging
<derRichard> Forty-Bot: so you suggest that ->read/write should no longer give access to raw registers but to the internal eeprom (if there is any)
<Forty-Bot> I think that's more useful generally
<Forty-Bot> for most RTCs nothing needs to change
sobkas has joined #u-boot
<NonaSuomy> I want to get a console after the kernel boots. I compiled busybox into the uImage I get as far as Starting kernel ... and then I believe an external watchdog from maybe the WM8321 restarts the processor MX508 before I get the busybox prompt. Any idea how to pet that dog some how so that doesn't happen?
<derRichard> Forty-Bot: hm. and what about the rtc command? it exposes ->read/write as commands
<derRichard> so existings scripts might break
<Forty-Bot> well, for your specific RTC there is only one board
<Forty-Bot> so I think you can get away with making the change and seeing what happens
<NonaSuomy> Seems like 30 sec from U-Boot till that Linux Starting... line.
<NonaSuomy> *Starting kernel
<Forty-Bot> but e.g. my nvmem series also expects that the rtc read/write functions access the eeprom
<NonaSuomy> Kernel 2.6.35.3
<Forty-Bot> ah, the venerable 2.6
<derRichard> Forty-Bot: i have a generic solution in mind. not a hack that will break as soon i upgrade the bootloader :D
<Forty-Bot> how do you mean?
<NonaSuomy> U-Boot 2009.08 (Dec 21 2011 - 14:48:38)
<derRichard> i want to upstream my solution
<Forty-Bot> well, you only really have to change your rv3028 driver
<Forty-Bot> and maybe some documentation
<hanetzer> NonaSuomy: earlyprintk stuff?
<hanetzer> is DEBUG_LL enabled in the kernel?
<hanetzer> ohhh. its very old.
<hanetzer> Forty-Bot: makes me glad the kernel I'm working against is at least a 3.x series (3.10.something)
<Forty-Bot> you guys are nuts
<hanetzer> Forty-Bot: nah. I'm trying to be un-nuts (mainlining the device)
<NonaSuomy> @hanetzer I tried to enable earlyprintk but it won't compile on the mx508
<Forty-Bot> good luck!
<NonaSuomy> bunch of mangled stuff was moved around.
<hanetzer> but yeah. pretty nuts.
<NonaSuomy> CC arch/arm/kernel/early_printk.o
<NonaSuomy> In file included from arch/arm/kernel/debug.S:132:0:
<NonaSuomy> arch/arm/plat-mxc/include/mach/debug-macro.S:51:2: error: #error "CONFIG_DEBUG_LL is incompatible with multiple archs"
<NonaSuomy> #error "CONFIG_DEBUG_LL is incompatible with multiple archs"
<NonaSuomy> ^
<hanetzer> oh, you just gotta mess around with the kconfig settings, you need to turn off multiple arch selection under system type somewhere.
<NonaSuomy> hmm
<NonaSuomy> This? │ Symbol: MX5_MULTI_ARCH [=n]
<NonaSuomy> or this │ Symbol: ARCH_MXC [=y] │
<NonaSuomy> │ Prompt: Freescale MXC/iMX-based
zibolo has quit [Ping timeout: 252 seconds]
<hanetzer> not sure, havent fiddled with old kernels
zibolo_ has quit [Ping timeout: 252 seconds]
<NonaSuomy> From when I looked up that error I just found people bickering about how to handle it properly with not much a conclusion that I understood.
jelle has left #u-boot [WeeChat 3.5]
<hanetzer> d you know exactly what soc it is?
<NonaSuomy> System On Chip?
<NonaSuomy> MX508
<NonaSuomy> MCIMX508CVK8B NXP i.MX50 32-bit MPU, ARM Cortex-A8 core, 800MHz, MAPBGA 416.
<NonaSuomy> WM8321G Wolfson Processor Power Management Subsystem (PMIC)
<hanetzer> arch/arm/boot/dts/imx50.dtsi seems to be relevant to your interests.
<NonaSuomy> Yeah that's the same device
<NonaSuomy> Sony PRS-T1
<NonaSuomy> no folder exists under arch/arm/boot/ called dts
<hanetzer> NonaSuomy: modern kernel.
frieder has quit [Remote host closed the connection]
<hanetzer> looks like an interesting device.
<NonaSuomy> There is a project called inkbox I would like to get running on it.
<NonaSuomy> They have it running on a Kobo n905a/b which runs the same processor
<NonaSuomy> I think because I don't know how to pet that externel watchdog is the culprit or maybe I'm barking up the wrong tree
mckoan is now known as mckoan|away
<NonaSuomy> I tried to disable all the kernel watchdog features but it still reboots like clock work after 30sec
<NonaSuomy> I tested by using sleep 25; boot in the uboot console and then worked my way up to 30sec it gave me less and less lines from the kernel booting process.
mmu_man has quit [Ping timeout: 260 seconds]
<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.
ilunev has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
___nick___ has joined #u-boot
<NonaSuomy> Do embedded processors usually have an active watchdog pin, what enables them to begin with if not?
___nick___ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
___nick___ has joined #u-boot
<NonaSuomy> Or does that processor watchdog pin just not matter and the PMIC just turns the power off after not getting pet.
<NonaSuomy> If I know that pmic https://www.mouser.ca/datasheet/2/76/WM8321-514966.pdf is on 0x34 connected to the mx508 can I pet the watchdog from U-Boot?
<NonaSuomy> *i2c address 0x34
prabhakarlad has quit [Quit: Client closed]
monstr has quit [Remote host closed the connection]
jenneron[m] has joined #u-boot
<jenneron[m]> hello, does anyone know is it possible to boot a kernel from subpartition with u-boot? how?
redbrain has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
<NonaSuomy> The watchdog timer duration is set using WDOG_TO. The watchdog timer can be halted for debug
<NonaSuomy> purposes using the WDOG_DEBUG bit.
<NonaSuomy> WM8321G Address R16388(4004h) Watchdog, Bit 14 WDOG_DEBUG, Default 0, Watchdog Pause 0=Disable 1=Enabled (halts the watchdog timer for system debugging) Protected by user key
ilunev has joined #u-boot
<NonaSuomy> so now how do a form that into a uboot i2c command.
<NonaSuomy> i2c read <chip> <chip address> <length> <memory address>
<NonaSuomy> i2c mw <chip> <chip address> <value> <length>
<NonaSuomy> i2c md <chip> <chip address> <length>
<NonaSuomy> What is the difference between read and read and display
<NonaSuomy> i2c read 0x34 0x4004 1 <memory Address?> bit 14?
<rfs613> NonaSuomy: i2c read transfers data from the i2c device into RAM (at <memory address>)
<rfs613> whereas i2c md does i2c read and just displays the value on console
<NonaSuomy> Ok so I would want md to see the value set
<NonaSuomy> on the console
<rfs613> yes, md = memory display
<rfs613> and later you will liklely want mm to modify the value
<NonaSuomy> what is mm compared to mw?
<rfs613> mm is memory modify, it's a combination of md and mw.
<rfs613> it reads a value, shows it to you, then asks for a replacement value.
<NonaSuomy> oh nice
<rfs613> if you enter one, it writes the value.
<NonaSuomy> if you enter nothing it quits?
<rfs613> then it moves on to the next address, until you type a non-numeric value, it quits
<rfs613> at least that is how the regular memory version works, I haven't tried the i2c version, but suspect it is the same
<rfs613> by the way, do you have a schematic or otherwise know that the WM8321 watchdog is actually the one driving your reset?
<NonaSuomy> i2c mm{.b, .w, .l} {i2c_chip} {addr}{.0, .1, .2}
<NonaSuomy> No no schematic I just bruteforced to make me believe that with sleep ##; boot increments to understand that it wasn't the processors watchdog as it would display less and less kernel lines the more time I gave it.
<NonaSuomy> 30 secs was the max value I could get anything from.
<rfs613> ok, well it is possible there is another watchdog elsewhere. But this one is worth a try. Looks like it is enabled by default (per the datasheet you linked)
<rfs613> WDOG_DEBUG looks promising, although it looks like this bit is locked, and requires writing a code to security register first.
<NonaSuomy> There are two other uC's on board an 8bit micro and another which I can't read the label of something m430. I just hope they used the PMIC as the rest are undocumented.
Forty-Bot has quit [Read error: Connection reset by peer]
<NonaSuomy> maybe we get lucky and they never locked the bit?
<rfs613> see 12.4 (page 43) of the data sheet. Looks like it's built in, but they tell you the "code"
<rfs613> seems it is mostly to avoid accidental writes, not a real security protectoin
<rfs613> i2c md.w 0x34 0x4008 -> default value is 0x0000 according to data sheet
<NonaSuomy> Would that mean it's disabled by default?
<rfs613> that means you can't modify the WDOG_DEBUG bit (and other stuff too)
<rfs613> you have to write a magic value 0x9716 to this register, to allow writes to WDOG_DEBUG etc.
<NonaSuomy> Makes sense was just wondering if the default is security bit always enabled so you have to always do that process first. Booting now maybe we just won't get anything read back so lets see.
<rfs613> try reading from 0x4004 also... default value seems to be 0xaa17 for that register
<NonaSuomy> In linux it was showing that device i2cdetect as UU which means it's in use so hopefully it's not in use during uboot.
littlebobeep has quit [Ping timeout: 240 seconds]
<rfs613> UU means there is a linux driver that has claimed the device. Says nothing about u-boot really. But, if linux knows about it and has a driver, maybe all you need to do is start watchdogd to feed the watchdog?
mmu_man has joined #u-boot
<NonaSuomy> i2c_addr failed Error reading the chip.
<NonaSuomy> Let me confim
<NonaSuomy> input: wm831x_on as /devices/platform/imx-i2c.0/i2c-0/0-0034/wm831x-on/input/input2
<NonaSuomy> MX50_ARM2 U-Boot > i2c probe
<NonaSuomy> Valid chip addresses: 00 48
<NonaSuomy> I think that is the eink pmic though.
littlebobeep has joined #u-boot
<NonaSuomy> MX50_ARM2 U-Boot > i2c md.w 0x48 0x4008
<NonaSuomy> 4008: 00 e4 2f f5 20 32 2d fa 61 00 00 00 00 00 00 00 ../. 2-.a.......
<NonaSuomy> MX50_ARM2 U-Boot > i2c md.w 0x48 0x4004
<marex> i2c bus
<NonaSuomy> 4004: e4 74 fb 00 00 e4 2f f5 20 32 2d fa 61 00 00 00 .t..../. 2-.a...
<marex> and i2c dev N
<marex> switch bus to the right one
<marex> (if you have more than 1 i2c bus, which is likely)
ilunev has quit [Read error: Connection reset by peer]
<NonaSuomy> don't know if they had that command in this version of uboot
<NonaSuomy> MX50_ARM2 U-Boot > help i2c
<NonaSuomy> Usage:
<NonaSuomy> i2c md chip address[.0, .1, .2] [# of objects] - read from I2C device
<NonaSuomy> i2c - I2C sub-system
<NonaSuomy> i2c speed [speed] - show or set I2C bus speed
<NonaSuomy> i2c mm chip address[.0, .1, .2] - write to I2C device (auto-incrementing)
<NonaSuomy> i2c mw chip address[.0, .1, .2] value [count] - write to I2C device (fill)
<NonaSuomy> i2c nm chip address[.0, .1, .2] - write to I2C device (constant address)
<NonaSuomy> i2c crc32 chip address[.0, .1, .2] count - compute CRC32 checksum
<NonaSuomy> i2c probe - show devices on the I2C bus
<NonaSuomy> i2c reset - re-init the I2C Controller
<NonaSuomy> i2c loop chip address[.0, .1, .2] [# of objects] - looping read of device
ilunev has joined #u-boot
<NonaSuomy> U-Boot 2009.08 (Dec 21 2011 - 14:48:38)
<NonaSuomy> wm831x 0-0034: WM8321 revision C
<NonaSuomy> wm831x 0-0034: Security key had non-zero value 1
<NonaSuomy> I feel like that first 0 means it's on i2c-0
<NonaSuomy> is this maybe the old way of selecting the i2c port ? address[.0, .1, .2]
<NonaSuomy> I do remember in linux I believe there was a /dev/i2c-0,i2c-1,i2c-2 but maybe it just lists devices like that and not buses.
<NonaSuomy> When I typed i2c dev 0 it just gave me the list above so I assume that means it's not valid.
ilunev has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
___nick___ has quit [Ping timeout: 240 seconds]
<NonaSuomy> I looked at examples seems it should say "Setting bus to 0" after that not give the command list.
littlebobeep has quit [Ping timeout: 240 seconds]
Forty-Bot has joined #u-boot
<NonaSuomy> 48 tps65180 1-0048: PMIC TPS6518x for eInk display
littlebobeep has joined #u-boot
littlebo1eep has joined #u-boot
littlebobeep has quit [Ping timeout: 240 seconds]
flyback has quit [Remote host closed the connection]
littlebobeep has joined #u-boot
<marex> NonaSuomy: i2cdetect -l in Linux will tell you which busses you have
flyback has joined #u-boot
<NonaSuomy> [root (ttyGS0)]# ./busybox i2cdetect -l
<NonaSuomy> i2c-0 i2c imx-i2c I2C adapter
<NonaSuomy> i2c-1 i2c imx-i2c I2C adapter
<NonaSuomy> i2c-2 i2c imx-i2c I2C adapter
<NonaSuomy> Maybe the default is i2c-1 for some reason.
littlebo1eep has quit [Ping timeout: 240 seconds]
<NonaSuomy> not sure how you would switch to i2c-0 in this 2009.08 uboot version without i2c dev option.
<NonaSuomy> Link to the source code of that version of uboot is above
<NonaSuomy> link is from here
gsz has quit [Quit: leaving]
sobkas has quit [Quit: sobkas]
sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
littlebobeep has quit [Ping timeout: 240 seconds]
littlebobeep has joined #u-boot
torez has quit [Quit: torez]
apritzel has joined #u-boot
littlebobeep has quit [Ping timeout: 240 seconds]
littlebobeep has joined #u-boot
littlebobeep has quit [Remote host closed the connection]
littlebobeep has joined #u-boot
guillaume_g has quit [Ping timeout: 248 seconds]
<marex> NonaSuomy: could be just unimplemented/disabled ... do you need to access that i2c bus ?
<NonaSuomy> Line 105 that's the old source there
<NonaSuomy> #if defined(CONFIG_I2C_MULTI_BUS)
guillaume_g has joined #u-boot
littlebobeep has quit [Ping timeout: 240 seconds]
<NonaSuomy> #if defined(CONFIG_I2C_MULTI_BUS) U_BOOT_CMD_MKENT(dev, 1, 1, do_i2c_bus_num, "", ""),
<marex> it is possible this is disabled in your build
<NonaSuomy> #if defined(CONFIG_I2C_MULTI_BUS)
<NonaSuomy> if (!strncmp(argv[0], "de", 2))
<NonaSuomy> return do_i2c_bus_num(cmdtp, flag, argc, argv);
<NonaSuomy> does that mean it used to be de instead of dev.
<marex> it means 'de'<anything> matches
<marex> i2c dev would be handled the same as i2c deANYTHING
<marex> the shortest first arg is 2 letter long, mm/mw/md , probably that's why it is implemented that way
<NonaSuomy> Is there a way to see what is enabled/disable in uboot?
<marex> see include/configs/yourboard.h
littlebobeep has joined #u-boot
<NonaSuomy> mx50_arm2.h mx50_arm2_ddr2.h mx50_arm2_iram.h mx50_arm2_lpddr2.h mx50_arm2_mfg.h
<marex> NonaSuomy: arm2 is a devkit iirc
<NonaSuomy> I'll assume this means no
<marex> what are you trying to achieve here anyway ?
<NonaSuomy> #define CONFIG_CMD_I2C 1
<NonaSuomy> #define CONFIG_HARD_I2C 1
<NonaSuomy> #define CONFIG_SYS_I2C_PORT I2C2_BASE_ADDR
<NonaSuomy> #define CONFIG_SYS_I2C_SPEED 100000
<NonaSuomy> #define CONFIG_I2C_MXC 1
<NonaSuomy> #define CONFIG_SYS_I2C_SLAVE 0xfe
<NonaSuomy> same config section for all the files
<marex> what are you trying to achieve here anyway ?
<marex> what is the end goal ?
littlebobeep has quit [Ping timeout: 240 seconds]
<NonaSuomy> disable an external watchdog on the i2c bus that is set for 30 seconds which my customized kernel I believe is taking longer than that to boot as it has busybox compiled into it.
<marex> the WDT is not gonna be in the audio codec though ?
<NonaSuomy> End goal is to port a customized inkbox https://github.com/Kobo-InkBox/inkbox build to the sony PRS-T1
<marex> and usually WDT is supposed to be enabled and never disabled
<marex> how is it that your kernel starts for 30 seconds though ? that's a bit too much
<NonaSuomy> that chip is a power management device not audio
<NonaSuomy> It's a slow old processor.
<marex> its like cortex a9, no ?
<NonaSuomy> yes the device takes several mins to boot.
<NonaSuomy> on it's own firmware
<NonaSuomy> on inkbox it will take even longer
<marex> NonaSuomy: did you try booting the kernel with lzo compression or without compression ?
<marex> I wouldn't be surprised if they did not enable caches here
<marex> 800 MHz CA8 should be plenty fast
<marex> do you have 'icache' command there ?
<marex> run ... => icache
<NonaSuomy> I accedently wiped all the partitions off the eMMC so I no longer have access to a proper boot cycle.
<NonaSuomy> Basically just get uboot then I tried pointing uboot at my uImage on the SDCard
<marex> and that uImage is how big ?
<marex> did you build that yourself ?
<NonaSuomy> yes
<NonaSuomy> this is as far as I get now.
<marex> so the kernel does not start at all ?
<NonaSuomy> not sure why xip kernel image says ok as well.
<NonaSuomy> correct it gets there then it resets and you watch the same process over again
littlebobeep has joined #u-boot
<marex> is it possible the uImage is broken ?
<marex> do you have a working kernel image ?
<NonaSuomy> I believe I have a couple backups of the eMMC just not sure which part of it I should extract from
<marex> see 'printenv bootcmd'
<marex> that's the boot command
<marex> that's what the u-boot runs to load kernel and jump to it
<marex> if there is some load/fatload/ext2load/mmc load/... , that part
<NonaSuomy> this is the layout of the eMMC I believe https://pastebin.com/raw/d5HQcemy
<marex> Normal Kernel :0x00100000:0x00400000
<marex> probably this
<NonaSuomy> MX50_ARM2 U-Boot > printenv
<NonaSuomy> stdin=serial
<NonaSuomy> stderr=serial
<NonaSuomy> stdout=serial
<NonaSuomy> ethact=FEC0
<NonaSuomy> loadaddr=0x70800000
<NonaSuomy> loadaddr_ramdisk=0x70C00000
<NonaSuomy> rawtable=0xF40000
<NonaSuomy> bootargs=console=ttymxc2,115200 init=/init bootdev=0 rawtable=0xF40000
<NonaSuomy> bootcmd=mmc read 0 ${loadaddr} 0x800 0x1400;mmc read 0 ${loadaddr_ramdisk} 0x2800 0x258;bootm ${loadaddr} ${loadaddr_ramdisk}
<NonaSuomy> bootdev=0
<NonaSuomy> Environment size: 326/131068 bytes
guillaume_g has quit [Ping timeout: 260 seconds]
<marex> so it reads raw eMMC at offset 0x800 (in 512B block units) and it reads 0x1400 such blocks
<marex> thats the kernel
<marex> dtto for ramdisk
<marex> and then it jumps to it with bootm
apritzel has quit [Ping timeout: 252 seconds]
littlebobeep has quit [Quit: leaving]
<NonaSuomy> what is the purpose of reading the mmc and then reading the ramdisk?
littlebobeep has joined #u-boot
<NonaSuomy> I have flashed SDCard with the eMMC 1:1 copied with a few modifications to point to run from the SDCard (It used to run) when the eMMC had everything in place
<marex> NonaSuomy: they read uImage which wraps the kernel zImage and then read uImage which wraps the ramdisk
<marex> two blocks
<marex> *two blobs
<marex> and then they point the bootm command to both blobs to start kernel and provide pointer to ramdisk to the kernel
<NonaSuomy> Does it need both or is that like a backup if it can't find the ramdisk then it falls back to the eMMC or vice versa?
littlebo1eep has joined #u-boot
<NonaSuomy> Like I'm unsure why this uboot is still running after I removed all the partitions unless I missed it.
mmu_man has quit [Ping timeout: 252 seconds]
littlebobeep has quit [Ping timeout: 240 seconds]
<marex> maybe it is stored in emmc boot partition or some such ?
<marex> or in some other storage
<marex> the kernel is what you need, the ramdisk is optional, it gets mounted as root filesystem from ~tmpfs (ram)
<NonaSuomy> someone said something about nand but not sure where that would be as the emmc is this but no other IC on the board https://www.digchip.com/datasheets/parts/datasheet/1761/SDIN5D1-2G-LT-pdf.php
<NonaSuomy> would it have like a read only section of it that my wipeout wouldn't have hit?
<NonaSuomy> It has a button combination which I was able to get this https://pastebin.com/raw/v7kVurL7
<marex> NonaSuomy: open the SoC datasheet, is there a register called something like
<NonaSuomy> So it must have it's stock kernel some place as well
<marex> SRC_BMSR
<marex> or just BMSR
<marex> Boot Mode Status Register
<marex> if you 'md 0x.... 1' that register address, you will be able to determine from what the SOC booted
littlebo1eep has quit [Ping timeout: 240 seconds]
<NonaSuomy> Sorry it's an A8
<NonaSuomy> MCIMX508CVK8B