Definitions for TStar / TenStar boards (USB A and USB C) #2784

New issue

Open

opened 2026-01-03 03:34:40 -06:00 by wlatendresse · 3 comments

wlatendresse commented

2026-01-03 03:34:40 -06:00

(Migrated from github.com)

I can not spot and definitions for the TenStar USB A and TenStar USB C versions of the RP2350 boards yet (See attached photos).

Is this intentional, or why don't these appear anywhere in src/boards/include/boards? (Are they simply identical to other models?)

I can not spot and definitions for the TenStar USB A and TenStar USB C versions of the RP2350 boards yet (See attached photos). Is this intentional, or why don't these appear anywhere in src/boards/include/boards? (Are they simply identical to other models?) ![Image](https://github.com/user-attachments/assets/ce9bfd97-9b3c-4c1d-8d36-4fc37177a5c0) ![Image](https://github.com/user-attachments/assets/fa60bb02-3755-4d8f-b4ca-7dcddd3bd1ec)

peterharperuk commented

2026-01-03 06:04:19 -06:00

(Migrated from github.com)

It's up to the manufacturer to push a change to add support for their board

wlatendresse commented

2026-01-03 07:40:09 -06:00

(Migrated from github.com)

It's up to the manufacturer to push a change to add support for their board

Yes, either the manufacturer does it, or the community does it if the manufacturer doesn't want to. That has always been the spirit of open source, and that's precisely why this issue was created, and also to make it clear that the manufacturer apparently hasn't considered it necessary so far.

The current state (also considering the number of existing repositories and the resulting code fragmentation) is hardly tenable anyway.

The Linux kernel demonstrates, in principle, how it should work. I see no reason why things should be any different for Raspberry Pi projects (and its countless derivatives), especially considering the associated loss of productivity caused by searches and similar tasks.

> It's up to the manufacturer to push a change to add support for their board Yes, either the manufacturer does it, or the community does it if the manufacturer doesn't want to. That has always been the spirit of open source, and that's precisely why this issue was created, and also to make it clear that the manufacturer apparently hasn't considered it necessary so far. The current state (also considering the number of existing repositories and the resulting code fragmentation) is hardly tenable anyway. The Linux kernel demonstrates, in principle, how it should work. I see no reason why things should be any different for Raspberry Pi projects (and its countless derivatives), especially considering the associated loss of productivity caused by searches and similar tasks.

kilograham commented

2026-06-29 11:04:01 -05:00

(Migrated from github.com)