Dropping omap3430 ES1.0 support in mainline
Tony, all,
The OMAP3430 ES1.0 was pretty much a test chip, with the only known board being the 3430ES1.0 SDP. There are only a small number of these boards outside TI and within TI, they've likely never been used in over 2 years. It's unlikely that these boards still work on mainline, and likely have been broken in linux-omap since the very beginning.
Between ES1.0 and ES2.0 we've had several major changes in the clock nodes,
and IPs. However we're still keeping code/data on these in the kernel today.
Since all later OMAP3 chips have been very similar to ES2.0, it probably makes sense to drop support for the ES1.0. This would result in a small but probably significant reduction in the current code. If you're okay with dropping this support, we can slowly start working on this.
What do you think?
- Anand
Quoted 13 lines · Anand Gadiyar
Tony, all,
The OMAP3430 ES1.0 was pretty much a test chip, with the only known board being the 3430ES1.0 SDP. There are only a small number of these boards outside TI and within TI, they've likely never been used in over 2 years. It's unlikely that these boards still work on mainline, and likely have been broken in linux-omap since the very beginning.
Between ES1.0 and ES2.0 we've had several major changes in the clock nodes,
and IPs. However we're still keeping code/data on these in the kernel today.
Quoted 6 lines
Since all later OMAP3 chips have been very similar to ES2.0, it probably makes sense to drop support for the ES1.0. This would result in a small but probably significant reduction in the current code. If you're okay with dropping this support, we can slowly start working on this.
What do you think?
No thanks!
Tony
Quoted 5 lines · Anand Gadiyar
The OMAP3430 ES1.0 was pretty much a test chip, with the only known board being the 3430ES1.0 SDP. There are only a small number of these boards outside TI and within TI, they've likely never been used in over 2 years. It's unlikely that these boards still work on mainline, and likely have been broken in linux-omap since the very beginning.
We had linux-omap booting on the 3430SDP ES1.0 from at least 2007:
http://linux.omap.com/pipermail/linux-omap-open-source/2007-November/012160.html
We've used the 3430SDP ES1.0 as part of our regular testbed up until last year, when it fried itself, so as far as I know, it's worked the whole time.
- Paul
Quoted 3 lines · Paul Walmsley
Quoted 1 line · Anand Gadiyar
The OMAP3430 ES1.0 was pretty much a test chip, with the only known
board
Quoted 2 lines
Quoted 2 lines
being the 3430ES1.0 SDP. There are only a small number of these boards outside TI and within TI, they've likely never been used in over 2
years.
Quoted 1 line
Quoted 1 line
It's unlikely that these boards still work on mainline, and likely
have
Quoted 5 lines
Quoted 1 line
been broken in linux-omap since the very beginning.
We had linux-omap booting on the 3430SDP ES1.0 from at least 2007:
http://linux.omap.com/pipermail/linux-omap-open-source/2007-November/01216
0.html
Quoted 2 lines
We've used the 3430SDP ES1.0 as part of our regular testbed up until
last
Quoted 3 lines
year, when it fried itself, so as far as I know, it's worked the whole time.
Okay, so we're aligned that you guys don't have an ES1 board to test, and TI doesn't have any either. :)
I'd still like to know if anyone in the wild still cares about the board.
(I see Tony already said "No thanks", but I'd like to know anyway).
- Anand
Quoted 6 lines · Anand Gadiyar
Okay, so we're aligned that you guys don't have an ES1 board to test, and TI doesn't have any either. :)
I'd still like to know if anyone in the wild still cares about the board.
(I see Tony already said "No thanks", but I'd like to know anyway).
Why would we want to remove support for a board that should work fine with linux-omap and isn't causing any problems with existing code?
- Paul
Quoted 6 lines · Paul Walmsley
Quoted 4 lines · Anand Gadiyar
Okay, so we're aligned that you guys don't have an ES1 board to test, and TI doesn't have any either. :)
I'd still like to know if anyone in the wild still cares about the
board.
Quoted 4 lines
Quoted 2 lines
(I see Tony already said "No thanks", but I'd like to know anyway).
Why would we want to remove support for a board that should work fine
with
Quoted 1 line
linux-omap and isn't causing any problems with existing code?
I'm not sure it works fine, and if there are no users that care about the board, then it would be nice to drop the support. If the board works fine today, that's good, but has anyone tested the current kernel on that board?
(we're struggling to keep linux-omap working on boards available now, why support something that nobody cares about. It's not like I'm asking 3430 support to be dropped)
- the ES1 chip has never been available to the outside world beyond sampling quantities
- no new developments are likely to happen on that board
- nobody's likely to have one of these around and care to boot it up
- there are plenty of replacements like the beagles which are lower cost, easier to obtain, and can beat an ES1 in speed
I'm okay having support for the board if someone's actually using it. It's not such a big deal. It was just a thought - it came up because Manju was looking at old errata docs, and came across something that was specific to an ES1, but we realized there was no way to test it.
- Anand
Quoted 2 lines · Anand Gadiyar
Manju was looking at old errata docs, and came across something that was specific to an ES1, but we realized there was no way to test it.
Sounds like something that should at least go in as a comment to the affected code.
- Paul
Quoted 14 lines · Tony Lindgren
Quoted 13 lines · Anand Gadiyar
Tony, all,
The OMAP3430 ES1.0 was pretty much a test chip, with the only known board being the 3430ES1.0 SDP. There are only a small number of these boards outside TI and within TI, they've likely never been used in over 2 years. It's unlikely that these boards still work on mainline, and likely have been broken in linux-omap since the very beginning.
Between ES1.0 and ES2.0 we've had several major changes in the clock nodes,
and IPs. However we're still keeping code/data on these in the kernel today.
Quoted 8 lines
Quoted 6 lines
Since all later OMAP3 chips have been very similar to ES2.0, it probably makes sense to drop support for the ES1.0. This would result in a small but probably significant reduction in the current code. If you're okay with dropping this support, we can slowly start working on this.
What do you think?
No thanks!
yeah, I don't like the idea of simply dropping support either and would be very happy if I had an old h2 board to fix up the omap_udc.c code which is horrible :-p
Signature · 1 line
balbi
Quoted 31 lines · Anand Gadiyar
Quoted 6 lines · Paul Walmsley
Quoted 4 lines · Anand Gadiyar
Okay, so we're aligned that you guys don't have an ES1 board to test, and TI doesn't have any either. :)
I'd still like to know if anyone in the wild still cares about the
board.
Quoted 4 lines
Quoted 2 lines
(I see Tony already said "No thanks", but I'd like to know anyway).
Why would we want to remove support for a board that should work fine
with
Quoted 1 line
linux-omap and isn't causing any problems with existing code?
I'm not sure it works fine, and if there are no users that care about the board, then it would be nice to drop the support. If the board works fine today, that's good, but has anyone tested the current kernel on that board?
(we're struggling to keep linux-omap working on boards available now, why support something that nobody cares about. It's not like I'm asking 3430 support to be dropped)
- the ES1 chip has never been available to the outside world beyond sampling quantities
- no new developments are likely to happen on that board
- nobody's likely to have one of these around and care to boot it up
- there are plenty of replacements like the beagles which are lower cost, easier to obtain, and can beat an ES1 in speed
Quoted 4 lines
I'm okay having support for the board if someone's actually using it. It's not such a big deal. It was just a thought - it came up because Manju was looking at old errata docs, and came across something that was specific to an ES1, but we realized there was no way to test it.
If this is the SDMA bug we are talking about, it was unfortunately already there in OMAP2420. For some reason I didn't find it in 2430 errata, but since it was still there in 3430 ES1, we can assume that 2430 also has the issue.
That being said, ES1 devices for both OMAP3 and OMAP4 were supposed to be engineering samples. There is no product out there with OMAP3 ES1, and same thing is happening with 4430 ES1.
So, it makes sense to keep supporting them during the transition, but as soon as everybody is upgraded to the next production version, what the point to keep maintaining these buggy devices? Hopefully the auto-destroy mode after 2 years seems to work fine :-)
Regards,
Benoit