arm: rpi: Enable USB and Ethernet driver model Raspberry Pi
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 20 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 20 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [U-Boot] [PATCH 00/20] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi
Quoted 25 lines · Pavel Machek
Quoted 24 lines · Stephen Warren
Quoted 11 lines · Simon Glass
Hi Stephen,
Quoted 8 lines · Stephen Warren
Quoted 6 lines · Simon Glass
Raspberry Pi uses a DWC2 USB controller and a SMSC USB Ethernet adaptor. Neither of these currently support driver model.
This series does the following:
- Move Raspberry Pi to use device tree control (u-boot-dtb.bin instead ofu-boot.bin)Quoted 8 lines
Quoted 4 lines
I'd strongly prefer not to do this. For one thing, it means we'd need different U-Boot builds for each of the different RPi models, and we currently don't need that (or perhaps we require users to create their own u-boot-dtb.bin by choosing the right DTB to append). If it
Why does device tree change how things work now? The
get_board_rev()function currently deals with this. It doesn't look likerpi_board_revis used anywhere else.Without a DT, the code is free to make all the board-rev-specific decisions at run-time without external influence.
Quoted 8 lines
Quoted 4 lines
With a DT, we either have to:
a) Pick the DT for one particular board and use that everywhere, even if it's incorrect for the actual board in use.
Is that an option? I mean... if you can tolerate incorrect values for something, perhaps that something should not be in the dtb in the first place?
Indeed I would certainly rather not have U-Boot use a DT that contains invalid information.
Quoted 5 lines
Quoted 2 lines
b) Build a different U-Boot + DTB image for each board-rev, and put the correct one on the SD card.
d) Build U-Boot + set of DTB images, then pick up the right one at the runtime?
Perhaps that'd work.
Quoted 3 lines
Quoted 1 line
Neither of those options seem like a good idea to me.
Stuff that can be autodetected does not belong to the device tree...
I tend to agree, but then you need platform-specific code to do the auto-detection, and there's pushback on that since a large benefit of DT is to remove platform-specific code from SW and just represent the information in DT. Put another way, DT seems to end up being "nothing" (DT not used) or "everything" (even representing some auto-probed data). Not great, but.