08:46 <Guest71> Hi everyone :)

08:47 <Guest71> I have a question if someone would be so kind to answer. Whom/Where do I need to contact from uboot, to report a security vulnerability?

08:48 <apalos> Guest71: Tartarus is the head maintainer, so mailing him (Tom Rini) and the subsystem maintainer which the vuln belongs to is a good start

08:55 <Guest71> Thank you very much! Is it still trini@konsulko.com ?

09:03 <apalos> yep

11:05 <apritzel> Hi, is there already something that would create a UCLASS_BLK device based on memory mapped (flash) storage? So to allow partitioning and filesystem access?

11:06 <apritzel> Maybe on top of MTD? Like Linux' mtdblock?

11:15 <apritzel> in particular this is using a Xilink "XIP/XNVM" QSPI controller, to expose a read-only byte-accessible view of some QSPI flash, and we want to use a GPT on that

12:06 <hanetzer> apritzel: so like, gdisk /dev/mdt in linux parlance?

12:06 <hanetzer> *mdt

12:57 <hanetzer> any rockchip u-boot maintainer around? a bit curious about the rockchip_timer_init function in mach-rockchip/spl.c

15:04 <hanetzer> hrm... my spl is getting too big.

15:30 <cambrian_invader> apritzel: I think you can use UBI

15:31 <cambrian_invader> http://www.linux-mtd.infradead.org/doc/ubi.html

15:32 <hanetzer> how would one go about seeing where to trim space in spl?

15:33 <hanetzer> I'm over by 0x108 bytes :P

15:33 <cambrian_invader> you can start with nm --size-sort u-boot

15:33 <cambrian_invader> and try enabling LTO

15:37 <hanetzer> damn, tsill 0x20 too big :P

15:37 <hanetzer> however that's a nice trick, thank.

15:48 <hanetzer> its the debug uart, nice.

16:02 <hanetzer> oh well, doesn't mattter much since I'm feeding it to a self-rolled qemu sim for now

16:31 <hanetzer> hrm. where can one enable debug symbols for u-boot?

16:43 <hanetzer> ah. optimize for debugging

17:14 <hanetzer> in coreboot there's a bit of ram used to keep the cbmem log ring buffer whatever that one could inspect in gdb while debugging, does something similar exist in u-boot, and if so, where is it located/how can one locate it?

18:31 <rfs613> hanetzer: check out CONFIG_LOG and related settings, which allows logging messages into a memory buffer.

18:31 <hanetzer> thank.

18:33 <rfs613> there is also bootstage, but AFAIK this is much less granular

19:00 <hanetzer> `undefined reference to `_u_boot_list_2_driver_2_hisilicon_hi3521a_crg' seems I'm missing something here for the spl.

19:02 <hanetzer> I did U_BOOT_DRIVER(hisilicon_hi3521a_crg) with .name = "hisilicon_hi3521a_crg", and try to get it via `uclass_get_device_by_driver(UCLASS_CLK, DM_DRIVER_GET(hisilicon_hi3521a_crg), devp)', where udevice **devp

19:08 <marex> hanetzer: driver not compiled in or something ?

19:08 <hanetzer> should be? there's an *.o file for it under spl

19:09 <hanetzer> or not... I swear it was there before lmao

19:09 <hanetzer> probably left over from a dirty rebuild.

19:24 <hanetzer> how,if at all, important is it to have the first parameter of the U_BOOT_DRIVER and .name field be the same?

19:42 <hanetzer> wrt DEBUG_UART_*_INIT, I suppose I should do any pinmuxing and clocking needed there yeah?

19:42 <cambrian_invader> yes

19:44 <hanetzer> and in arch/arm/mach-rockchip/spl.c rockchip_timer_init is initializing a memory-mapped clock, which may be, for example, a sp804 clock on another platform?

20:11 <rfs613> hanetzer: from a quick look, rockchip timer is not an sp804. The rockchip has a control register at offset 0x10. Whereas sp804 offset 0x10 is a read-only interrupt status register.

20:20 <rfs613> also the rockchip looks to be a 64-bit counter, while the sp804 is 32-bit (but there are two of them)

21:23 <NonaSuomy> What is usually involved in rooting a device besides using sketchy 3rd party tools?

21:26 <NonaSuomy> What do all these tools do to accomplish that task?

21:26 <NonaSuomy> When I look up manual root processes they all start with get 1-click root app etc but can't find technical documentation of what actually happens.

21:38 <hanetzer> rfs613: yeah, I just mean conceptually that its 'some clock peripheral mmio mapped here'

22:44 <hanetzer> ugh. it really is annoying when what your datasheet says is contradicted by running, working firmware on a device

22:46 <hanetzer> datasheets say apll foutpostdiv has a max of 800mhz but the registers and the maths they give for it put it at 1.1ghz lmao... unless their div1/div2 values are 1-indexed, I guess.

22:50 <hanetzer> but then again, other values match 1:1 when using 0-indexed values.