13:29 <karlp> does anyone know where the "USB DFU Speed" numbers came from here? https://linux-sunxi.org/FEL/USBBoot (from the table with soc support status)

13:29 <karlp> even using a ram backend, I'm capping out at ~1.3MB/sec which seems to be goverend byt he 4k limit on control transfers.

13:30 <karlp> I've instrumented dfu-util and there' no bwPollTimeout sleeps, so it seems to be at the protocol limit?

13:30 <gamiee> karlp: afaik the u-boot doesn't use DMA, so it is slower. The benchmarks were probably. Made on BSP?

13:32 <karlp> I suspect more likely that they were made on mac, that doesn't have the windows/linux 4k control transfer limit...

13:52 <karlp> bleh, if I disable "CONFIG_ENV_IS_IN_FAT" because I want it in mmc only, uboot doesn't boot. with it, it complains about unable to use fat on mmc block..

15:53 <apritzel> karlp: are you doing this on latest mainline? We fixed some issues about environment priority lately ...

15:54 <apritzel> and I am pretty sure I tested a raw MMC environment at some point in the past

15:54 <karlp> this is 22.07, 22.10 hadn't come out yet,

15:56 <apritzel> and you did enable CONFIG_ENV_IS_IN_MMC, and disabled CONFIG_ENV_IS_IN_FAT?

15:57 <karlp> if I have _only_ _IS_IN_MMC, it doesn't boot, if I have both, it boots, and saves in mmc.

15:57 <apritzel> IIRC the algorithm is to save where it loaded from, so that sounds about right

15:58 <apritzel> (and if possible: please ignore release tags, and just use the latest master)

15:58 <karlp> well, I'm trying to do "initial" programming, so can't it just do the "no env found, using default" instead of just freezing?

15:58 <apritzel> it should, but this whole priority thing is surprisingly tricky

15:59 <karlp> I don't doubt it. I've been spinning wheels in circles on this sort of thing all week.

15:59 <apritzel> it took somewhat like three fixes to get it right ;-)

15:59 <karlp> trying to ignore some of the desires to understand things properly and just get on with what I need to be doing...

16:00 <apritzel> and the generic U-Boot environment code is somewhat nasty, and silently hangs if the wrong environment source is returned

16:01 <apritzel> if you can live with the FAT warning, I recommend you just leave that in, for now, and I have a look at it later

16:01 <karlp> yeah, I'm living with it right now, it goes away the first time I do a save env..

16:01 <apritzel> or you try latest master (maybe 2022.10)

16:02 <karlp> if you want to poke something fun, "ums 0 mmc 1.1" then ctrl-c then "ums 0 mmc 1" (or any thjing where you try and reexpose UMS) asserts.

16:03 <karlp> I'm not even sure why the assert is there, all the callers _appear_ to handle the bool, but, that's another thing I can just work with right now, it reboots, and I re-issue the UMS command and move on.

16:06 <apritzel> karlp: ah, found the problem: https://source.denx.de/u-boot/u-boot/-/blob/master/board/sunxi/board.c#L169-176

16:06 <apritzel> it says "for all defconfigs ..."

16:07 <apritzel> I guess it's time to fix this properly, in the generic code ...

16:09 <apritzel> karlp: although I am wondering why you get there in the first place. You should exit above, with "return ENVL_MMC;"

16:11 <karlp> I dunno man, I can look at that again on monday and tryu just those steps for you, but I'm trying to get a couple of steps forward to finish the week right now.

16:14 <apritzel> karlp: are you booting from FEL, by any chance?

16:14 <karlp> yes,

16:15 <karlp> oh huh, boot dev != mmc then :)

16:15 <apritzel> yeah, that would explain it

16:15 <karlp> so if I could flash it directly, without fel, then it woudl work, but I can't get it flashed without running it via fel first.

16:16 <apritzel> we hoped we had fixed that issue, by always returning a valid source, but that assumes that you have either FAT, UBI or NOWHERE compiled in

16:16 <apritzel> and you have neither

16:16 <karlp> I mean, I only tried turning off FAT to try and make the warnings go away, it looked sus, and I don't have a fat partition I want it in anyway,

16:16 <apritzel> karlp: thanks for the report, I will have a look later

16:17 <karlp> you're very welcome :)

23:32 <apritzel> karlp: So I can reproduce your problem: when I remove ENV_IS_IN_FAT, and enable ENV_IS_IN_MMC, it hangs when doing FEL booting.

23:34 <apritzel> karlp: if you want a quick hack, just add "if (IS_ENABLED(CONFIG_ENV_IS_IN_MMC)) return ENVL_MMC;" to that "if (prio == 0) .... " statement at the end of env_get_location()

23:36 <apritzel> meanwhile it's env_init() that needs to be fixed, but that is used by other platforms as well, and even outside of init_sequence_f[], so it's a bit dangerous to change that ...